Exceptional coding style

[H. S. Teoh]

On Tue, Jan 15, 2013 at 10:58:47AM +0000, Russel Winder wrote:
[...]
> Go has an extreme position on this, there is one and only one style of
> code that is acceptable, the one defined in the gofmt program that is
> used to format all Go code. I happen not to like some parts of it, but
> I live with the enforced style.
> 
> Python is less extreme, in that there are many styles of code allowed,
> but there is PEP-8 which is "Python style as Guido intended".  This is
> supported by the pep8 program for enforcing elements of style. I have
> disagreement with some of the choices, but I live with it, and format
> my code to PEP-8 except for the line length rule – which is just so
> 1980s.
> 
> C, C++, D, Fortran, Groovy, probably need to learn a lesson from one
> or other of these.
> 
> The issue is that having a single global style standard for a
> programming language makes it easier to read code in that language.
[...]

I used to despise Python, because of its imposed indentation
conventions. But after I started using SCons, I acquired a liking to the
"whitespace thing". It's actually very nice to be able to indicate
nesting just by whitespace alone. No need to worry about pathologies
like }'s on the wrong line, leading to wrong indentation and misleading
code appearances, etc..

I used to hate being forced to code in any other style than my own, too.
But after working with my previous supervisor, who used what I
considered an overly verbose style, I started very much liking the fact
that the code is so easy to read, and identifier names so easy to guess.
There were no creative (aka inconsistent) abbreviations, shortcuts,
etc., everything followed a predictable scheme, and declarations and
wrapped lines line up correctly. You didn't even have to know much about
the code to be able to correctly guess what it does.

Compare that with the other project that I worked on, in which
everything was in terse C coding style: inconsistent abbreviations
everywhere, unhelpful local variable names, gratuitous omission of
whitespace, etc..  It was anybody's guess what a piece of code actually
does. Sometimes, when enough pointer-to-struct-of-pointers-to-structs
coupled with tables of callback function pointers (with unhelpfully
terse names) which are initialized by calling tables of function
pointers which are initialized in diverse obscure places, the exact
location of which depended upon runtime parameters, it was impossible to
understand what the code does even upon a careful reading. Needless to
say, plenty of bugs abound due to people not understanding what exactly
the code is doing.

Having a global coding style annoys most programmers (probably because
it insults their creativity), but it does a world of good when you're
working in a large collaborative project.


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its flaws.