It is unarguably true that software development needs coding standard. A good standard can improve the efficiency of the development process and reduces unnecessary coding errors. But a bad standard can achieve just the opposite.
Developers from almost all companies adopt certain standards to some extent. But the usefulness of these standards can vary quite dramatically.
So, what is a good coding standard? While not getting into too much detail, here are my thoughts.
- A good software development standard should be concise : If a coding standard is presented to you in a thick binder, chances are that you will not fully memorize everything that you needed to know. A good standard should give you the high level requirement of the rules in software development and not the line by line rule teaching you how to write software (you should have learned that in school if you are a programmer).
- A good standard should be able to set up the guide-lines programmers must follow and yet give them enough freedom to be creative : If a coding standard is too rigid (e.g. here is how you should and the only way you should create procedures) then it is likely the creativity of each individual programmers would not be fully utilized and chances are you will not get the top notch product you had hoped. It is necessary to lay down rules that pertaining to the nature of the business (e.g. all errors must be logged in certain places in the database and sent to the operations department.) But you should always give the developers the freedom as to how a particular instance should be implemented (of course, existing code should be re-used whenever it is appropriate).
- A good standard should be expandable and allow changes to be made when necessary : Why we need to write code like this? Because the standard says so We hear about this kind of conversation way too often. As software evolves, standard should evolve along the way as well. There is no excuse to stick to certain standard just because it was written so. We should always analyze whether the standard is still in line with the state of the art software development. The golden rule of yesterday might not be applicable to todays way of writing code.
- Last but not least, a good standard should always favor coding efficiency : Writing efficient code is a great challenge for most of the developers. At the end of the day, given the same hardware, efficient code runs much faster and thus scales far better. The worst thing you can do is to retrofit efficiency to your existing code. It is not only a waste of time; but, guaranteeing the correctness of a large project is difficult if not impossible when changes are made simultaneously across the board. If a teammate suggests a much better (efficient) way of writing certain code, please make sure that his thoughts are well listened, even if the method he is using is not in the standards.
After all, standards should be created to facilitate software development not to impede it.
