Indentation

People,

Let’s all stop doing this:

static void
my_calling_function_wrong (void)
{
[tab]MyItem1 *item1;
[tab]MyItem2 *item2;
[tab]MyItem3 *item3;

[tab]my_long_funcion (item1,
[tab][tab][tab][tab]..item2,
[tab][tab][tab][tab]..item3);
}

And start doing this:

static void
my_calling_function_right (void)
{
[tab]MyItem1 *item1;
[tab]MyItem2 *item2;
[tab]MyItem3 *item3;

[tab]my_long_funcion (item1,
[tab].................item2,
[tab].................item3);
}

The former doesn’t make sense unless each and every code viewing text display understands Mode lines’ tab-width property. The latter just always works, with every normal text editor.

ps. The super cool guys at Anjuta have already fixed this for me. I’m sure the even more cool EMacsers and the uber cool vimers can also fix their text editors?

Unnecessary note: [tab] is a tab and . is a space in the examples.

25 thoughts on “Indentation”

  4. Yeah, that’s how I’m doing things too.
    Using tabs to indent, using spaces to align.
    This way, everybody is able to use any indent width, while the alignment/formatting is kept unchanged.

  5. That’s the only way I like to indent my code. And if everyone would remember that simple rule, we could all just use tabs and forget about code messed up by “inadequate” editors or copy and paste.

  7. Two reasons for not using tabs at all:
    – using tabs is nice to allow custom indentation width, but if someone uses two spaces as tab width and somebody else uses four spaces, the latter person may get lines much longer than 80 chars when looking at code from the former person
    – the indentation scheme you describe requires the editor to recognize the language and syntax, to turn the Tab key press into tabs or spaces (or am I mistaken?), so this is difficult to get right for simple text editors like Gedit.

  9. I use this sort of hybrid – I do the aligning with spaces manually, because I’ve never managed to persuade an editor to do it sensibly (particularly since I have to use Visual Studio at work, and that has very little idea of how to indent C++ in any kind of readable manner – such as initialisation listsm which it likes best all on one line).

    Once upon a time I used spaces, but then somebody convinced me that allowing people to have variable indentation through the use of tabs was better, and so I switched. Displays vary so much that it’s nice to let people tweak it to suit them.

    @oliver: 80 column wide lines of code seems to me a very archaic limitation these days, since our screens can, typically, show far more than that. Okay so you don’t really want to go too high because the readability goes through the floor, but it’s not so much of a problem on a big screen if the indentation goes deep but the line itself stays fairly short. Deep indentation is or can be indicative of other problems, but trying to stick to 80 columns seems like an unnecessary handicap to me.

  10. If you actually still care about the 80 char limit, you are free to use a small indentation width.

    Doing this indentation style manually is really not that bothersome, and actually much easier than dealing with spaces-only in a simple editor like Gedit. Yes “insert tabs as spaces” is trivial to implement, but it still requires you to hit backspace up to 8 times everytime you need to remove a single indentation, which is a huge PITA. Not to mention that it’s extremely easy to make a mistake, and I’m just tired of dealing with source code that is a huge mess of spaces thrown all over the place (yes it wouldn’t happen if everyone would use emacs or vi properly, but that’s not reality).

    Even if someone gets the alignment wrong (which is easy to fix when I stumble across it), working with code that uses tabs still tends to be a lot nicer.

  11. The problem with using tabs is that is not always obvious to see them, and you end up having a mix of tabs and spaces in the same file, which can be quite annoying, specially when it interferes with your patches.

  12. yes, you’re absolutely right. I’m using this style too in vim but manually.

    leave people using the tab length they are confortable with, and don’t force your likes to others !

  13. But Berto, that goes both ways. And in my experience I encounter more source files that are consistent tabs-only, than consistent spaces-only (especially around Gtk).

  14. I disagree with both approaches. I prefer:

    [tab]my_long_funcion (item1,
    [tab][tab][tab]item2,
    [tab][tab][tab]item3);

    The advantage to this is that the parameter indent is consistent across ALL method calls, meaning that if I rename my_long_function() to some_semantically_better_name() (yay refactoring), I don’t need to reindent all of the parameters (thus minimizing diffs in the revision history).

    I really don’t understand the need/desire to have all parameters “lined up” underneath the opening ‘(‘ of the function call. Indentation is certainly required, but to have a variably sized indentation, based solely on the function called, seems quite silly.

  16. @Jonathan Pryor: Then at least drop the first parameter to the next line. This conforms with Google’s suggested indentations for Python, where both of these are accepted:

    [tab]my_long_funcion (
    [tab][tab][tab]item1,
    [tab][tab][tab]item2,
    [tab][tab][tab]item3);

    or

    [tab]my_long_funcion (item1,
    [tab]……………..item2,
    [tab]……………..item3);

    reference:
    http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Indentation#Indentation

  17. @Daniel Borgmann:
    > Yes “insert tabs as spaces” is trivial to implement, but it still requires you to hit backspace up to 8 times everytime you need to remove a single indentation, which is a huge PITA.

    shift-tab it’s the right answer.

  19. The solution is of course to drop tabs completely. Mixing them may be your quick band-aid but that’s just making things even worse and MORE complicated, because then the next editor that comes along have to know how to edit those lines as well. URG!

    All good editors today know how to edit with spaces that behaves like tabs, problem SOLVED.

  22. Tab > space.

    If you are unable to read function definitions with long parameter counts (how many of those do you have in a single file anyway..) you might want to consider seeing an optometrist.

    Every single point of a space being preferable to a tab is complete and utter nonsense. If, for some reason, you’re stuck in the pre Vietnam war computing era and are unable to fit more than a couple of characters on a single line, I suggest upgrading your hard- and/or software.

    Not to mention that every single decent text editor has the ability to set the displayed tab-width to whatever you please. And if you really (although I really can’t imagine why) want to align function parameters in some in(s)ane way, I suggest you try to improve your text editor of choice to do just that.

    But please, don’t insert random crappy spaces just to make something “pretty”. It’s a complete waste of time and it increases source file size for no good reason at all.

  23. @Daniel Borgmann: tab-only simply does not exist. It’s possible, but every source file I’ve ever seen has had at least some spaces. So once you eliminate for whatever reason allowing a mix of tabs and spaces, the only logical choice left is spaces-only. (Except for Makefiles, and guess what the most common problem is people have with Makefiles ?)

  24. Very good post, if only because that’s the way I work too :P

    I always enjoy spaces vs. tabs debates, people can get so wonderfully emotional about it. It’s almost like politics.

    Perhaps in a next blog post you could talk about K&R vs. whitesmith vs. Allman and bracket placement for code blocks. That’s always a good debating point as well :)
    (I prefer whitesmith/allman, less bugs per line :P )

    Also, I think all arguments that talk about it being hard to be consistent with spaces and tabs should join the 21st century and just configure and use a code beautifier. Granted I mostly use a IDE instead of just a editor, but I’m reasonably sure there are similar tools for vim and emacs.

Comments are closed.