Re: On Tabs and Spaces

tisdag 16 oktober 2007 skrev Michael Witten:

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