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.
Thank you, very nice post. I’m sorry I could not read the original, with all of its native idioms and style.
I like the ArrayList/LinkedList convention which I usually don’t use, as I’m very often using an ArrayList as my default List implementation.
Your post makes me think about it twice and I wish you would translate more posts like that one!
Eric.
I could not agree with you more. My only disappointment is that there’s people who don’t think a consistent coding standard is so important.
Nice post, just a comment about your ArrayList/LinkedList statements.
While it were nice if you could so, you will actually almost never choose LinkedList because of the iteration type. If you chose LinkedList then because of the fast O(1) prepend and append operations when you don’t know the size in advance. But then: addition and insertion is amortized O(1) in ArrayList as well… Then think about the memory usage of the lists: While ArrayList has to preallocate some memory and is memory efficient when the size is known in advance, LinkedList has to allocate memory for every element in the list to store the pointers. So there it is almost everytime the best thing to choose ArrayList.
eg see http://joust.kano.net/weblog/archives/000066.html
Correction: ArrayList has only amortized addition, of course. So insertion would be a point for LinkedList.
YANA (Yet Another Nice Article) from you Stefan 🙂
Nice post indeed; now I’m slightly disappointed that you didn’t give any hint on how you „endeavour to enforce Draconian measures for standard coding conventions“. That’s a problem I’m facing right now. Checkstyle and assorted tools are too dumb to understand the reasons behind the possible diversions (and I’d hate to have to have to resort to ugly markup), and it seems common/good sense can only be trusted so much. Any tip?
You have a good point about how programming idioms and style convey meaning. However your tone and choice of words reveal some traits that are probably more counterproductive than mixing up „for“ and „while.“
You say „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….“ There’s no such thing as a „standard coding convention.“ There are lots of opinions about the „right“ way to write code, though. It’s important to distinguish between one’s personal preferences, obsessive-compulsive tendencies, and fetishes and the one and only „right“ way to do something. There’s nothing wrong with consistency and it can make team projects go smoother, but as Emerson said, „A foolish consistency is the hobgoblin of little minds.“ I would wager that more programming time has been wasted arguing about the „right“ way to place braces in C, or changing indents from eight spaces to four, than has been lost trying to figure out why a „for“ loop didn’t really need the index variable.
I agree with you that a chaotic style, with no apparent consistency, is the hallmark of an inexperienced or sloppy programmer. However I don’t agree that a programmer who fails to follow my personal style is necessarily doing something wrong. To turn Tolstoy around, bad programmers are all alike, but good programmers are each good in their own way. Rather than try to force another programmer to use my style (which is not practical anyway) I prefer to filter out the truly bad code and accept and learn from the good code.
I know it’s just a figure of speech, but proposing that people who believe stylistic differences should be tolerated „deserve to be shot“ is over the top and only detracts from the point you are trying to make. Even if we agree in principle I wouldn’t want to work with someone who has a „fascist outlook“ on style, imposes Draconian enforcement, and believes in capital punishment for offenders.