Coding guidelines and the spaces-versus-tabs holy war

Logtalk, like most programming languages, defines a set of coding guidelines that aim to improve the quality and readability of source code:

https://github.com/LogtalkDotOrg/logtalk3/wiki/Coding-Guidelines

These coding guidelines are also mandatory for contributions to the Logtalk distribution. Most guidelines in the above document are pretty consensual but one of them, source code layout and indentation, always stirs a lot of discussion:

Format your source file using tabs, not spaces.

Search the web and you can easily find passionate texts defending the use of either tabs or spaces for source code layout and indentation. Recently, I was commenting on a paper on Prolog coding guidelines that stated:

2.1 Indent with spaces instead of tabs.

You cannot normally predict how tabs will be set in the editors and browsers others will use on your code. Moreover, mixing tabs and spaces makes searches and substitutions more problematic. All in all, it is better not to use tabs altogether: almost any editor can be set to substitute spaces for tabs automatically when saving your file.

Take the first sentence. It completely misses the point of using tabs instead of spaces. Try this. Open any of the many examples distributed with Logtalk in your favorite text editor. The example source code is formatted using tabs. Next go to your text editor preferences and adjust the tab size to your liking. I prefer a tab size equivalent to 4 spaces. You may prefer a tab size equivalent to 2 spaces. Or 3 spaces. Or 6 spaces. No matter your choice, the code will remain perfectly indented. That means that I’m not imposing on you my indentation preferences. If someone gives you a file indented using spaces, say, where an indentation level is 2 spaces, and you prefer to use 4 spaces, your preference will be ignored. You will need to edit the file, i.e. change it, even if only for you to feel comfortable reading/studying the source code.

If you think that my argument is only meaningful for text editors but not for browsers, well, think again. I have written (and tested!) support for syntax highlight of Logtalk source code for Pygments, GeSHi, Highlight, Source-highlight, and SyntaxHighlighter. If you’re publishing source code on a web page, a blog, or a wiki, chances are that you will be using one of these syntax highlighters. As you already guessed, they allow you to set your tab preferences. Never found a problem due to the use of tabs instead of spaces.

I have also written (and tested!) Logtalk syntax highlight support for several text editors, including TextMate, SubEthaEdit, Emacs, Vim, Kate, Gedit (i.e. GtkSourceView), NEdit, and jEdit. Again, never found a problem due to the use of tabs instead of spaces. This, I concede, may not have always been true in the past but, nowadays, using spaces for indentation is just a big waste of space. And obnoxious to all people you may share your code with that don’t necessarily share with you the same preferences for the size of an indentation level.

As this post is about a holy war, it’s mandatory and good netiquette that I finnish it with a suitable insult or inflammatory remark to the other side. So, death to the tab infidels! May your spacebar burn in hell!

Share/Bookmark

