you picked an borderline case without showing the full effects of your
choice of style - but still even in this example you are wrong i
believe. Look at how inconsistent this looks:
for (i=0; i<10; i++) {
l = 10;
if (k <= 10)
k = 11;
}
(the inconsistent 'i=0' versus 'l = 10')
so in your style we'd have to write it as:
for (i=0; i<10; i++) {
l=10;
if (k<=10)
k=11;
}
which, on one hand, looks unprofessional (in fixed width font), but on
the other hand, the literals and operators are way too "close" to each
other and operators are easily missed and mis-identified visually -
causing bugs.
For example the 'k' and the '<=' operator may look visually similar and
can be "blended", making it easy to skip over 'k=10' versus 'k<=10' -
while 'k = 10' clearly stands apart from 'k <= 10'. [and syntax
highlighting does not help with this particular problem]
in Documentation/CodingStyle it looks:
for (i = 0; i < 10; i++) {
l = 10;
if (k <= 10)
k = 11;
}
which is certainly reasonable and groups safely.
yes - you can have arguments one way or another, but there's nothing
worse than maintainers each going towards their own _arbitrary_ and
often clearly inferior coding style, which is inconsistent within the
same file.
I at least make the point that i'm trying to converge to
Documentation/CodingStyle. Is it arbitrary? Yes, to a fair degree, but
it certainly conveys a very strong, unambiguous sense of taste.
Ingo
--
