| 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.