| Conditions | 11 | 
| Paths | 11 | 
| Total Lines | 21 | 
| Code Lines | 19 | 
| Lines | 0 | 
| Ratio | 0 % | 
| Changes | 2 | ||
| Bugs | 0 | Features | 0 | 
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
| 1 | <?php  | 
            ||
| 89 | public static function getOS(): int  | 
            ||
| 90 |     { | 
            ||
| 91 |         switch (PHP_OS) { | 
            ||
| 92 | case 'Unix':  | 
            ||
| 93 | case 'FreeBSD':  | 
            ||
| 94 | case 'NetBSD':  | 
            ||
| 95 | case 'OpenBSD':  | 
            ||
| 96 | case 'Linux':  | 
            ||
| 97 | return self::OS_LINUX;  | 
            ||
| 98 | break;  | 
            ||
| 
                                                                                                    
                        
                         | 
                |||
| 99 | case 'WINNT':  | 
            ||
| 100 | case 'WIN32':  | 
            ||
| 101 | case 'Windows':  | 
            ||
| 102 | case 'CYGWIN_NT':  | 
            ||
| 103 | return self::OS_WIN;  | 
            ||
| 104 | break;  | 
            ||
| 105 | case 'Darwin':  | 
            ||
| 106 | return self::OS_OSX;  | 
            ||
| 107 | break;  | 
            ||
| 108 | default:  | 
            ||
| 109 | return self::OS_UNKNOWN;  | 
            ||
| 110 | }  | 
            ||
| 113 | 
The
breakstatement is not necessary if it is preceded for example by areturnstatement:If you would like to keep this construct to be consistent with other
casestatements, you can safely mark this issue as a false-positive.