Never use hard tabs

Update: This post has been updated to address some of the claims in the comments. Please note that most of these claims are wrong :)

As there seems to be some confusion when hard tab characters (ASCII code 9) are appropriate in source code files here is a rule:

1) Never use hard tabs

1. 1) Unless your source code is hard tab sensitive (only such format I know is Makefile)

1. Reasons not to use hard tabs

  • Due to legacy, different text editors treat hard tabs different. UNIX text editors prefer hard tab is 8 spaces, Windows text editors and IDEs (Eclipse) prefer that a hard tab is 4 spaces.
  • The hard tab length agreement between different text editors cannot be reached
  • The hard tab length agreement between people cannot be reached
  • Thus, hard tabs may break source code readability and editability if there is more than a single person editing the file. They will open the file in an editor with different tab settings, edit it and next time you open the file it is ruined and all indentations are wrong.
  • This is even worse on white space sensitive languages (Python, CoffeeScript) as this might actually cause syntax errors or programming logic errors

However, you can avoid this problem in the first place if you do indentation using soft tabs (spaces) instead.

Even if you were the single person in the world editing the text file, even you might switch the text editor in some point and accidentally shoot yourself in the leg.

2. Using soft tabs for indentation and having no hard tabs should not be a problem because

  • All text editors can convert tabs to spaces in fly, when editing the file. Please note me if there are commonly used editors, besides Windows Notepad, which doesn’t do it yet.
  • Text editors usually have different settings to tab key length and indentation settings. The latter is what you really want to adjust.

3. Pseudo-arguments for using hard tabs

  • It makes the file size smaller: you really care about those twenty bytes on your gigabyte hard disks?
  • This one I made up: spaces count toward the file size in web stuff, because visitors download the files. However if those bytes really matter you that much you should be using a minimizer in the first place.
  • I like them arguments…: rationale not involved
  • The change resistance in human nature

You might have a legacy software project having its legacy style guides. If the project big, e.g. Linux kernel, the switching cost may be very high and not affordable. However, even with this kind of codebase, you can gradually replace hard tabs away.

4. Style guides (updated)

Hard tabs are required only in Makefile syntax and preferred only in Go style guides. This is because people have learn by experience that hard tabs cause mess when working with other people.

5. Tab character is not semantically the same as indent level (updated)

There is no style guide or coding conventions saying that the tab character should the indent. This assumption is easy to make because it allows you to stick your head into a sand, ignore the surrounding world and by singing “let the users pick their own tab width” mantra. However, though a cunning idea, this perceived simplicity causes compatibility and co-operation issues which this post tries to highlight.

6. The user should choose to their own tab width (updated)

To choose your own preference is the rationale many people claim is the reason for indentation by tabs. “Let the users pick their own preference for indentation” However if you indent to work with other people the recommendation is to stick to the programming language recommendation. This way people can be more easily pick up the codebase.

There is nothing gained by having “user chooseable indentation width by adjusting tab character width”. The most used indentation width is 4 spaces anyway, so it is extra effort to maintain the freedom to have a user pickable indent width number instead.

Try to go to tell some old UNIX admin that they must adjust their editor tab width (see below).

7. Tab width is 8 spaces and don’t mess with it (updated)

People who use tabs as indent assume tab one tab = one indent and they can freely adjust the tab width, so that the indentation looks nice. However

  • By legacy, the tab character width is 8 spaces and most of the software out there makes this assumption. If you use any other value for tab width you are breaking this legacy social contract and you are making it for other peoples more difficult to work with your project.

This really limits the ability of using tabs as indent, because 8 spaces tabs often don’t make sense as indent (exception in system style C programming like with Linux kernel).

It’s ok if you work with the code in only one text editor alone where you have this one setting for tab width and that’s the only setting in the world controlling the tab width in your source code project. But when someone else must read or edit the code

  • Others must adjust tab width to make your code more readable
  • Adjusting tab widths from 8 spaces might be very difficult when working with other toolchains (e.g. you are viewing the code in terminal using cat)

Also in the languages where the recommended indentation level is only two spaces it would make it little funny to use one tab character just to have two spaces.

8. Tabs cannot be used to format code multi-line functions (updated)

Some people prefer to format long argument lists like this. A Python example which would break because of mixed tabs and spaces if tabs are used as indentation

