Hacker News Reader

Comment by mherrmann | Hacker News Reader

I've never really understood why you would use several characters (=spaces) for something that is semantically one indent. Can someone enlighten me? What are the advantages of spaces over tabs?

View on HN

Not all editors are smart about tabs and spaces, and when the two start to mix things get really funky if everyone doesn't have the same "1 tab = x spaces" value set on their editor.

For example:

      function_call(really_really_really_really_really_argument1,
                    really_really_really_really_really_argument2)

Say that this is supposed to be at one indent level. The beginning of both of those lines should contain only one tab, and the spacing that positions the second argument from the indent should be only spaces:

  <tab>function_call(really_really_really_really_really_argument1,
  <tab>SSSSSSSSSSSSSSreally_really_really_really_really_argument2)

If the text looked like above (each 'S' is a space), then one's editor could easily change whether or not a <tab> was displayed as 8 spaces or as 4 spaces, and the display wouldn't be affected. Many editors, however, consider all spacing at the start of the line to be indentation. If you were using one of those editors with tabs set to (e.g.) 4 spaces, the code might look something like this:

  <tab>function_call(really_really_really_really_really_argument1,
  <tab><tab><tab><tab>SSreally_really_really_really_really_argument2)

Now the code only looks the way it was meant to look if you have you <tab> = X spaces value set to 4. If you set it to something else, the code looks like a mess.

Your point is valid, that's why I write

    function(
        really_really_really_really_really_long_argument1,
        really_really_really_really_really_long_argument2,
        really_really_really_really_really_long_argument3);

Right, not now you're dictating coding style to work around the warts associated with using tabs. If you use spaces there are no such issues because spaces don't change widths between editors.

To be honest, no, because my formatting will not be broken after refactoring changing function name length.

What workflows do you have where renaming functions happens often enough that you need to optimize for it?

I do not really measure how often this happens, just rename as soon as name does not reflect exactly what function does.

The kind of formatting you suggest - aligning with spaces to get beautiful indenting - is a royal pain in the ass to edit. You change the function name to something a few characters shorter and now you have to change all the lines. It's prettier than the alternative, though (I still don't use it).

I wish the pioneers of programming languages would have had the foresight to provide an automatic formatting tool and standardize on a canonical layout. So much time and effort would have been saved.

Further, I think code guideline documents and discussions without an accompanying config file for astyle or clang-format are pretty useless.

That particular form of formatting is part of Python's PEP-8, which has tooling around it. Maybe not all editors have something built it, though.

Editor is one thing and most fully featured editors probably have an indent mode like this. Then there's all the other tools, like diff/merge tools, automatic refactoring scripts, etc which don't work as well.

I'm not a fan of Python's significant whitespace or PEP-8 in the first place. It puts too much emphasis on aesthetics at the cost of practicality. Writing a parser or any tooling for that is just a pain in the ass. I do use Python occasionally but for very different reasons than aesthetics.

