PHP Static Analysis during development to avoid bugs in code

Developers are a special kind of thinkers. Non-coders on the other hand side assume often, that coding is either black magic or "very simple". Every developer knows the phrase "just change this and that" from someone that has heard about SQL at some point during their career and now they believe they understand a developers work better than the literal developer. And static analysis is something very similar to a Manager with barely any coding experience who tells you how to do your job, and its impressively important to do it during development, for quite some reasons. Note: if you're a manager, stop telling your developers how to code, you're not a static analysis. :)

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: 

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;
}

So now we will return `1` always, unless our input is `(string) b`. Then, the price will be `2`. Thats a little bit better. Now, if we do the static analysis, we can be sure that we will always return something useful from `someFunction`. We will always receive a price back that might be correct, but code-wise we can't know. In certain business cases this might not be the ideal approach. Maybe, you really want to have `null` - in this case of course this example is not quite doing it. However for this very simplified example, it serves the purpose well. 

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!