indentation

Don Christensen djc at cisco.com
Sun Aug 29 01:56:57 CEST 2004


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

Many apps (but again not ALL) for sending formatted output to a printer can
likewise be configured to expand tabs so as to make the code look okay.
So again, most people can go to some effort to configure their application
to print the code in a reasonable manner.

Many debuggers (yet again, though, not ALL) allow you to modify the width
of displayed tabs.  So most people can go to some effort to configure their
debugger to display the code in a reasonable manner.

Some?/Most?/All?/No? compilers, when outputting readable assembly listings
with the C code interspersed, allow you to adjust tab widths ....

I once worked in a company where the software director dictated that source
code use four-space tabs, because he used vi and could not make it insert
spaces appropriately when he hit the TAB key.  We had to use a DOS-based
debugger that could not be configured for tab width and was limited to
80 columns.  A third or more of the code was never visible in the debugger.
The situation is not quite so bad these days, but it still seems like a
potentially substantial waste of time to force anyone who works on the
code to configure all of their tools so that the code looks reasonable.

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.

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

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.

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



More information about the Xfce4-dev mailing list