GitHub Access Token became invalid

It seems like the GitHub access token used for retrieving details about this repository from GitHub became invalid. This might prevent certain types of inspections from being run (in particular, everything related to pull requests).
Please ask an admin of your repository to re-new the access token on this website.
Test Setup Failed
Push — master ( c5ade0...e039e4 )
by Gabriel
05:51
created

Debug   A

Complexity

Total Complexity 8

Size/Duplication

Total Lines 48
Duplicated Lines 0 %

Coupling/Cohesion

Components 1
Dependencies 4

Importance

Changes 0
Metric Value
dl 0
loc 48
rs 10
c 0
b 0
f 0
wmc 8
lcom 1
cbo 4

1 Method

Rating   Name   Duplication   Size   Complexity  
C enable() 0 32 8
1
<?php
2
3
namespace Nip\Debug;
4
5
use Symfony\Component\Debug\BufferingLogger;
6
use Symfony\Component\Debug\Debug as SymfonyDebug;
7
8
/**
9
 * Class Debug
10
 * @package Nip\Debug
11
 */
12
class Debug extends SymfonyDebug
13
{
14
    private static $enabled = false;
0 ignored issues
show
Comprehensibility introduced by
Consider using a different property name as you override a private property of the parent class.
Loading history...
15
16
    /**
17
     * Enables the debug tools.
18
     *
19
     * This method registers an error handler and an exception handler.
20
     *
21
     * If the Symfony ClassLoader component is available, a special
22
     * class loader is also registered.
23
     *
24
     * @param int $errorReportingLevel The level of error reporting you want
25
     * @param bool $displayErrors Whether to display errors (for development) or just log them (for production)
26
     */
27
    public static function enable($errorReportingLevel = E_ALL, $displayErrors = true)
28
    {
29
        if (static::$enabled) {
0 ignored issues
show
Bug introduced by
Since $enabled is declared private, accessing it with static will lead to errors in possible sub-classes; consider using self, or increasing the visibility of $enabled to at least protected.

Let’s assume you have a class which uses late-static binding:

class YourClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return static::$someVariable;
    }
}

The code above will run fine in your PHP runtime. However, if you now create a sub-class and call the getSomeVariable() on that sub-class, you will receive a runtime error:

class YourSubClass extends YourClass { }

YourSubClass::getSomeVariable(); // Will cause an access error.

In the case above, it makes sense to update SomeClass to use self instead:

class SomeClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return self::$someVariable; // self works fine with private.
    }
}
Loading history...
30
            return;
31
        }
32
33
        static::$enabled = true;
0 ignored issues
show
Bug introduced by
Since $enabled is declared private, accessing it with static will lead to errors in possible sub-classes; consider using self, or increasing the visibility of $enabled to at least protected.

Let’s assume you have a class which uses late-static binding:

class YourClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return static::$someVariable;
    }
}

The code above will run fine in your PHP runtime. However, if you now create a sub-class and call the getSomeVariable() on that sub-class, you will receive a runtime error:

class YourSubClass extends YourClass { }

YourSubClass::getSomeVariable(); // Will cause an access error.

In the case above, it makes sense to update SomeClass to use self instead:

class SomeClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return self::$someVariable; // self works fine with private.
    }
}
Loading history...
34
35
        if (null !== $errorReportingLevel) {
36
            error_reporting($errorReportingLevel);
37
        } else {
38
            error_reporting(E_ALL);
39
        }
40
41
        if ('cli' !== PHP_SAPI) {
42
            ini_set('display_errors', 0);
43
            ExceptionHandler::register($displayErrors);
44
        } elseif ($displayErrors && (!ini_get('log_errors') || ini_get('error_log'))) {
45
            // CLI - display errors only if they're not already logged to STDERR
46
            ini_set('display_errors', 1);
47
        }
48
49
        if ($displayErrors) {
50
            $handler = ErrorHandler::register(new ErrorHandler(new BufferingLogger()));
0 ignored issues
show
Documentation introduced by
new \Nip\Debug\ErrorHand...ebug\BufferingLogger()) is of type object<Nip\Debug\ErrorHandler>, but the function expects a null|object<self>.

It seems like the type of the argument is not accepted by the function/method which you are calling.

In some cases, in particular if PHP’s automatic type-juggling kicks in this might be fine. In other cases, however this might be a bug.

We suggest to add an explicit type cast like in the following example:

function acceptsInteger($int) { }

$x = '123'; // string "123"

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
51
        } else {
52
            $handler = ErrorHandler::register();
53
            $handler->throwAt(0, true);
54
        }
55
56
        app('container')->share(ErrorHandler::class, $handler);
57
//        DebugClassLoader::enable();
0 ignored issues
show
Unused Code Comprehensibility introduced by
58% of this comment could be valid code. Did you maybe forget this after debugging?

Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it.

The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production.

This check looks for comments that seem to be mostly valid code and reports them.

Loading history...
58
    }
59
}
60