13 Responses to “Coding guidelines and the spaces-versus-tabs holy war”

  • Roberto Bagnara

    STOP!

    What madness is this?

    You have a nice convenient spacebar in your keyboard, don’t introduce tab crap in your code.

    Do we have a tab key in mobile phones? No. Do we want to wonder how wide the tab size will be in the editor/browser/whatever we will use one year from now? No. There has _never_ been any problems with spaces.

    You can write a program to convert spaces to tabs _anyway_, so do the only sane thing, and use spaces everywhere, and get rid of that stupid and horrible tabs which only buy you pain, editor configuration work, extra code, and a black star for being stupid.

    [ http://lkml.org/lkml/2002/6/6/87 :-D ]

  • Roberto Bagnara

    Seriously now :-D

    I disagree. It is true that you can set the tab size in various tools (not all of them), but only one setting is guaranteed to reproduce the alignment the original author intended. Of course this problem is technically solvable: text files may have an attribute saying “this text has been formatted for a tab size of X”, or this information may be put in a comment in the file itself. All in all, even if you do that, the only advantage over using spaces would be a negligible memory saving.

    Suppose now that you don’t care at all about the layout chosen by the original author. What you may want is a pretty-printer/code-beautifier that does more than playing with tab sizes.

    • Paulo Moura

      Ok, Seriously now :-) You write that “only one setting is guaranteed to reproduce the alignment the original author intended”. Given that what matters is the relative alignment (i.e. preserving the indentation levels), why caring about the original author intentions? What matters is that, with the tab setting you’re already using in your favorite text editor, the source code file will open from the start nicely aligned. In fact, if the original author doesn’t explicitly tell you, how do you guess his/her tab setting anyway?

  • Theofrastos Mantadelis

    Well very often you care for more than just the relative indentation. For example:

    typical_print:-
      write('Beginning of a very long line
             I like it continue exactly below'),
      format('Nasty formating that shows numbers:%d',
                                                [NUM]),
      predicate_with_many_args(Arg1, Arg2, ...
                               ArgIDoNotFitToTheSize,...),
      nl.

    I dare you to find a way to abstract this indentations…

    I’m a space user because I often have to write stuff like above. The rest of the world has to trust that I chose the best indentation for the specific code as I trust the others when I read code.

    I love holy wars :-D FLAMEEEEE lol

    • Paulo Moura

      The write/1 call is not a very good example. With a newline character within the single quotes, what actually gets printed depends on the Prolog compiler you’re using. Worse, with some compilers, you get a syntax error.

      The call to the predicate with many arguments would not work well with tabs, I concede. But it’s also a style that I don’t use or recommend. A simple predicate rename and all calls will loose the intended format. Not to mention that a predicate with many arguments always leads me to think that I may be doing something wrong. There are also alternative layout styles that don’t pose a problem with spaces. For example:

      findall(
      	Term,
      	LongGoal,
      	List
      )

      Is really a matter of style. Of course, some styles do make you look cool ;-)

  • Theofrastos Mantadelis

    The blog doesn’t preserve spaces… What else would you expect from a tab lover??? ;-)

    ‘typical_print:-
    ‘ write(‘Beginning of a very long line
    ‘ I like it continue exactly below’),
    ‘ format(‘Nasty formating that shows numbers:%d’,
    ‘ [NUM]),
    ‘ predicate_with_many_args(Arg1, Arg2, …
    ‘ ArgIDoNotFitToTheSize,…),
    ‘ nl.

    • Paulo Moura

      The blog uses HTML. In order to preserve the layout of your code, you can simply wrap it using the pre element. I just updated your comment in order to better illustrate your point. Wait… me helping a tab infidel! I’m doomed!

  • Roberto Bagnara

    I am not following. Let me start from the end: I need not to guess the tab setting of the original author if the original author does not use tabs (as I and others recommend).

    In contrast, suppose that the original author does use tabs. Consider these two cases:

    1) You have columns made up of, e.g., Prolog atoms separated by one or more tabs (the right number of tabs that worked with the tab size in use by the original author); these atoms vary in length; in general, not all tab settings will allow you to have the columns properly alignment. If the original author does not tell you, you will have to guess.

    2) A line of program text not using tabs is, in the original author system and according to his/her own intention, aligned with a line using tabs: the only way you have to get the alignment right is by using the very same tab setting.

    • Paulo Moura

      Using tabs for indentation doesn’t prevent you from using spaces after the indentation for alignment. As you know, indentation conveys code structure, which is different from e.g. writing printing instruction arguments for outputting a nice table layout. That said, I must say that I never found myself in the situations that you describe (and I write a fair amount of code as you may be aware). What seems clear (see e.g. Theo’s comment and my reply to him) is that some coding styles work best with tabs while other styles work best with spaces.

      The fact is, I don’t want anyone telling me that I should use (the equivalent to) 2 spaces per indentation level, when I would much prefer to use (the equivalent to) 4 spaces. Accordingly, my use (and recommendation of using) tabs for indentation levels respects each person preference for the tab size (or its visual equivalent in spaces). Changing the tab size is just a text editor preference setting away, which don’t require any changes to the file itself.

      P.S. Sorry for the serious mode. I know that this is supposed to be a holy war with flames bursting at every word. I will try to behave next time.

  • Nicolas Pelletier

    And now for something completely the same…

    I, too, like Roberto, misunderstood Paulo’s argument to mean “tabs everywhere, even for alignment”, so I am relieved to read his argument is much more reasonnable thant what I thought at first.

    That said, I’ll add my two cents worth of oil to the general fire ;-)

    - I agree that someone trying to tell me how *his* source should look in *my* editor is likely to annoy me pretty quickly. In this respect, using tabs for indentation is good;

    - I also agree that having to guess the tab size to even be able to read the source is a waste, and every well-behaved citizen should avoid putting such a burden on others;

    - I also agree that the tabs vs. spaces debate is just the tip of the iceberg when it comes to source code indentation. Heck, what about parentheses, commas, curly braces, semi-colons, dots? Even a tool like indent, depsite its vertiginous number of options, does not cover all the intricate ways people like to write C code;

    - Anybody who has had to discover, at the time of an important merge operation, that some previous merges, done months before, introduced a mix of spaces and tabs in the files; or that the vast majority of the differences consist of somebody carefully reworking the place where commas lawfully ought to be, is likely to understand the diversity of people’s tastes and utter lack of compatibility between coding standards;

    - Lastly, I heartfully agree that everybody should have his or her own pretty-printer, tailored to his or her tastes and nicely coupled with editors, diff and merge tools, and version control. After all, the way source code is stored on disk is largely independent of how people will use it. To paraphrase Kent Beck, author of a book on coding rules for Smalltalk: “Source code in files? How quaint”.

    - And now, everybody concerned about the gain in size should just compress all his or her files. It might even so happen, depending on the compression algorithm, that files using tabs and those using spaces end up being the same size (how shocking!)

    Note to the reader: do not dare taking any of the above seriously, or you might start a _real_ flame war ;-D

    Note to Paulo: it seems you found a sure way to get more comments posted on your blog.

    • Paulo Moura

      Nice to know that you’re also a Monty Python fan ;-) Regarding your comment on files with a rotten mix of tabs of spaces, I have been there. I was fixing some minor bugs on a Prolog compiler and all the indentation was completely toasted. I end up fixing it line-by-line before I could make a couple lines worth of bug fixes without cursing like a mad man.

      P.S. Loved the Smalltalk quote. I took several decades for the general industry to catch up with many of the goodies on the Xerox Parc Place Smalltalk implementations and, in some aspects, it seems that we’re still not there.

  • Tabs vs. Spaces | MTR

    [...] Space Infidels] [Joel on Software Forum: Tabs or Spaces?] [Why I Love Tabs] [Why I Prefer NO Tabs] [The Tabs vs. Spaces Holy War] [Revisiting Tabs and Spaces] [Rizzoweb: Tabs vs. Spaces] [Tabs vs. Spaces: The End of the [...]