Jul 5 2006

Elastic tabstop that ends the holy war?

Via Joel on Software, Elastic Tabstops is an attempt to use expanding/elastic tabstop characters to solve the tab-vs-space issue.

Yup. Tab or space. Or in the case of “space” — how many space characters? Also recently debated on wp-hackers mailing list when Matt released the WordPress coding style, every single programmer seems to have his/her own style. For me, a Python programmer who follows PEP 8 religiously, I like my code to have 4-space shift and every single line has to fit into 80 columns. Somehow it also affects me when I code in other languages…

Now back to elastic tabstops. It is basically trying to create “tables”, and it introduces the concept of “columns” together with “rows” or “lines” of text. A <TAB> character puts the following text into the next column on the same row, so that text in the same column aligns properly vertically. A new line character basically starts a new table with a different set of column width. Very neat.

Don’t think it is going to work too well with older editor that has fixed tab width. Not sure how it handles complex situations like “column-span” to allow omitting a tab or two.

I’ll stick with my Vim 7 for now :)

6 Comments

  1. Alistair on 11 Jul 2006 at 10:50 pm #

    I never really understood the debate over the tab versus space issue. I personally prefer to use tab, simply because if I want my tab to display with two, four, six, eight or eighty spaces – I change it in my editor and it displays it that way. When I give you my file, you can choose to display it differently and everyone is happy. The thing I don’t like about spaces is that it is fixed, if you like four spaces but I don’t feel its enough; then I don’t feel immediately comfortable reading your code (silly I know).

    Can you explain why you prefer spaces over the trusty tab?

    Al.

  2. Scott Yang on 12 Jul 2006 at 11:49 am #

    Tab as indentation has issue when space is introduced, or when you mix tabs with spaces. For example some people might prefer to indent this way:

    void buzz(void) {
    [TAB]foobar(argument_1, argument_2,
    [TAB]       argument_3);
    }
    

    When [TAB] is of different size, argument_3 on the second line will not align. One solution is to make [TAB] always 8 characters wide, or replace them with spaces so it always look the same across editors. Of course you can indent your code this way, which again would look “funny” but at least consistent across editors with different tab space:

    void buzz(void) {
    [TAB]foobar(argument_1, argument_2,
    [TAB][TAB]argument_3);
    }
    

    Or even forget about wrapping long lines at 80 columns.

    Problem also comes with multiple developers are editing the same file. Mix tabs and spaces are bad, especially with indentation-sensitive programming languages like Python.

    There are also “style guide” in various programming languages / open source projects. WP and Python were the examples I’ve used, and they usually try to enforce a rule on indentation.

  3. Charles Darke on 7 Sep 2006 at 4:09 am #

    Why bother with the new lines:

    void buzz(void) {
    [TAB]foobar(argument_1, argument_2, argument_3);
    }

    If you insist:

    void buzz(void) {
    [TAB]foobar([TAB]argument_1, argument_2,
    [TAB][TAB][TAB]argument_3);
    }

  4. Scott Yang on 14 Sep 2006 at 11:35 am #

    Why bother with the new lines

    Someone do work on 80×24 terminals :)

  5. Charles Darke on 16 Sep 2006 at 9:36 am #

    I do too, but having long lines isn’t a problem. When you have a long line, it just wraps and you can tell that it has wrapped since it wraps to column 0 whereas the lines above and below are indented.

  6. Jonathan on 7 Mar 2007 at 2:33 am #

    Meh. I use tab because I’m lazy. It saves me three clicks.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>