Conditions | 10 |
Paths | 10 |
Total Lines | 27 |
Code Lines | 25 |
Lines | 0 |
Ratio | 0 % |
Changes | 1 | ||
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 |
||
17 | public static function getMessage($errorCode) |
||
18 | { |
||
19 | switch ($errorCode) { |
||
20 | case self::OK: |
||
21 | return null; |
||
22 | break; |
||
|
|||
23 | case self::INI_SIZE: |
||
24 | case self::FORM_SIZE: |
||
25 | return __('Uploaded file size exceeds maximum file size allowed'); |
||
26 | break; |
||
27 | case self::PARTIAL: |
||
28 | return __('The uploaded file was only partially uploaded'); |
||
29 | break; |
||
30 | case self::NO_FILE: |
||
31 | return __('No file was uploaded'); |
||
32 | break; |
||
33 | case self::TYPE_NOT_ALLOWED: |
||
34 | return __('File type not allowed'); |
||
35 | break; |
||
36 | case self::CANT_WRITE: |
||
37 | return __('Error saving uploaded file'); |
||
38 | break; |
||
39 | case self::NO_TMP_DIR: |
||
40 | case self::EXTENSION: |
||
41 | default: |
||
42 | return __('Upload error'); |
||
43 | break; |
||
44 | } |
||
47 |
The
break
statement is not necessary if it is preceded for example by areturn
statement:If you would like to keep this construct to be consistent with other
case
statements, you can safely mark this issue as a false-positive.