Keep it clean – few words about coding standards

Keep it clean – few words about coding standards

Professionalism likes order and standardization. That’s a fact – enhanced organization boosts productivity and decreases the chance of failure. As an evidence let’s recall lean methodology invented and successfully implemented by Toyota. It is no different with the programming, caring of code quality and readability became standard and every developer wanted to be considered as professionals have to know and obey coding standards. Let’s look what kind of benefits we earn by keeping it clean!

Speaking of clean code, let’s mention formatting first. Actually, most of the nowadays IDE platform offers very clever and automated syntax correction, basically on a fly. It is a true convenience not having to care about all of that indentations. Of course, there are still technologies present on the programming scene, used quite often for whom editors don’t offer complex support – such as VBA, still very popular and extensively used, yet Microsoft Office built-in VBE (Visual Basic Editor) does not provide automated formatting. So even that risk of getting for pull request totally unformatted code is very low, let’s keep in mind that in clean code terms formatting is a very first step.

If You look into different programming languages, what is considered as a proper practice may differ? However, It is not that important to force one and only right standard for the whole IT industry. Apart from that, it’s nearly impossible to change immediately what was built and grown into given language community over even decades, it’s more important keep it unified in the limits of company, department, team and – getting lower – even within the project.

The main objective of keeping it clean is not esthetic perception but assurance of efficient work with what given developer (or team of devs) wrote. Creating code that is completely error-proof is realistically speaking impossible. There are tools and techniques for mitigating the risk of code failure such as detailed testing utilities, the culture of frequent code reviews etc. However, this one, little,

The inconspicuous unnoticed gap may cause a very expensive problem. Hard-to-read code creates the possibility of not enough attentive process of code review, and every missed error released for further release stages is basically waste of money for both, vendor and customer. Also, cooperation with the team is much easier when all of the developers stick to the certain agreed standard.

And in the end there is another factor – writing dirty code is simply… unprofessional. Unfortunately, in a day of rapid industry growth, as can be observed, many of new developers, ready for programming adventure are self-trained, home-made graduates. Actually, it is completely fine as the stack of knowledge that lays around the internet is such extensive, that for the stubborn person it is not difficult to obey junior-level knowledge in period countable in weeks. However, self-training creates the risk that there is lack of proper role models for such persons – including powerful knowledge how to write properly. Another group are devs who purposely ignore all the conventions and lay all it off at laziness. Well… Ignorance is bliss. And there is a special place in hell for them waiting.

Being a good professional is composed of many factors, and ability to write readable, the high-quality code is one of them. Remember that deep knowledge about given framework or architecture comes with hard work and time, but even simple solutions may be delivered with class and clearness. So, keep it clean!

Post a comment