1. Home
2. Blog
3. Ideal code

We often here about the ideal (or perfect) code. However, what is a perfect code? Has anyone seen it? From my point of view an ideal code is a code that meets all the software and programming requirements and standards. It also involves the best development practices and techniques.

Is it possible to define a list of attributes for the perfect code? I think that every company or even every developer has his own rules for the perfect code. Here is my favorite list of attributes:

• Readable
• Concise
• Obvious
• Self-describing
• Flexible
• Testable
• Scalable
• Effective
• Modern
• Secure & safe

Readability is the first feature. Developers spend 95% of their working time reading other people’s code. If the code is not readable then a reviewer will spend much more time reading it and will have less time to alter it. If a programmer can’t understand part of a code, he will rather rewrite it from scratch then spend time reading it over and over again.

Conciseness is the second feature. If your code is concise or compact then developers will spend less time reading it. The less lines of code you have the less bugs you can introduce.

Obviousness is the third feature. The source code is not a detective book where surprises are something you expect. Your code should be obvious for other developers even if they do not know you or your programming style. How do you achieve that? You should follow industry standards, principles and conventions. It is not a big deal but I have met many developers who tried to reinvent the wheel in their projects.

There are many debates going on whether we should write comments or not. Sometimes we should write comments but nonetheless comments are not linked to the code. Therefore, when we change a code we have to remember to alter the comments. That is why self-describing code is so vital. It saves us from double work.

Flexibility is the fifth feature. Successful applications can evolve for years or even decades. Each new requirement leads to design and code changes. Therefore, the more flexible your code is the faster you can change it and develop new features. Non-flexible code is mostly fragile. Every code change can produce a number of bugs or inconsistent system behavior. The non-flexible components are hard to support and in most cases easier to rewrite from scratch.

Testability is the sixth feature. Robert Martin once said that untested code is the dark matter of the software universe. Only test automation and relevant code coverage can ensure the adequate quality of your software product and minimize the number of the bugs. If the code is not testable then we have to spend more time creating mocks and stubs for the unit-tests. Thus writing tests for such code can be more time-consuming then writing the code itself.

Scalability is the seventh feature. Modern applications mostly deal with dynamic loading where resource utilization can change from 0 to 100% and even higher. In that case your code should not be stuck if loading is growing. For example, if your process execution time for 100 items is 1 second and for 1000 items it is 100 seconds then your code is not scalable.

Effectiveness is feature number 9. It is the only attribute that can be measured and tuned. It is not so easy to define code effectiveness during the code or design review. Because we often do not know in advance the resource size and usage. However, there are general rules on writing effective code and optimizing slow or non-efficient code. From the other side premature optimization is not recommended because it often decreases readability and conciseness for some average gains in terms of performance.

Programming languages are evolving. Each released version brings new syntax, features, libraries and best practices. They make code more concise, fast and easy to understand. It is very important that developers speak the same language even if it is a programming language. Therefore, my advice is to always be aware of the latest language features so that your code is modern and up-to-date.

Software components are like a black hole. You know the input or output parameters and you don’t know the internal processing details. Components are mostly reusable and state-full so the main rule here is that the code should be safe. Any invalid, incorrect, or missing parameters should not harm your code and make its behavior inconsistent for further usage.

Sergey Morenets
Software Development and Java Specialist