Elastic Tabstops — An End to Tabs vs. Spaces?

An anonymous reader writes "Along with Vi versus Emacs, the tabs versus spaces argument must rank as one of the classic holy wars among coders. Here's an attempt to solve it by making tabstops expand or shrink to fit their contents. The concept's pretty cool to use, so be sure to have a play with the demo!"

Comments

How we got here

[Animats]

The way we got into this mess is that in early versions of UNIX, tab stops were set to 8 spaces in the TTY handler. This was not because tab stops were intended as indentation. It was because an ASR-33 teletype could tab that far in one character time. It was for optimizing output time. (Back in those days, TTY output processing had to have time delays to handle the mechanical lag in printers. "How many nulls were required after each carriage return" was an issue, and better systems kept track of the printing column position and adjusted the delay accordingly. Peripherals used to be really dumb.)

If some reasonable indentation value like 4 or 5 had been chosen, everything would have been fine.

Re:How we got here

[Mr Z]

Not just mechanical output devices. I wrote a TTY driver for a Viewpoint terminal that I was driving from an 8052. That thing needed delays all over the place. (Imagine my surprise, years later, to open one up and find an 8051 sitting in there.) I actually discovered it needed delays from the UNIX side of things, because the first thing I implemented was a serial-to-serial pass through, and I had to mess w/ the various stty delay settings before I stopped losing text.

But, yes... 80 columns goes back to Hollerith, and 8-column tabs goes back to an old teletype.... and yet these standards persist. :-) I personally expand all tabs to spaces just to avoid tab damage. I've gotten some horribly dainbramaged files over the years and never like being on the receiving end of that.

--Joe

Re:A standard tab length would be easier

[linvir]

Tabs versus Spaces: An Eternal Holy War.
Jamie Zawinski

My opinion is that the best way to solve the technical issues is to mandate that the ASCII #9 TAB character never appear in disk files: program your editor to expand TABs to an appropriate number of spaces before writing the lines to disk. That simplifies matters greatly, by separating the technical issues of #2 and #3 from the religious issue of #1

A very clever solution indeed. Apparently some clever bastard sovled this issue six years ago. Return to your homes. Nothing left to see here.

Re:From Wiki

[DesertWolf0132]

Vi came to fulfil the law of Ed as Christ came to fulfil the law of Moses. Come forth into the baptism of the Holy Vi and be saved!

Re:A standard tab length would be easier

[swansontec]

This is how I code, at least in C-like languages. You can set your tab length to whatever you want, and my sources still look pretty:

int foo ()
{
    //Every line starts with tabs:
    if (
        some_really_long_expression &&
        some_other_really_long_expression
    ) {
        DoSomethingClever(42);
        DoSomethingComplex(
            param1,         //Tabs start the line, spaces between param and comment
            param2,         //Comments line up, thanks to spaces
            param3          //Tab can be any length, whole line moves in or out
        );
        return -1;
    } else {
        return rand();
    }
}

Re:A standard tab length would be easier

[What is a number]

I am also of this camp, in that Tabs are only allowed at the beginning of the line. I do get complaints from others about this part:

1.
              param2, // Comments line up, thanks to spaces

if param2 changes (ie, imagine a more complicated line), you waste time re-aligning the comments. Of course, with tabs=3 or 4, you might also need to realign, just not as often.

The other complaint is similar - aligning #defines:

2.

#define Foo 17
#define BARBARBARBAR 18

people don't like aligning these by spaces - it just isn't as quick. Even I don't like using spaces here, but I do it because I believe in tabs-only-for-indenting as the best overall rule.

I'm tempted to either

A. find (or somehow customize) an editor that will change tabs to spaces ONLY in the middle of a line
or
B. make a hot-key that turns tabs=space on/off, so I can turn it on while doing #defines, then shut it off. So my #defines are aligned with spaces, but I used tabs to enter them.

Any other suggestions? 1. and 2. are the only arguments against tabs-only-for-indenting that I think are somewhat valid, and I'd like to get rid of them.

---
I type this every time.

Re:whether or not this solves the problem

[bogado]

I think that this is good, I aways thought that tabs for identation is simply a better idea just because it made simple for people to see the code the way they feel more conforable with. I don't think 'styles' is a problem, it is just the oposite, imagine if we could make a "style sheet" of some sort and apply to the code and sudenly all the code you load into your editor is styled as you liked?

I use the command line program ident to apply my style to other people's code, sure I don't send them this way I read the code and then just 'undo' before altering the file. But all of this would simply be better if we could style the code without touching it.

Re:whether or not this solves the problem

[mdfst13]

"imagine if we could make a "style sheet" of some sort and apply to the code and sudenly all the code you load into your editor is styled as you liked?"

Yeah, but people would still screw it up.  For example:

  // K&R style -- comments on the if/else go before
if () {
  // comments on the if clause go after the first {
} else {
  // comments on the else go after the else {
}

  // BSD style
if ()
{
}
else
{
}

  # Conway style
if () {
}
  # This also is a problem with BSD, but I thought I'd put it here.
  # Comments on the else clause go between the closing } of the if
  # and the else {.  Net result?  Hanging elses.  I.e. someone removes
  # the if () {} but does not realize that there is an else.  Further,
  # since an if can only be closed by lookahead, this results in real
  # oddities, like the else clause attaching to the previous if.
else {
}

I find the last to be the single ugliest syntax.  The theory behind it is that it is best to put keywords in the left most column.  However, the problem here (IMO) is that an else is irrelevant without the surrounding block structure and the if.  Thus, IMO, it makes sense to write it } else {, as that indicates that the } does not close the if; instead it closes the if true clause before opening the else not true clause.  I actually prefer BSD as being more consistent.

Anyway, the problem that your stylesheet would have is that the syntaxes are fundamentally incompatible.  In BSD and Conway, you can put line comments (//) after the } and before the else.  In K&R, you can't.  Now, you might argue that the stylesheet could move the comment.  However, if you do that, then you lose information.  Why?  Because any other location for the comment in K&R already has an equivalent in BSD/Conway.

What's really needed is a single, canonical way of formatting saved code.  Then developers can apply the stylesheet to the canonical form when viewing.  This canonical way would have to prohibit those practices that only work in some of the representations but not others, e.g. comments in between } and else.