call_a_function(argument,
                very_long_argument="something",
                even_longer_argument="something_else)

ย Or in C

   if (first condition
       second condition)

9. Text editors

If you are a text editor author, make sure your text editor ships with hard tabs turned off by default, especially for whitespace sensitive languages if you vary tab policy by file type.

Note that this blog post, and the situation, could have been avoided if

  • All text editors would have sticked to soft tabs by default
  • All text editors would have sticked to a hard tab is 8 spaces by default

But in some point (when?) someone (who?) decided to make our life little more complex.

10. Tools for managing hard tab policy in your software project

ย Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

56 thoughts on “Never use hard tabs

  1. What a bullshit hipster blog post indeed. All your arguments against tabs are just opinion and personal preferences, the conclusion are not logical or even based on facts.

    Here is one gem: “There is nothing gained by having โ€œuser chooseable indentation width by adjusting tab character widthโ€. The most used indentation width is 4 spaces anyway, so it is extra effort to maintain the freedom to have a user pickable indent width number instead.” — That’s no effort at all if you use tabs, it is when you use spaces. And every single dev has his own preference, so why not enable them to set it to their liking?
    (Oh btw, nice assumption that width 4 is used anyway. If that was the case, why should we be using spaces again?)

    Statements like “Thus, hard tabs may break source code readability and editability if there is more than a single person editing the file.” are just plain wrong. You also reason that those two points speak against using tabs:
    “- The hard tab length agreement between different text editors cannot be reached
    – The hard tab length agreement between people cannot be reached”
    … BECAUSE nobody can agree on on the ‘perfect’ length to indent, tabs are a great thing when working with many people. Anyone is free to use the width they like, which is not possible with spaces!

    If anything, the “3. pseudo-arguments for using hard tabs” you listed apply to YOU! All your “arguments” do not hold once you’re willing to set your freaking tab-width in your editor.

  2. It is much easier to move around file with tabs by arrows than in file with spaces-only (unless you force yourself to 2-spaces indentation or get used to Ctrl+Arrow …but using tabs is still more productive).

    It has nothing to do with file size and whatever pseudo-argument, it is purely about writing your own program and how fast can you be and how comfortable you feel.

    Actually, this article is filled with pseudo-arguments. One of them is that “every editor can replace tab with spaces” – yes, and most of the editors allow to specify tab-size ๐Ÿ˜‰ And some can even retab (yes, Vim: retab!) the file as you wish it ๐Ÿ˜‰

    Even GitHub can show your files as you want it, just add ?tab=4 to the URL ๐Ÿ˜‰ (I often use ?ts=4;w=1 to ignore white spaces and line endings completely … hmm, as I think of it, shoud I use Windows, Linux or Mac line endings?).

    Stupid article, selfish and arogant.

    Programmers: use whatever you want to, and if you create some editor or diff-like program, make sure to have settings for tab-size ๐Ÿ˜‰
    And if somebody is complaining about your source file, kick him and let him (or her) write their own source file instead of complaining about tab-size ๐Ÿ˜€

  3. There seem to be no legitimate reasons against tabs here.

    You mention that “people can’t agree on indentation size”, which is a plus for tabs because I can use 3-tabs, you can use 4-tabs, our friend can use 8-tabs, and we can all edit the same file and it will look good to each of us.

    You mention that some languages choke on mixed whitespace (things like Python). This does not seem to be a valid argument for or against tabs.

    You say “Tabs cannot be used to format code multi-line functions”, and then provide an example in Python showing how this would break things, however – this example functions – a perfect demonstration of the usefulness of tabs.

    You seem to repeat throughout the article that tabs will mess up indentation, but (Linux kernel development aside,) fail to actually detail any circumstances in which tabs are not the superior indenting choice.

    I need more actual arguments and less fluff about how people listing the arguments against your opinion are “sticking their heads into the sand, ignoring the surrounding world and singing ‘let the users pick their own tab width’ mantra”. Tell me why the USAGE of tabs is wrong; not why the USERS of tabs are wrong.

  4. “10 reasons why people should eat pears but not carrots” (example argument: if you try to eat a carrot but drop it, you might as well pick up a pear next time).

    “Never use yellow pencils” (example argument: if a member of your team is allergic to the color yellow, you’re screwed)

    “Always open the door using your right hand” (example argument: I once opened the door with my left hand and my the tab settings in my emacs changed)

    A tab means a tab, and every editor can render it according to the user’s choice. The only argument that makes any sense here, is that if one member of your team doesn’t play along, then integration is screwed. the rest is drivel.

  5. Spaces are not tabs. And your preference is not relevant here, it’s not like tabs are broken or anything. Customize your text editor if your preference is so important to you. I’ll stick to tabs simply because there’s nothing wrong with them.

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=""> <s> <strike> <strong>