This post is not about transformers and the complexities of Galvatrons right hand transformer Cyclonus or anything else Decepticons related, sorry.
Sonar for example calculates the cyclomatic complexity of the code. If you want to know more about cyclomatic complexity feel free to google it. I was not aware of the term until I came across it in Sonar and I claim that I still do not understand it well. How I see it, it affects the complexity of the code which then affects the readability and maintainability of the code which I try to keep in high regard.
Now there is something that affects the cyclomatic complexity of the code which I see unfortunately much these days. For example the project I am currently working on has a lot of legacy code and new commits even follow this style that I do not like much. It’s the if-else style. If you have much of if-else blocks, possibly much of them being redundant, you increase the cyclomatic complexity which increases the understandability of the code. Now what’s wrong with this style? Glad you asked!
If you control the flow of a method, or a member function, with if-else if-else statements you make it more complex and the flow becomes kind of like a tree. Each if or else is new branch in that tree. Although the method might be quite small and understandable it still is a tree with branches, not so straightforward when you would picture the flow. Several exit points that can be somewhere in the tree structure. Thus making it more complex. I think this is one issue (or perhaps the only issue) that cyclomatic complexity calculation tries to tackle. The simpler your methods are the better. Each time you are changing the control flow of a method with if-else or something else like exceptions, which is bad practice, but I’ve seen it too many times in production code, think of the flow as a straight line going from up to down and when ever this change in the flow happens you split the into two new directions, the left (if) and the right (else) and this pattern continues. This can be manageable if you keep your methods short, but it is still bad practice and the cyclomatic complexity of your code still increases no matter how short your code is.
Now for the style that I tend to favor. Instead of having these changes in the flow how about trying to make the method execution as straightforward as possible? Now consider you make a shiny happy method that works perfectly because everything is perfect. The flow of the method is straight as it does this one thing and does not start wandering around in cases and special cases of the cases which are cases of special cases. Now draw the control flow of the method. It should be a vertical line going from up to down, nothing else. If you achieve this you are almost there. Of course you might start to wonder if everything isn’t that perfect? If there are some error cases? Invalid input? Ok now follow the flow of the method and wherever you see a point where some failure can happen then handle that. For example validate the input. If the input fails, exit. You call some service and it fails, then exit (or let the possible exception propagate). Now each time the execution fails and you exit do not split the line into branches of a tree. Instead draw a horizontal line from the vertical line that visualizes the execution flow to left or right it doesn’t matter. You can even come up with some notation to indicate that the execution of the method has exited. Now compare the two drawing that you didn’t actually do. The other one is a tree, a more complex structure almost like a fractal, and the other one is a straight vertical line with little horizontal lines sticking out of it, a less complex structure.
I could even claim that if you do the same method using both styles of coding the latter one, the one based on the vertical line, has less code than the other one and is more easier to glimpse through. Reading the code is like you just read it line by line to see what happens and if error happens you know it where it is relevant.
Maybe this is common way of writing code, but as I mentioned in the beginning I have seen these if-else if-else blocks with redundant else blocks in the legacy code of the project I am currently working on, but what worries me is not that, but the fact that the style continues in the newer code. I am not even sure about all those legacy jewels of the crown that how legacy are they. One thing I also do not like is the frantic banging of the keyboard to get as much code as possible. That gets you nowhere nice (unless your boss appreciates that kind of bs) and clutters the code quite quickly. The less you write code the better. Maybe it is an art of its own to write less code than to produce as much code as possible like you were fourteen tucked away in your darkened room avoiding social contacts. Well if you are that remember that if you want to make a living out of programming you have to think about others, with your manners and your code.