| Conditions | 1 |
| Paths | 1 |
| Total Lines | 110 |
| 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 |
||
| 111 | public function queries() |
||
| 112 | { |
||
| 113 | return [ |
||
| 114 | [ |
||
| 115 | '{ test:nonNullArgument2(ids: [1, 2]) }', |
||
| 116 | [ |
||
| 117 | 'data' => [ |
||
| 118 | 'test' => 1 |
||
| 119 | ] |
||
| 120 | ], |
||
| 121 | ], |
||
| 122 | [ |
||
| 123 | '{ test:nonNullArgument2(ids: [1, null]) }', |
||
| 124 | [ |
||
| 125 | 'data' => [ |
||
| 126 | 'test' => null |
||
| 127 | ], |
||
| 128 | 'errors' => [ |
||
| 129 | [ |
||
| 130 | 'message' => 'Not valid type for argument "ids" in query "nonNullArgument2": Field must not be NULL', |
||
| 131 | 'locations' => [['line' => 1, 'column' => 25]] |
||
| 132 | ] |
||
| 133 | ] |
||
| 134 | ], |
||
| 135 | ], |
||
| 136 | [ |
||
| 137 | '{ test:nonNullArgument(ids: [1, null]) }', |
||
| 138 | [ |
||
| 139 | 'data' => [ |
||
| 140 | 'test' => 1 |
||
| 141 | ] |
||
| 142 | ] |
||
| 143 | ], |
||
| 144 | [ |
||
| 145 | '{ test:nonNullArgument }', |
||
| 146 | [ |
||
| 147 | 'data' => [ |
||
| 148 | 'test' => null |
||
| 149 | ], |
||
| 150 | 'errors' => [ |
||
| 151 | [ |
||
| 152 | 'message' => 'Require "ids" arguments to query "nonNullArgument"' |
||
| 153 | ] |
||
| 154 | ] |
||
| 155 | ] |
||
| 156 | ], |
||
| 157 | [ |
||
| 158 | '{ nonNullScalar }', |
||
| 159 | [ |
||
| 160 | 'data' => [ |
||
| 161 | 'nonNullScalar' => null |
||
| 162 | ], |
||
| 163 | 'errors' => [ |
||
| 164 | [ |
||
| 165 | 'message' => 'Cannot return null for non-nullable field "nonNullScalar"' |
||
| 166 | ] |
||
| 167 | ] |
||
| 168 | ] |
||
| 169 | ], |
||
| 170 | |||
| 171 | [ |
||
| 172 | '{ nonNullList }', |
||
| 173 | [ |
||
| 174 | 'data' => [ |
||
| 175 | 'nonNullList' => null |
||
| 176 | ], |
||
| 177 | 'errors' => [ |
||
| 178 | [ |
||
| 179 | 'message' => 'Cannot return null for non-nullable field "nonNullList"' |
||
| 180 | ] |
||
| 181 | ] |
||
| 182 | ] |
||
| 183 | ], |
||
| 184 | [ |
||
| 185 | '{ nonNullListOfNpnNull }', |
||
| 186 | [ |
||
| 187 | 'data' => [ |
||
| 188 | 'nonNullListOfNpnNull' => null, |
||
| 189 | ], |
||
| 190 | 'errors' => [ |
||
| 191 | [ |
||
| 192 | 'message' => 'Not valid resolved type for field "nonNullListOfNpnNull": Field must not be NULL' |
||
| 193 | ] |
||
| 194 | ] |
||
| 195 | ] |
||
| 196 | ], |
||
| 197 | |||
| 198 | [ |
||
| 199 | '{ user {id, name} }', |
||
| 200 | [ |
||
| 201 | 'data' => [ |
||
| 202 | 'user' => [ |
||
| 203 | 'id' => '6cfb044c-9c0a-4ddd-9ef8-a0b940818db3', |
||
| 204 | 'name' => 'Alex' |
||
| 205 | ] |
||
| 206 | ] |
||
| 207 | ] |
||
| 208 | ], |
||
| 209 | [ |
||
| 210 | '{ user { __typename } }', |
||
| 211 | [ |
||
| 212 | 'data' => [ |
||
| 213 | 'user' => [ |
||
| 214 | '__typename' => 'User' |
||
| 215 | ] |
||
| 216 | ] |
||
| 217 | ] |
||
| 218 | ] |
||
| 219 | ]; |
||
| 220 | } |
||
| 221 | |||
| 223 |
Having each class in a dedicated file usually plays nice with PSR autoloaders and is therefore a well established practice. If you use other autoloaders, you might not want to follow this rule.