So lets jump directly into the topic why static analysis of methods is really important and why every developer should apply some thinking around the corner to make their code more failsafe.
As always, lets have a look at an example.
php public function someFunction(string $input): int { if($input === 'a') { $price = 1; } if($input === 'b') { $price = 2; } return $price; }
So if we now write PHPUnit Tests and check for our return values for each `a` and `b`, then we will end up with nice 100% Code Coverage. Great! Or not? The answer is simple: no! This code is actually not good. The internet is full of memes of QA Testers that will smack developers codes with arbitrary values. There is actually even a good joke:
A QA Tester walks into a bar. Orders 1 beer. Orders 99999999 beers. Orders -100 beers. Orders Apple Beers. The code does not fail. Then, a customer enters the bar and asks for the toilet. The bar goes up in flames.
So why is this joke so accurate? Because it reflects exactly the method that you can see above. We cover that our inputs are in a certain range. However, our example is slightly different. If the QA tester asks for "a beer", he will end up with 1 beer, since we match `a -> 1`. But if he asks for -1 beers or 1 beer even, or 99999 beers instead he will be presented an Exception! Why is that?
Because we have declared that our return type is `int`, but `$price` is undefined, so it would return `null`. `null` is not setup to be returned, so it throws the exception. So, rule of thumb is: we cannot be sure that our input is always correctly formed, follows under our assumptions and so on.
Now we can utilize a useful thing that we call `default` values. But lets go away from our Joke with the beers and have a look again at the faulty method. We declared that we work with a `value` to `price` mapping, basically. We have quite some possibilities to make this code better. The most obvious solution to this would be the following case:
php public function someFunction(string $input): ?int { if($input === 'a') { $price = 1; } if($input === 'b') { $price = 2; } return $price; }
Now, we have declared that our return type is `?int`. The return value can be `null` or any number. But does it really gives us a better code? No. The problem still remains - we should not have a null Price. We should have a default price. An simple way to make this better *and* easier to read is this:
php public function someFunction(string $input): int { $price = 1; if($input === 'b') { $price = 2; } return $price; }
But can it still be better? Yes! Since PHP 8.x we have `matcher` function available that is very easy to use, read and maintain. Instead of having this grown method, with matchers it would only look like this:
php public function someFunction(string $input): int { return match ($input) { default => 1, 'b' => 2 }; }
This looks so much better, doesn't it? And we have the guard in place that prevents us from having to deal with any null value, but we have implemented our cases correctly *and* we can very easily maintain this. Have a new case? Add 1 line (instead of at least 4, newline, if start, code, if close).
Also, we will always have our default value setup.
Clean coding is not just good for the developers. Its also good for the environment. Because clean code executes faster, thus costs less electricity, thus requiring less - probably - non-renewable energy sources. So, even if you're not interested in clean code but are in the environment, applying clean code will have a large impact. If everyone is going to clean their code, Developers will be happier, Shops will be faster, and less electricity will be consumed. A Win...Win-Situation, really.
Thats it for today, if you have any questions you can always send us a message. If you have developers in your team that look for some coaching or training, we're you're guys. Just hit us up!