indentation

[Brian J. Tarricone]

Don Christensen wrote:

> I'm going to try to restrain myself from getting too involved in
> this discussion, but I feel compelled to add a cent or two...
>
> Brian J. Tarricone wrote:
>
>> Olivier Fourdan wrote:
>
> ...
>
>>> - I use curly braces even if there is only one instruction after an
>>> if/while/for because I find it easier to read,
>>
>> that's just a personal preference thing i guess, because i find it 
>> somewhat the opposite.
>
> In my experience, always using braces has prevented more than one bug
> when a macro is used that expands to multiple lines or code is modified
> to add another line into the conditional block without adding the
> braces.

i'll agree with you on the second point - but that's just a matter of 
not being sloppy and paying attention to what you're doing.  an editor 
that autoindents helps a lot here ("huh?  why did it not indent it out 
to the if-block level?  oh, right, forgot the curly brace...").

as for macros, people SHOULD be writing multiline macros like this:

#define MULTLINE_MACRO \
do {\
    some_stuff();\
    some_more_stuff();\
} while(0)

that way,

if(some_condition)
    MULTILINE_MACRO;

will expand correctly (sure, the generated indentation will be messed 
up, but there isn't much you can do about that).

this is a widely-used technique, and i've seen it recommended all over 
the place (google for examples, if you care).  sure, there are macros 
written by other people that you can't control that may not follow this 
convention.  but, for my preference, i just make sure to double-check, 
as i think adding extra braces decreases readability greatly, and wastes 
space (especially for people that don't like to put the braces on the 
same line as the if/else statement).  the double-checking isn't really 
much work, as i find that the intersection of 1) multiline macros i use 
(hell, macros period), and 2) if/while/for blocks with only one 
statement in the body, tends to be a very small set.

>>> - I expand the source because I don't want tabs. Some editors use 4 
>>> or 8
>>> caracters for a tab and that really break readability
>>
>> don't most editors (at least any that are actualy worth using) let 
>> you set the tab width?  this is why i like tabs so much.  i prefer 
>> 4-char indentation, and that's what i tell my editor to display tabs 
>> as.  but if someone else wants to look at the code, and they prefer 
>> 2- or 8-char indentation, they can easily tell their editor to 
>> display tabs that way, and be able to read the code comfortably - 
>> without impacting anyone else.
>
> Tabs are horrible evil scurges!  Sure, most (but by no means ALL) editors
> allow you to modify the width of displayed tabs.  So most people can 
> go to
> some effort to configure their editor to display the code in a reasonable
> manner.

horrible evil scourges?  methinks we have a dirrrrty rotten style zealot 
on our hands, yesss precious ^_~.

[snip: a bunch of good examples of places where you might need to read 
code ouside an editor that often don't let you change the tab-width value]

these are a lot of good points, actually, and i'll admit many of these 
had never even occurred to me.

> True enough that using tabs allows a user to change the displayed code
> indentation without actually changing the code, but I suspect you will
> find far more programmers who are okay with looking at 
> four-space-indented
> code than are okay with actual tabs being used for indentation.  The only
> other argument in favor of tabs is that it can reduce file size, but I
> find it hard to believe that anyone would seriously try to use that as
> justification.

granted, few people (from what i've seen, anyway) use 8-space 
indentation, so it's not a problem, but i know _i'd_ appreciate it if 
someone who did would use tabs, as i'd hate to read code with 8-space 
indents.

i suppose my biggest problem with spaces is the inconsistency.  not to 
point fingers, but large portions of libxfce4util and libxfcegui4 are 
unreadable to me because some places have mixed tabs and spaces, and, in 
the case of gtk-style indentation, this has the indentation all wrong 
when using an editor that displays tabs at 4 spaces.  for the curious, 
here's what some sections are like:
1 indent:  4 spaces
2 indents: 1 tab
3 indents: 1 tab + 4 spaces
4 indents: 2 tabs
so to me, i see this on my screen:
1 indent: 4 spaces
2 indents: 4 spaces
3 indents: 8 spaces
4 indents: 8 spaces
it's really nasty and really hard to read.  and since i often have 
multiple files open with different standards, setting the tab width 
(which is global in my editor) will make my code have 8-space indents 
for everything, which i hate.  if unreadable stuff like this could be 
eliminated, i wouldn't mind it if everyone used spaces.  for example, i 
have no problem reading linux kernel source code, as they seem to be 
very consistent, at least inside modules.

i guess my feeling is this:  using tabs will always look consistent (in 
a text editor, at least), no matter what, and it's configurable to a 
person's taste without affecting anyone else.  using spaces will look 
consistent as well, but only if everyone editing the file uses the same 
number of spaces (and it's not configurable to taste without 
reformatting the file).  using a mix of tabs and spaces only looks 
consistent if everyone else has the same editor settings as the original 
author (and again isn't configurable without reformatting the file, 
which some tools may have trouble with since it's rather confusing).

> That being said, I have no problem with you using whatever standards you
> feel are best for you.  It is, after all, your code, and I am grateful
> that you have chosen to share it with us all.  It has improved my life
> to some extent (at least the 
> sitting-in-front-of-a-computer-all-day-at-work
> aspect of my life).  But I also have no problem in presenting an argument
> intended to convince you that your stated preference may not be the best
> choice.  :)

i'm beginning to see what you're saying here, and i'm somewhat compelled 
to use 4-space indents, but not enough to change what i already have.  
we'll see...

> Sorry, but coding styles/standards are one of those hot-button issues 
> that
> I can't seem to keep my mouth shut about.  More than once this has caused
> me much extra work as I was drafted to write (and defend!) such standards
> in companies where I worked.

i certainly understand - we all have our pet-peeves, and they can get 
easily intensified when we've spent a lot of effort in the past 
defending them.  i'm not even going to start talking about how i feel 
about curly-brace positioning and spacing between function names and 
arguments, etc., as i'm sure that'll just make matters worse ^_~.

    -brian