Re: On Tabs and Spaces

[Robin Rosenberg <robin.rosenberg.lists@dewire.com>]

[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]

tisdag 16 oktober 2007 skrev Michael Witten:
> What are the rules about tabs and spaces in source code?
> 
> I'm having a terrible time with formatting,
> especially in the perl scripts; there is a
> mix of spaces and tabs.
> 
> from what I can deduce, single tabs are used
> to introduce the equivalent of 8 spaces while
> 4 explicit spaces are used for half a tab.

A looong time ago I worked with a system that did not have *this* problem. 
The code had a straight left margin. No indent. The code was initially written 
just after the origin of time_t (content, not name) and that it was written 
on punched cards probably explains the left margin, efter all you can indent 
the cards if you like to.

I "accidentally" did indent code once, but only once, since I got a lot of 
complains from others about not following coding standards. My solution was 
to write a Brief macro to indent the code before working on it and undent 
before submitting my work to test. We never had a discussion on tabs vs 
spaces.

Btw, some of that code was "logically" indented 22 levels. I'm still amazed 
att those long sheets of code people annotated with pencil to discover the 
logical structure.

So it is possble to simply not care about tabs and spaces, except where
there is a syntactic difference.

Fast-formward twenty years and back to the topic.

I think it is ok to start or end a *big* series of changes with a re-format 
patch, iff the series already introduces a *lot* of changes. 

In the previously submitted and rejected patch to cvsexportcommit this
was not the case, I rewrote it heavily and that would have been a window
for for reformatting, but I didn't see a need, probably because I used emacs
and probably the original author too. Now I realize the file *is* actually 
indented inconsistently. Add to that that I am responsible for some of it. 
Next person to do any major work on it should submit a fix-indentation patch  
very much like the one MIchael did. The problem with reviewing such patches
still exists, it is not possible to just read such patches, one has to apply 
them and verify them with other tools.

I've been through enough many bracket and indentation discussions to see that 
it really doesn't matter as much what style is used as long as the same style 
is used throughout a whole source file. There are some coding styles that 
works bad with the patch/apply style  submitting code, but those are not an 
issue here.

As for TAB size. The most authoritative read "stupid") programs on the issue, 
i.e. cat (unix) and type (dos/windows) agree that tab stops are located at 
every eight position starting (8,16 etc).

Attached is an updated version of a script I've been using lately to clean up 
commits. First it only removed trailing whitespace, but after this thread I 
changed it to (try to) tabify changes. Should we use such scripts more 
actively to root out inconsistencies a patch at a time?

-- robin

[-- Attachment #2: washammend --]
[-- Type: application/x-shellscript, Size: 636 bytes --]

[-- Attachment #3: washtrailing --]
[-- Type: application/x-shellscript, Size: 535 bytes --]