Coding standards
04 January 2014In the last few weeks, my current company has been in discussions about coding standards for the project I am working on, and for use as a whole company-wide. Coding standards are understandable because many programming languages place almost no bound on how unreadable source code can be made, as can be seen by one look at the OCCC, so at least some guidelines are required to keep things from getting out of hand. The problem is where the lines are drawn, and due to bad experience with coding standards in the past, I was somewhat sceptical whether they would be anything other than a road-block to progress.
Why they suck
My personal hatred of them is due to how often companies adopt a given convention without thinking it through, and the classical case is adopting Hungarian notation purely because it is what Microsoft supposedly uses. It does not help that there are two variants of this notation, and the far more common one is completely moronic in that it conveys information that is rarely news, and in some cases leads to more confusion. The prefix lpstr (long pointer to string) is not only long-winded, it is archaec given flat memory models used since..err Win95 (and the 1970's elsewhere).
Incidentally I am a big fan of the other variant, applications Hungarian, because quite often it allows mental grouping of variables and at the same time also given an indication of their role (idx, cnt, buf for index, count, and buffer respectively):
for(idxList=0; idxList<cntList; idxList++) bufList[idxList] = ...
Apparently the whole systems vs. applications dialect split is due to the systems lot at Microsoft screwing up the interpretation of the original Hungarian notation specification, and in the end the only way they could fix the resulting SNAFU was to officially deprecate Hungarian notation as a whole.
Wrong approach
Philosophically a major complaint of mine is that coding standards are a mis-targeted deployment of administration effort, because they do not come close to addressing some of the more severe issues with software development. At times they feel like an exercise in rearranging the deck chairs on the Titanic, because they are a cosmetic exercise compared to things like having a busted build system or disfunctional requirement analysis. The underlying problem is that writing good code is really a mind-set issue, but coding standards end up prescribing specific examples, and as they are usually top-down diktats they get applied blindly. I have in the past come across instances where following the letter of the standards actually made code worse rather than better, and ironically some of the worst program code I have ever seen was actually conformant to several coding standards, but that did not stop it bordering on being unfit for purpose.Python standards
The thing about Python is that the language itself drives people towards neat code, in large part due to use of indentation to delimit blocks of code, which does away with all issues related to bracing styles seen in most other languages. Python has also avoided the temptation to assimilate features from other languages in the same way Perl and C++ have. As a result it is a language that has a relatively small proportion of oddities with which to sting you, as it has avoided mixing philosophically different ideas.
However with PEP8, I think Python has started to stray into the area of religious fundamentalism, and I have a strong suspicion this is partly driven by consultants. This suspicion is because the use of snake_case, as most easily seen in the threading library, actually goes against the prevailing use of camelCase. The whole idea of Pythonic programming style, which amounts to not using valid languages features, even has a somewhat religious overtone to it. There is a whole graveyard of programming languages that got buried due to a dogged adherence to puritanism.
Hire one of the many Python language lawyers, like my company did, and you will inevitably have “problems” highlighted. Thing is that Python is relatively clean to start with, so this necessitates nit-picking. Naming conventions is one thing, but questions have to be asked when things like the position of whitespace in tuples comes into scope: (first,second) vs. (first, second) vs. ( first,second ). Any competent programmer should not have any major difficulty with this sort of variation. The biggest sign of a standards document being written by someone with too much time on their hands is complaining about trailing whitespace, as this is invisible.