Improving conditions clauses – working on the code
It’s fascinating how very small changes can improve code readability. Bellow you can find some examples, which are often present in unexperienced programmers code.
Conditional operators:
Let’s say that we have a condition which looks like in this example
|
1 2 3 4 5 |
public function countWorkingHours($day, ...) { // ... some things in your code ... if ($day > 5 && $day) |
What is wrong with this code? The intention of the “if” condition is unclear – there is no explanation why we compare to specified numbers and what are those numbers.
Let’s see how it can be improved for better redability by using “Don’t make me think” principle:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public function countWorkingHours($day, ... ) { // ... some things in your code ... if ($this->isWeekend($day)) { // ... do something } else { // ... do something else } ] private function isWeekend($day) { $friday = 5; $sunday = 7; return $day > $friday && $day |
It takes more lines of code now, but it’s clear what the “$this->isWeekend($day)” condition is checking.
This is quite simple example, but many times the defined condition rules are more complex and this type of solution will make their intention clean for programmer.
Indentations:
“… if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program.” – Linux Torvalds, Linux kernel coding style
I like this rule a lot. It’s one of the code smells easy to find which say, that something needs to be improved in the code. So what does it mean? Let’s look at the example:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
function someFunction($some_array) { foreach ($some_array as $row) { // ... do something if ($this->someCondition()) { if ($this->anotherCondition()) { // ... do something continue; } // ... do something } } } |
What is wrong? You have too many nested code block here, which should be extracted to separated function or even object (depends on the logic).
Let’s see how it can be improved for better redability:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
function someFunction($some_array) { foreach ($some_array as $row) { // ... do something $this->proceedRow($row); } } private function proceedRow($row) { if ($this->someCondition()) { if ($this->anotherCondition()) { // ... do something return; } // ... do something } } |
Guard Clauses:
Many times I see code which look like that:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
function calculatePrice(User $user, Product %product, $discount = 0.0) : float { $price = 0; if ($discount == 0) { $price = $item->getPrice(); } else if ($user->isPremium()) { $price = calculateDiscountedPremium($item->getPrice(), $discount); } else { $price = calculateDiscountedDefault($item->getPrice(), $discount); } return $price; } |
It’s not so bad, and after a while it started to be even quite clear what is it responsible for. But can it be improved? Yes – and there are few ways how it can be done. First step – try to use early return and remove “else” block. After that the code will look like that:
|
1 2 3 4 5 6 7 8 9 10 |
function calculatePrice(User $user, Product $product, $discount = 0.0) : float { if ($discount == 0) { return $item->getPrice(); } else if ($user->isPremium()) { return calculateDiscountedPremium($item->getPrice(), $discount); } return calculateDiscountedDefault($item->getPrice(), $discount); } |
So a little bit less lines of code. now let’s change the if-elseif statements into guard:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
function calculatePrice(User $user, Product $product, $discount = 0.0) : float { if ($discount == 0) { return $item->getPrice(); } if ($user->isPremium()) { return calculateDiscountedPremium($item->getPrice(), $discount); } return calculateDiscountedDefault($item->getPrice(), $discount); } |
Very small change, but great impact – don’t you think?
Subsequent articles
- Static Factory Methods aka Named Constructors: Read more…
- Refactoring Example – guard clauses: Read more…
- Hard-coded parts: Read more…
- Dependency Injection code smells: Read more…
- Naming conventions: Read more…
- Improving conditions clauses – few small things with hudge impact: Read more…
- Clean Code – how to start: Read more…
