Re: [Classpathx-crypto] quick comments on gnu.crypto code

[David Brownell]

> >     - Coding style ... three space indents?  No tabs?
> 
> 3 spaces is not so unusual, it does save some precious space if you want
> to keep your code within the common 80 columns range. 

And the counter-argument is that "four spaces" is much more common,
doesn't fight against standard 8-space tabstops, and is still "nicer" than
"indent == tab" for cases where nested code constructs "must" be used.

And I'll note that Linux coding style certainly says "indent == tab", and
notes that when that's awkward, the algorithm is the problem, not the
coding standard.  That tends to be very true, in my observation.  Kernel
code, like crypto code, is a domain where "simple is better" normally wins
against the more "deadline oriented" application domains where "done
now is better" wins ... it's "done now" that argues against restructuring
code to get rid of excessive nesting/indentation, and argues for narrow
indents.  (80/4 = max 20 levels/line, 80/3 = 26, either is too complex...)

Not that I want to start such style flamewars ... on the other hand
I think it's completely reasonable to say "three spaces" or "no tabs"
are guidelines that I've never subscribed to.  And I'll criticize them
every time it comes up, particularly when they're added as exceptions
to guidelines that are otherwise largely reasonable, since such style
guidelines do add up to 


> As for tabs, space is the lowest common denominator between editors.
> The brain dead ones display 8 spaces for TAB!!! and the good ones can 
> always be configured to emulate tabs with spaces.

Displaying 8 spaces for tabstops is not the same as storing them
that way.  Some editors will silently correct spelling "mistakes"
for you too, and store the results.  I don't like either behavior.  In
both cases using a Real Text Editor is a reasonable requirement.

Think of tabs as an 8-to-1 compression scheme built in to the
standard text file format.


> Many projects require "space only" for that reason actually (Apache 
> projects). 

The original motivation I heard for that was that a number of
early contributors didn't want to switch from Win32 editors which,
to this day, are often unable to handle tabbing correctly.
(MSFT discourages widespread use of monospaced fonts
and "ASCII art" tools.  Never mind that interop with other
operating systems gets worse that way.)

Many non-Apache projects still expect that Real Text Editors
will be used ... which know how to handle tabs! :)

- Dave