Challenging complexity
In the following text you will find some opinionated guidelines for reducing code complexity. The desired outcome is code that is easy to reason about and easy for maintenance. Just a heads up —there will be a lot of code to read ; )
1. Deeply nested code
One of the most important things for reducing complexity is having the least level of depth in your code. Cyclomatic complexity is a metric that you can use to track how deep in the rabbit hole have you descended. You can define some rules in your CI agent to help you with that. Besides all that fancy stuff, the code is much more easier to read and you can even split your editor and not lose half of the statements. A simple way to combat this disease is to abstract nesting into separate functions or inline conditional statements when they allow it.
Okay, the code that we are working with in this section is 5 levels deep. Check it out and tell me if you were able to read it or understand it:
Had fun? Let us try to remove some complexity from this code. Firstly, we can move the code responsible for getting the source of the event in a separate function. In addition, we improve the code for this functionality. Can you spot the change? The refactoring is marked with version 1 comment.
A small step towards our goal. What we can refactor next is the logic that handles the index attribute. Currently if we have a valid index we proceed with some more actions. There is no reason to nest the whole block into an if statement — much better is just to return if the index is not valid. Also we can gain some bonus points if we make our intentions clear with some reasonably named functions like Number.parseInt and Number.isNaN. The refactoring is marked with version 2 comment.
Wow! That change was great IMO. We removed three levels of indentation by just returning early instead of wrapping the logic in an if block. Just to make it clear those are the blocks that wrapped the whole code:
Can we improve it a bit more? I think we can! The check for the auxiliary key can be done without nesting in the else clause. Also we can extract the activation when SHIFT key is pressed. The refactoring is marked with version 2 comment.
Great! This code looks much better now. We can do some minor improvements but I will leave that one for you. What we achieved with this step by step refactoring is:
- reduce depth from 5 levels to 1 level
- reduce complexity level and improve maintainability index
- create code that expresses its intent
- ease of understanding
2. Simplifying conditional statements
Conditional statements are easy to write but people neglect the fact that they might not be so easy to understand if written in a bad manner. This includes checking too many statements, excessive usage of NOT operator and bad naming.
Read the following code and try to understand it:
Can you tell what this condition checks straight away? I can’t. It is quite intimidating in my opinion. Let us figure it out piece by piece:
I think that we are left with code that is much easier to understand than before. We removed all unnecessary brackets and the confusing NOT operator. We expressed clearly what we wanted to check.
Another thing that people often do is to write long conditionals. If you continue to improve the code shown in the first part you might end up joining the return statements into one condition that looks like this:
Again, can you tell straight away what exactly are we checking here? Much better would be to break down this conditional into chunks and give each of them a proper name so that we can easily understand it:
3. Function length
One thing that really reduces complexity is creating small functions with single responsibility. When functions are kept small there are not many statements and therefore they are easier to read and understand. An example would be the refactoring we did in the first part.
Officially that is the longest thing I have on Medium. Hope you managed to stay till the end and found it useful. Any comments are welcome ; )