I disagree. I moved form Perl to Python and disliked the whitespace to begin with. It does solve a couple of problems - it forces inexperienced coders to indent properly (I had one colleague who didn't when she used Perl). It also solves the missing brace problem when moving blocks of code around, which for me makes it worthwhile. It does make moving blocks around and commenting sections out a bit more effort, but way less effort than trying to work out where the brace has gone.

Some languages do have more-or-less canonical formatting styles. The Lisp family comes to mind, as do ML and Haskell. You see far fewer arguments about formatting there, partly because there's very widely-accepted style, and partly because nobody cares to argue about the few things that don't have established canon.

> Many editors, however, consider all spacing at the start of the line to be indentation.

What? If your editor can't tell the difference between you hitting the tab key versus the spacebar, it's a bug in your editor.

Smart tabs - the idea you're talking about - is well-supported in just about every major editor.

Things that are supposed to be lined up stay lined up even if they aren't at the start of a line - even if you:

* Use different tools - IDE, command line, version control tool, code review tool, e-mail client.

* Have code that follows with different conventions - because you participate in several projects, or because you've imported third party code that follows a different convention, or because the code is written in different languages.

* Have co-workers with different opinions about what tab width should be set to.

Personally I don't think there's that much value in vertically aligning things, except in lookup tables. Usually it's a sign you've adopted line-length rules that don't reflect modern monitor sizes, or that your methods have too many parameters. But some people seem to think it's valuable.

People always talk about consistent display of spaces whereas tabs might be shown as 4 spaces or even 8. Of course that means you can usually customize how tabs are rendered unless you code in Notepad or something crazy.

Lots of people need to access files on a server via Emacs or Vim. Having to deal with tabs there can be very frustrating.

On vim (I am sure as hell you can do this on Emacs) you can always define your tabs to be spaces and you can specify exactly how much. So this is really not a big problem.

I'm not an Emacs guy but it's trivial to set the tab size on vim. I would be shocked if that were not also the case for emacs.

The big advantage, as other people discuss, that that different editors display tabs as 2,4 or 8 spaces, and I've never worked on a codebase which used tabs, and where viewing the code in different tab sizes didn't break the layout somehow.

If you use spaces, you can format code, knowing it will look right on other people's machines. Perhaps a sufficiently organised bunch of programmers could edit a large code base such that it viewed fine with 2,4 or 8 character tabs, but is it worth the pain?

Semantically, the TAB character means something like "insert a pseudo-random number of spaces here" with that number often defaulting to some ridiculous value like 8.

I keep my programs less than 80 character wide for accessibility purposes but if I use tabs then the width is unpredictable.

Also, spaces are universal and trivial whereas the TAB button in many editors has strange behavior.

    def doSomething( parameter1
                   , parameter2
                   , parameter3
                   ):
        pass

How would you make all the punctuation line up using tabs?

Rather (assuming you’re dealing with Python),

    def do_something(parameter_1,
                     parameter_2,
                     parameter_3):
        pass

    def do_something(
        param1, param2,
        param3, param4
    ):
        ...

It's not that hard. Alignment is generally harmful - it's a maintenance burden which adds whitespace noise on diffs, which means more noise in code reviews. Not to mention how atrociously ugly it is when long variables/method names lead to 5+ lines with 60+ characters of indent for a single variable name per line.

Most diff programs have an "ignore whitespace" option. "whitespace noise on diffs" is pretty much a solved problem. You can even add '?w=1' to a Github URL to turn on the feature.

1. That's a band-aid. The characters have still been changed - the diff still "exists".

2. Those options are not perfect, they don't always work as expected

3. Those options are not turned on by default (because that would be INSANE)

4. Git's not the only VCS, much as I wish it were

5. Github's not the only Git web UI; that option is not available everywhere.

It's not a "solved problem". It's an artificial problem, that gets solved when you start consistently stripping trailing whitespaces on save and not realigning everything all the time.

> It's an artificial problem, that gets solved when you start consistently stripping trailing whitespaces on save and not realigning everything all the time.

This is mostly solved via coding standards. If there are no coding standards people will "refactor" the coding style when they touch various pieces of code. If people were following a consistent style, then the alignment wouldn't be changing all of the time.

Although I strongly agree with the trailing whitespace sentiment. The most egregious offender that I've found is Eclipse putting trailing spaces on blank lines to bring them to the indent level of the non-blank lines. Ugh.

    enum {
        NORMAL    = 1
        ABNORMAL  = 2
        IRREGULAR = 3
    }

Now if you're writing like this, what happens when you introduce "EXCEPTIONAL = 4"? You change 3 other unrelated lines. This is something that alignment causes, regardless of "coding standards". Hell, gofmt does that... It looks pretty (to some extent - with long names and lots of members it gets unreadable), but creates so much noise.

You don't, you use tabs for indentation and spaces for alignment.

Parent, you are the devil incarnate. Grandparent, you have bigger issues to resolve.

The longer I've been programming, the more I think that alignment is ideally a presentational feature that a syntax-aware editor should do, not something that should be reflected in the source.

But then tabs vs. spaces isn't an issue.

With spaces you can position the cursor anywhere you want, with tabs you can not position the cursor in the middle of a tab.

Why would you want to do that? In fact, isn't it much more convenient to be able to jump over one tab with a single keystroke, rather than 2, 4 or 8?

If you use the mouse then you want the cursor to appear exactly where you clicked. It's just a UX problem, similar with clicking past the last line of a file, even if it's nothing there, the editor should append new lines until the place that you clicked becomes part of the file.

Reply on news.ycombinator.com