Why Your Code Should Be More Than Just Good Enough, Actually Close To Perfect

Have you ever seen a perfect code in your entire life? What's a perfect code indeed? While many scholars and software evangelists are trying to answer this question in terms of software programming, Sergey Morenets, Ukrainian Java evangelist, decides to ponder over the feasibility of the perfect code concept from a different angle. This blog post is a shortened version of his online book The Perfect Code that was published in DOU.ua and translated by Intersog for a broader English speaking audience.

Perfection is a very sensitive topic. Is it possible to reach ultimate perfection in such a volatile and dynamic area as IT? Who should assess the level of code perfection?

I agree that IT is an industry with rapidly changing game rules: there emerge new programming languages, frameworks and platforms; programming syntax changes, etc. What stays intact is developers and users! I'm sure you've come across many books that delve deeply into software programing and explore its ins and outs from a pure software development perspective. But I don't think explaining what a perfect code is can suffice alone. Software developers should have in-depth understanding of why it's critical to deliver the code that would be as perfect as possible. For this purpose and in order to provide a more coherent and argumentative response, I suggest we dig deeper and remember that writing a code is just one part of the entire software development process.

But first off, let's take a look at software development from the viewpoint of all stakeholders it involves.

The essence of my story is - a perfect code is part of a perfect product, i.e. the better the code, the better the product.

How do we distinguish a "perfect product"? By its superb quality, of course! Speaking in software development terms, a quality product is a stable and efficient product with a very low number of errors and bugs (i.e. scope of seamless features and speed of response). By "stable product" we normally mean the quality of your QA process, as well as software maintenance and support (speed of issue tracking and resolution and speed of new features deployment).

For me, a perfect example of a perfect product is a Voyager spaceship that has been navigating smoothly through our Solar System since 1977, with no critical issues ever detected, and keeps transmitting valuable data back to Earth.

Now let's take a look at a software product through developer's eyes. The three key tasks they have to accomplish are:

• code reading,
• code modification, and
• code troubleshooting and deployment.

The faster developers complete their tasks, the fewer side effects your product will encounter, i.e. the sooner they'll release a new build and the faster they'll evolve as professionals. To top it all, any project code should have the following requirements:

• Code should be clean and readable
• Code should be easy to modify
• Code should be fast launched / re-launched on different operating systems (OS)
• Code should be re-usable and testable
• Code should contain minimum acceptable errors (or zero errors)
• Code should be stable once configuration / environment has changed
• Code should be secured

These keywords actually describe the perfect code: readable, obvious, precise, self-describing, modern, flexible, extensible, effective, scalable, safe, secured, cross-platform.

Obviously, we can't achieve all of these features right away, so a question of how to prioritize them comes to the forefront. Therefore, I've divided all these features into several groups based on their primary importance for the project success. As it turned out, the following group of features comes to be priority #1: readable, precise and self-describing code. Let's talk more about it now!

Readable code

Developers spend a lion's share of their time (sometimes up to 90% of time) on code reading. Considering the fact that software development is a teamwork, in most cases they have to read someone else's code (e.g. project code, external library code, JDK code). Nearly each developer can say at the first gaze whether the code is readable or not. In my opinion, a readable code is a code that can be easily understood no matter what piece of it you're reviewing.

Is code readability intuitive or can it be achieved by following certain rules and conventions? Here're some tips to consider:

• Use simple methods over complex methods
• Avoid nested loops and forcing quit-outs of the loops
• Avoid nested try/catch and anonymous classes
• Follow coding conventions of your programming language

Code readability is actually based on the volume of data that each developer should keep in mind to easily understand any line of someone else's code. Experience matters a lot here, so my advise #1 for rookies is to read as much of someone else's code as possible. To read and to analyze!

Let's take a look at this piece of code. Although it's rather understandable, it's hard to perceive anyway.

A slight modification significantly improves its readability, doesn't it?

Precise code

In my opinion, a precise code is a code that can't be shortened without bitching up other features.

Based on my own experience, I'd divide all cases of code precision violation into 3 groups:

1. Minor cases;
2. Code replication or violation of the object oriented programming (OOP) principles;
3. Misuse of API or programming language constructs

With that being said, code precision depends on each particular developer's skills and knowledge. The more in-depth API knowledge they have, the better they'll make use of it. It draws an interesting conclusion: while making your code re-usable, you automatically make it precise!

Collections can help improve code precision as long as you know how to use them properly! For instance, to create a list from an object, many developers do the following:

But this will be a more elegant version:

Getting back to code lines, I'm sure you've bumped into such code many times:

This code is quite understandable, however, if you make some changes to it, it becomes cumbersome. Thus, a more precise version would be:

It also works faster.

Self-describing code

If you're a software developer, you should belong to one of these two groups: one group believes your code shouldn't contain any comments, while the others think comments are critical for better code understanding. If you ask me which group I belong to, let's take a look at the following piece of code first:

What does cronExpression field contain? Not each developer can answer this question no matter how familiar they're with CRON. The second group developers would provide a comment to better describe the field contents:

Now it's clearer, isn't it? But what if you use the same expressions in other places down your coding road? You'll have to provide a comment in each particular case. And what if someone changes your cronExpression parameters? Is there a guarantee they'll update a comment accordingly? Well, you'll have to rely on another person's decency and spare time, as writing comments is time-consuming indeed!

What would a first group developer do in this case? They'd add a constant that can be referred to in any part of the project.

It looks like the first group is a winner! We've indicated there's a certain process that will launch each 2 hours. But now developers who review the code can have the following question: Why are we using such an interval? And that's where you can't do without providing a comment:

That being said, there's no clear winner!

Conclusion

I'm sure you've already pondered over the above and asked yourselves whether or not it makes sense to learn all those patterns, standards and methodologies while you can simply deliver a perfect code. If your goal is to finish the project, ship it to the client and forget about it forever, then you don't need to bother following all those industry accepted standards. And your result as a teamwork will be a big black box no one really knows how it works. In addition, this big black box will be fully unscalable and hard to move out of your team property. You'll either have to remove walls or cut the box in pieces to get it out of your team. And the result is predictable anyways.

Perfect code is neither a dogma nor an absolute truth. It changes each time your industry / niche changes. But writing a code that would be close to perfect is no rocket science, it's a matter of following particular requirements and programming standards.

And what's your take on this?

Featured image source: walldevil.com