| Conditions | 11 |
| Paths | 30 |
| Total Lines | 26 |
| Code Lines | 21 |
| Lines | 0 |
| Ratio | 0 % |
| Changes | 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 |
||
| 143 | private function onDeepestType(&$n, &$parent, &$previous, $lineString):bool |
||
| 144 | { |
||
| 145 | $deepest = $previous->getDeepestNode(); |
||
| 146 | switch ($deepest->type) { |
||
| 147 | case T::LITTERAL: |
||
|
1 ignored issue
–
show
|
|||
| 148 | case T::LITTERAL_FOLDED: |
||
|
1 ignored issue
–
show
|
|||
| 149 | $n->value = trim($lineString);//fall through |
||
| 150 | case T::REF_DEF://fall through |
||
|
1 ignored issue
–
show
|
|||
| 151 | case T::SET_VALUE://fall through |
||
|
1 ignored issue
–
show
|
|||
| 152 | case T::TAG: |
||
|
1 ignored issue
–
show
|
|||
| 153 | $parent = $deepest; |
||
| 154 | break; |
||
| 155 | case T::EMPTY: |
||
|
1 ignored issue
–
show
|
|||
| 156 | case T::SCALAR: |
||
|
1 ignored issue
–
show
|
|||
| 157 | if ($n->type === T::SCALAR && |
||
|
1 ignored issue
–
show
|
|||
| 158 | !in_array($deepest->getParent()->type, T::$LITTERALS) ) { |
||
| 159 | $deepest->type = T::SCALAR; |
||
| 160 | $deepest->value .= "\n".$n->value; |
||
| 161 | return true; |
||
| 162 | } else { |
||
|
1 ignored issue
–
show
|
|||
| 163 | if (!in_array($previous->type, [T::ITEM, T::SET_KEY])) { |
||
|
1 ignored issue
–
show
|
|||
| 164 | $parent = $deepest->getParent(); |
||
| 165 | } |
||
|
1 ignored issue
–
show
|
|||
| 166 | } |
||
|
1 ignored issue
–
show
|
|||
| 167 | } |
||
| 168 | return false; |
||
| 169 | } |
||
| 171 |