indentation

[Don Christensen]

Brian J. Tarricone wrote:
> Don Christensen wrote:
...
>> 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...").

Yes, [X]emacs has saved me a number of times this way.

> 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.

This is a good example of why coding style/standards are really useful
(at least in my opinion) and how they can be crafted to reduce the
chances of error.  My personal preference is to allow for redundancy,
but that is because I like curly braces with one line conditional
blocks.

 > 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.

Okay, I'm going to reduce my credibility even further and show you a
snippet of my preferred coding style:

     if ( func_call( arg1, arg2 ) != ENUM_VALUE )
     {
         call_func( arg3, arg4, arg5 );
     }

Can you tell I like whitespace?  I'm not going to argue why I like
this style, especially since it seems to be so much less popular outside
the company where I used it than it was inside.

>> 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 ^_~.

Guilty as charged.  :)

> [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.
> 
...
> 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.

Yes, this is the one reason for using tabs that I can agree with.

> 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).

I completely agree with you on the mixed tabs and spaces issue.  [X]emacs
should never have shipped with indent-tabs-mode set to anything other then
nil.

I do have to disagree that using tabs and being able to change indents
will look consistent no matter what.  Consider the following code using
tabs set to two spaces (I've used spaces to make sure the examples
look as I intend them to):

   if (function_call_with_long_name(argument_one_with_long_name,
                                    argument_two_with_long_name)) {
     conditional_code_here;

Change it to tabs using four spaces and it looks like this:

     if (function_call_with_long_name(argument_one_with_long_name,
                                                                      argument_two_with_long_name)) {
         conditional_code_here;

Of course, you could craft your style to reduce or maybe even eliminate
this problem, where the two examples above might translate to:

   if (function_call_with_long_name(argument_one_with_long_name,
       argument_two_with_long_name)) {
     conditional_code_here;

     if (function_call_with_long_name(argument_one_with_long_name,
             argument_two_with_long_name)) {
         conditional_code_here;

I would argue that this is less than desriable.

>> 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...

I would never argue that you should change anything.  It rarely is worth
the effort to reformat a large amount of existing code.

>> 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 ^_~.

Oops, I should have read your reply all the way through before I included
the example of my preferred coding style above.  Now I wouldn't blame you
if you don't get this far  ;^)

Maybe it isn't so bad, because I can only use that style now when I'm
writing my own little perl scripts.  I haven't seen any code at work
that is anywhere near my preferred style, and I don't use that style
there.  I will say, though, that anyone who puts tabs into code generally
gets a stern warning at the very least during code reviews.

This has been a fun discussion, especially since it has been quite
cordial.  I think we both have done a good job of not getting overly
defensive about our personal opinions.  Not all such discussions go
so well.

By the way, welcome to California!

-Don

-- 
Don Christensen       Senior Software Development Engineer
djc at cisco.com         Cisco Systems, Santa Cruz, CA
   "It was a new day yesterday, but it's an old day now."