Conditions | 8 |
Paths | 36 |
Total Lines | 60 |
Code Lines | 35 |
Lines | 0 |
Ratio | 0 % |
Tests | 0 |
CRAP Score | 72 |
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 |
||
93 | public function update(EditDevice $request, $id) |
||
94 | { |
||
95 | $device = Device::findOrFail($id); |
||
96 | |||
97 | //Get the site id of the old or newly created site |
||
98 | if (!empty($request->input('new_site_name'))) |
||
99 | { |
||
100 | //Create a new site |
||
101 | $site = Site::create(['name' => $request->input('new_site_name')]); |
||
102 | $site_id = $site->id; |
||
103 | } |
||
104 | else |
||
105 | $site_id = $request->input('site_id'); |
||
106 | |||
107 | //Get the location id of the old or newly created location |
||
108 | if (!empty($request->input('new_location_name'))) |
||
109 | { |
||
110 | //Create a new location |
||
111 | $location = Location::create(['name' => $request->input('new_location_name'), 'site_id' => $site_id]); |
||
112 | $location_id = $location->id; |
||
113 | } |
||
114 | else |
||
115 | $location_id = $request->input('location_id'); |
||
116 | |||
117 | //Update the device |
||
118 | $device->location_id = $location_id; |
||
119 | $device->name = $request->input('name'); |
||
120 | $device->open_time = $request->input('open_time'); |
||
121 | $device->close_time = $request->input('close_time'); |
||
122 | $device->update_rate = $request->input('update_rate'); |
||
123 | $device->image_rate = $request->input('image_rate'); |
||
124 | $device->sensor_rate = $request->input('sensor_rate'); |
||
125 | //Check if the cover_command needs to be updated |
||
126 | if ($request->input('command') != null) |
||
127 | { |
||
128 | //If device is currently opening, closing or in an error state don't update command |
||
129 | if (!$device->isReadyForCommand()) |
||
130 | return response()->json("Device is currently in use.", 403); |
||
|
|||
131 | |||
132 | $command = $request->input('command'); |
||
133 | |||
134 | //If command is to unlock the device then check if the device should be open or closed based on the schedule |
||
135 | if ($request->command === 'unlock') |
||
136 | { |
||
137 | if ($device->isDuringScheduleOpen()) |
||
138 | $command = 'open'; |
||
139 | else |
||
140 | $command = 'close'; |
||
141 | } |
||
142 | $device->cover_command = $command; |
||
143 | } |
||
144 | |||
145 | $device->save(); |
||
146 | |||
147 | if (\Request::ajax()) |
||
148 | return response()->json(['success' => 'Device updated successfully']); |
||
149 | else |
||
150 | return redirect()->route('device.show', $id) |
||
1 ignored issue
–
show
|
|||
151 | ->with('success', 'Device updated successfully'); |
||
152 | } |
||
153 | |||
199 |
If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.
Let’s take a look at an example:
Our function
my_function
expects aPost
object, and outputs the author of the post. The base classPost
returns a simple string and outputting a simple string will work just fine. However, the child classBlogPost
which is a sub-type ofPost
instead decided to return anobject
, and is therefore violating the SOLID principles. If aBlogPost
were passed tomy_function
, PHP would not complain, but ultimately fail when executing thestrtoupper
call in its body.