Episode 15 of the Coder's Block podcast out now

The programming world is relatively split on whether more focus should be placed on code readability versus code complexity. As someone who's been working in the field for the past decade however, I have found code readability to be much more valuable for getting a project out to launch on time and for reducing the stress that can come with working on complex software.

The following are 5 reasons why I favor readability over complexity 90% of the time. There is a case for complexity at times, however I feel that has more to do with the type of work that you are working on. If you are working on secure systems for example or on datasets with incredibly large data points where you might not have the luxury of simplifying things any further.

Easier to debug with breakpoints

Breakpoints are a huge asset to any solid developer. Being able to stop execution at an exact point and inspect what exactly is going on can save you hours of testing and QA time down the road. By being more explicit with your code and the way that you define your variables, you can make this process much easier.

5 reasons to choose code readability versus complexity

Take the following for example:


var sum = getVal(sum) / (8 % 2) + (100 - sum / 2);

I'm sure that statement accomplishes what it needs to, based on the programmer that wrote. In this example, that would be me, and I made it up. But I've worked with many similar lines of code in the past. And whenever a test case failed, I was left to wonder where exactly in that line it happened. And this is where breakpoints come into play. The only option left here in order to fully test that statement is to split each component into it's own line in order to inspect its value dynamically.

Being able to test out code is a huge part of software engineering and development. Equally as important as coming up with complex algorithms. Sometimes, logic is difficult by its nature, but programmers can work towards turning that complexity into smaller chunks of logic that more people can work with. Something like the following might make more sense.


var divisor = (length % 2);
var offsetY = (100 - sum) / 2;

var sum = getVal(sum) / divisor + offsetY;

Different skill levels can work on it

Sure, that super complex new algorithm that you came up with is pretty cool. But at some point, you're probably going to leave your job. Which means somebody else will be working on this. And they may not be as amazing as you are. A big part of learning to program professionally, is learning to function in an environment with other programmers. And many times, you'll have people from junior to high senior level working on your projects.

If the aim in mind is to help out your company and your co-workers, then it is important to make their work easy on them. If logic is complex by its nature, then leaving a readable set of comments along the way can help anyone in navigating through the logic as well.


 if ( ! mouse.isDown) {
        // Do physics
        // Drag force: Fd = -1/2 * Cd * A * rho * v * v
        var Fx = -0.5 * Cd * A * rho * ball.velocity.x * ball.velocity.x * ball.velocity.x / Math.abs(ball.velocity.x);
        var Fy = -0.5 * Cd * A * rho * ball.velocity.y * ball.velocity.y * ball.velocity.y / Math.abs(ball.velocity.y);
        

In this example, you don't have to know about drag forces in physics, but you will able to work with the code and you will understand what each component to the algorithm is referring to.

Quicker to make updates

It is much easier to make changes to multiple lines of code, then it is to a single long and complex string. Particularly because you don't know of the consequences that can come with such updates.


var result = list.Single(x => x.Rank > GetRank(x.Score)).OrderBy(x.Score);

Something like this isn't too rare to find out in the field. The only issue here being if the logic ever needs to change, which it does, many times. I would only have this one line to work with, and making changes to one portion of the segment can inevitably lead to other items in the chain not functioning correctly.

Copy/pasting is simpler

Having recognizable code means that your code isn't that exotic pretty much.There's other's like it out on the web that you can relate to and learn from. Maybe your complex string isn't the most efficient compared to others. But it will much harder to identify that if it is hidden under unintelligible syntax. Copy and pasting is a big part of the programming world these days. We are no longer simply just adding a few numbers together and spitting out some output. We are manipulating tremendous amounts of data and sending it all over the place in order to generate a desired effect.

And needless to say, it's probably been done before by someone and it's been tested thoroughly. So many times, it's okay to borrow some innovation in the name of doing things correctly from the start.

More modular code

The complexity in algorithms many times comes down to the fact that giant multi-faceted parts of an equation get merged into 1 single cohesive unit. it functions in the exact same way in either regards, but in the more complex approach you are bypassing the separation of concerns route in order to achieve less code throughput.

In layman's terms, you are sticking everything together and making it hard for it to be split. Which means less re-usability. One of the most important things that I've picked up in a decade plus of software engineering is that code reuse is key to having a large and complex sustainable system. If there is something complex somewhere in your code, there is a good chance that you will encounter it again at some point down the line.

There is a time and place for complexity, for various reasons. For example, if you are in the research world and dealing with super complex data structures and mathematical formulas, then yes, you are expected to create and work with complexity. If you are working on a website that sells dog beds however, maybe it's okay to tone it down a bit. At the end of the day, you want to make your job easier for yourself and for those around you while keeping your companies profits going upwards. Then everybody wins. You do your job and feel proud of your work, your co-workers don't get frustrated working with your code and your company can continue to pay all of you to do your thing.

Walter Guevara

Walter G. is a software engineer with over 10 years of professional experience. When he isn't blogging or being a CTO he enjoys coding randomly complex things that he hopes many people will get a chance to use one day.

Have a question?

No comments posted yet

Add a comment

"sometimes you have to delete, to find your answer"
Copyright © 2018 thatsoftwaredude.com
humans.txt
Start
Score: 0
snake left
snake up
snake down
snake right