I simply cannot resist translating the last post in English. Here it goes.
Take a look at this post by Reg Braithwaithe. It is a short article delving into code writing conventions. This is a topic I have contemplated a lot on and I have a somewhat fascist outlook to it. This link is a great opportunity to share them with you.
In every project I have worked on, I endeavour to enforce Draconian measures for standard coding conventions. The reason – I’m very sensitive to code inconsistencies. I’d always organize everything after the same fashion – empty lines, brackets, splitting-up of long lines, different classes in the standard library and so on. Hence, I tend to notice all diversions – and I expect a reason to be behind them. For example, if I see an
ArrayList instead of a
LinkedList, I’m assuming offset indexing is a lot more important than linear iteration in the case. When I encounter a
while loop for handling an
Iterable, I’m expecting something more complex than „do the same thing for each item“. And when I see
for instead of an
.each in Ruby, I assume that the index variable is referenced somewhere after the loop body. And whenever that „convention“ is broken without a reason, this only taxes my attention and wastes my time.
Variations in a language, be it programming or natural, are a way of expressing information. „It’s chilly“ and „I’m shivering“ state the same fact, but sound different – the first one sounds somewhat cool (pun not intended), while the second expresses а stronger emotion. Programming languages share the same nuances even if they are not distinguished as much. Just as you avoid randomly accentuating your speech, you should avoid being chaotic when using the programming language tools. If you will do things in more than one way, then do them, but do them consistently. Style and method deviations are means of containing information and not means of self-expression –
for(;;) states you are going through each item in a collection, while
while states your code is iteratively going towards a given condition. Style deviation is not a method of demonstrating the aesthetical style of your poor and oppressed inner artistic self. Using one when the other is more appropriate is confusing and plain wrong.
This line of thought applies in full force to the dynamics of a team. If you’re one of those people who believe „differences in style should be tolerated, because this way you can determine who wrote the code“, you deserve to be shot (a little bit after you’ve been introduced to the concept of version control). Ideally, there should be no way to know who or when wrote a given piece of code just by reading it. Style nuances (different formatting, inconsistent naming scheme, arcane perversions) only create noise and obstruct the reading. Be a good pal and do things consistently – in the long run you all will feel better.
In short, style carries information. Worst thing you can do to information is to deprive it of meaning by using
rand() instead of reason, when applying style.