[TUHS] tabs vs spaces - entab, detab

[Jon Steinhart]

Andy Kosela writes:
> I am still computing in full screen text mode on CRT monitors, so it's
> 80 columns and 8 character tab as indentation for me.  It is a golden
> standard.
>
> >From Linux kernel coding style doc:
> "Tabs are 8 characters, and thus indentations are also 8 characters.
> There are heretic movements that try to make indentations 4 (or even
> 2!) characters deep, and that is akin to trying to define the value of
> PI to be 3."
>
> --Andy

Well, I suppose that I have to weigh in here before this discussion gets shut
down.

First of all, it's a shame that there isn't a nice global way to set system
tab stops.  I have a lot of aliases that pipe through "expand -t 4".

Second, while I agree with about 90% of the linux kernel coding style the
indent and line length parts are in the other 10%.  And from looking at
kernel code, while many may agree with the style doc they don't actually
follow it so I'm not sure what agreement means.

I always thought that the 80 character line length limit (now an amazing 100)
was silly; nobody was using VT-100s by the time that linux was developed.  Most
developers were born after the last one was relegated to a museum somewhere.
In that timeframe I had changed to using 132 column; I would have gone to 160
but not everybody that I worked with thought that it was worth whatever it took
to have a great monitor.  I have UHD on both my desktop and laptop which allows
a pair of nicely readable 132 column windows with room left over.  No longer
much of a cost barrier.

The big problem that I have with the linux style is that in addition to the
tab stop and line length restrictions, there is the weird belief that one is
doing something wrong if more than three levels of indent are needed.  From
what I have seen, this is followed by unnecessarily breaking up functions
combined with zillions of macros and static inline functions in header files
to give the appearance of only three levels of indent.  Bottom line to me is
that it makes the code unreadable, and if I have to choose an ideology it's
making the code easy to read for someone who didn't write it, not some slavish
adherence to a rule that doesn't make a lot of sense to me.

I think that line breaks hurt readability as they make it harder to mentally
process the block structure of code in pre-attentive mode.  I used to have
8 character tab stops and short (traditional one character) variable names;
now I've moved to 4 character tab stops and more readable variable names.

When I do need to break a long line, I indent the continuation line(s) one
character from the starting line to preserve the block structure appearance as
much as possible.  No additional indent makes it hard to distinguish separate
statements, two character indent makes it hard to tell which level the line
belongs to since it's halfway between two levels.

I do use tabs, not spaces.  Main reason, going back decades, is that I can
find a statement by searching for "^Ifor" which is distinct from any other
use of for.  For the same reason, I put function definitions in column 1
with the type on the line above, so that I can easily search for "^foo" which
is distinct from any invocations.

Anyway, whether or not you agree with this it works for me; my goal is to
make my code comprehensible by people who aren't as smart as I am because
I want to move on, not maintain stuff.

Jon