How to get your manager to approve refactoring? Avoid accidental bugs, and write code that is easier to understand? I'll give you a #QuickAnswer.

#programming #tech #softwaredevelopment #developer #sde

Clean Code (R. Martin) - US: https://amzn.to/3jVUEDU | UK: https://amzn.to/2Iij4Jz
Best Practices for Programmers - US: https://amzn.to/2SPRSEg | UK: https://amzn.to/2Fr2h6e

What is Cyclomatic Complexity in software development?

When you start your adventure with coding - you might think that writing complex code is something that very advanced programmers do. The more you learn the harder problems you can solve, and therefore - your code is more complex.
Well, it’s exactly the opposite - we always strive to produce the simplest, most elegant and easy to read programs that will achieve the objective with the least amount of steps. This kind of software is cheap to write, maintain and extend.
But how exactly can we measure the complexity of the code? Should we do it by number of lines of code, or maybe the amount of files? The quantity of network connections or endpoints in API?
All of these could be good indicators that something isn’t right with your project, but we also have a metric that helps to measure how complex is your source code. The technique invented by Thomas McCabe almost 50 years ago is hugely underestimated today, but can be very effective in detecting which bits of your repository should be refactored to avoid costly bug fixes and customer tickets.
Cyclomatic Complexity measures the number of linear paths through a piece of code: branching points: if/else/switch statements, loops and jumps. The higher the complexity - the bigger the chance something breaks.
There are at least four reasons to avoid it: Cognitive burden, Unpredictability, Fragility and Bugginess. You can probably guess what they mean: you will have hard time reasoning about the code paths; hard time tracing all rare situations, hard time changing your code and you’ll introduce bugs without noticing. All because you have too many nested control structures.
How to avoid this kind of complexity? Avoid more than one if/else conditional in your method. Refactor multiple sub-conditions into separate methods. Don’t any more if-statements in a switch statement. And don’t put yourself in a situation where you have 10 case statements for a single switch block!
There are tools available for almost every language to compute the complexity with some customised version of McCabe’s metric, but just to give you a rough guide, here is a little scale on where things are: 1 to 10 - not complex, 11-20 - bit complex, 21 to 50 - really complex, and over 50 - is too much.
You can add them to your build pipeline and check periodically if your solution hasn't regressed to something that will be a pain to manage very soon. Such tooling has a very good upside: when you bring objective results to your manager it’s hard to argue that we actually should look into refactoring it. Well... It’s harder to argue.
Remember that this won’t say anything about performance of your code, and vice-versa. Potential bottlenecks affecting resources like CPU or memory should be measured separately.
May your code be simple and free from bugs. Subscribe, and I’ll see you in the next one, cheers!