A talented software developer, Jack, has the ability to write clean and efficient code, but he’s facing a new challenge: balancing the need for code readability and code performance. On the one hand, he wants to write easily understandable code that is easy to maintain, but on the other hand, he knows that his code needs to run fast and efficiently.

Jack developed a systematic approach to finding the balance between code readability and performance wherein he starts by understanding the requirements of the project and defining the scope. Based on this, he assesses the size and complexity of the code and determines the level of collaboration required from other developers. He then decides which aspect, readability or performance, should take priority for that particular project.

When Jack prioritises code readability, he takes a human-centred approach to coding. He uses descriptive variable names, proper indentation, and comments to ensure that the code is easy to understand and maintain. He believes that code that is easy to understand is more likely to be correct and less prone to bugs, saving time and resources in the long run.

However, when Jack prioritises code performance, he takes a more technical approach. He focuses on optimising the code for speed and efficiency, even if it means compromising on readability. For example, he may use abbreviated variable names or forego comments to reduce the amount of code and make it run faster. Jack understands that code performance is critical for projects that require high-speed computation, real-time data processing, or other resource-intensive tasks.

But are there any principles that developers like Jack can follow without juggling between performance and readability of code? Moreover, is there any reason that developers would choose one over the other?

SOLID, DRY, KISS

Just like any other field of science and engineering, programming also has some basic principles that govern good software engineering.

The KISS or ‘Keep It Simple, Stupid’ principle is to remind all developers that application design and deployment should be as less complex as possible. The procedure should be easily understandable and easy for other developers to debug whenever required. This ensures that the code is maintainable in the future. 

Next principle is called DRY or ‘Don’t Repeat Yourself’. It means exactly the same. Every developer should aim to reduce repetition of information within their work to avoid redundant code. This can be achieved by converting and segregating the entire system into smaller fragments for helping manage the code, and recalling it whenever necessary.

SOLID principles come from and for design. These sound philosophical, but when implemented while coding, make the code easier for collaboration, modification, and troubleshooting for bugs and issues. 

• Single responsibility principle means that every module should carry out a one responsibility, instead of complicating it.
• Open-closed principle states that any part of the system should be easily extendable by adding further features.
• Liskov substitution principle states that objects within a program should be replaceable with instances of their sub-category types without altering the accuracy of the program.
• Interface segregation principle suggests that it’s best to avoid adding new methods or functionalities into an existing interface. On the contrary, it’s better to incorporate a new interface and allow the classes to implement different interfaces depending on the need.
• Dependency inversion principle says that design patterns should be resolvable by using dependency injection.

What’s the Verdict?

Code performance is critical, especially when working on projects that require high-speed computation and real-time processing. This can result in slow and sluggish user experiences. But focusing on the performance of a code that is not readable is useless. Moreover it can also be prone to bugs and errors. 

Performance is a quirky thing. Starting to write a code with performance as the first priority is not a path that any developer would take, or even recommend. In a Reddit thread, a developer gives an example of a code that compiles in 1 millisecond, and the other code in 0.1 millisecond. No one can really notice the difference between both the models as long as the code is “fast enough”. So improving the performance and focusing on it, while sacrificing the readability of the code can be counterproductive. 

Moreover, in the same Reddit thread, another developer pointed out that writing faster algorithms actually requires you to write harder code oftentimes, which again sacrifices the readability. “Performant code relies on clever tricks,” the user said. High performance code is oftentimes not related to the objective that a developer has, but just focused on improving the performance. Making lookup tables, hashing stuff, or doing manipulations like building up a cache, just for making the operation speed up, is just divergence from actually trying to make the code work.

So ideally, the approach, when writing code, should be that the code must work first, then make it good, and then worry if the code should be fast, or just “fast enough”. Speed is not as important as the programming process to be memory efficient. It becomes a concern when it becomes a concern.