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.