Hacker News Reader

Comment by tom_mellior | Hacker News Reader

> This is exactly why I use tabs and the reason which appears to never get cited in the holy wars.

I see this cited every time. Unfortunately, it's bogus in practice. Consider:

    print('some long thing',
          further, arguments)

If this is an indented block, you'd have to indent the second line to the correct depth with tabs, then add exactly six spaces for alignment. You have to mix spaces and tabs, which is never good news. Additionally, if you try to actually type in the six spaces, editors might take, say, four of them and group them into a tab. (I have vague memories from a long time ago of Emacs doing this. I might be wrong.)

If you get this wrong in program parts that are by definition invisible, it might look good for you and look really bad for others (i.e., the opposite of the stated goal). In code I see mixing spaces and tabs, the latter tends to be the case.

View on HN

I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs.

That being said, this problem and problems like it can be solved simply by not aligning things visually:

    print(
        'some long thing',
        further,
        arguments
    )

Strictly adhering to indentation and never alignment can make the code a bit less readable, but conforming to a canonical indentation like this also makes it easier to reindent, move code around, etc.

I think that's what the argument really comes down to – alignment flexibility vs display flexibility. It's interesting to see which people generally prefer.

> can make the code a bit less readable

Yes, and I'd say that that's a big problem. I'm not a religious opponent of tabs, but making code less readable just so you can keep using them wouldn't fly if I were Malevolent Whitespace Dictator For Life.

IMO, that reads just as well. Each object is still indented, it's close enough.

> I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs.

Could you please clarify why do you consider "tabs for indentation, spaces for alignment" such a bad practice? I have never read any argument against it.

Alignment itself can be done automatically by any editor that supports smart tabs.

Simple: it's hell to automate.

My process is as follows:

    - tabs allow for custom settings
    - tabs need spaces to allow for alignment, because previous
    - automatically deciding what constitutes alignment vs
      indent is a non-trivial problem, highly dependent on the
      language†
    - using spaces throughout is worse theoretically because
      it flattens the theoretical problem but solves impedance
      mismatch
    - therefore I use spaces and am all the merrier in every practical
      use case
    - except for languages who make dash 3 easy (such as Go thanks
      to gofmt)
    - except for projects I have no say in, where I respect the will
      of the maintainers, because conventions among well-behaved
      people matter more than my highly individual opinion.

† to which the usual answer is "but your editor sucks with lang X", well too bad, I'd rather have pragmatic editor portability than have perfect language parsing in every editor being a pipe dream I hinge upon.

It's not that "tabs for indentation, spaces for alignment" is a bad practice, it's that alignment itself is a bad practice. It doesn't help readability, it directly causes overly long lines of code (which pushes people to try to use narrow indentation to compensate), it's something you have to fiddle with every time you refactor a name, and it gives you spurious changes in your VCS diffs. (Yes, you can set any diff program to ignore whitespace changes, but I want to know when whitespace has changed.)

Yes, Emacs used to group spaces into tabs. I think most editors these days do the right thing.

This problem goes away if you indent parameters instead of aligning them:

    print(
        'some long thing',
        further, arguments)

In this case it takes an extra line, but it's often shorter.[1]

[1] https://github.com/pennersr/django-allauth/blob/a44134688f5b...

Gross, You purt 3 parameters are on two lines. Either indent none of them and keep it on one line or indent all of them. What are you doing, trying to hide "arguments"?

That's how the original example was formatted. I'm illustrating one small change.

> I see this cited every time. Unfortunately, it's bogus in practice. Consider: > > print('some long thing', > further, arguments) > > If this is an indented block, you'd have to indent the second line to the correct depth with tabs, then add exactly six spaces for alignment. You have to mix spaces and tabs, which is never good news.

One way to avoid this would be use a hanging indent. For example:

    print(
        'some long thing', further,
        arguments)

That would work well with either tabs or spaces.

This is the right way to do it always, because it is the consistent way. You'll always be indenting the same way everywhere if you do it like this.

This is an example of where it's absolutely okay to mix tabs and spaces. If it's Python, that's not going to work, but depending on one's preferences and opinions that can be seen as a defect of the language, not the formatting. In C, C++, Java, Javascript, and nearly every other language, this is a great practice.

I agree in theory. Having seen terrible mixes of tabs and spaces, I don't agree in practice.

I've worked with several projects that painfully switched from tabs to spaces because tabs didn't work for them in practice, in a setting where several people work on one thing. I haven't seen projects go the other way. (Yes, automated formatting would solve part of thise.)

you're going to be downvoted by the thou shalt not mix tabs and spaces crowd that fails to understand the reason of what they preach. sigh.

also the fly by night devs who still don't see tabs on their text editors... I mean, ide.

I feel it's a matter of style. I've resisted a long time, but then I've come to appreciate:

    some_function_name('some long thing',
        further, arguments)

Assuming a tab width of four, there is no problem with starting the second line with a tab. And the whole thing can be indented by tabs, as well (in which case the first line has N tabs and the second line has N+1 tabs).

The longer the function name, the better the advantage of indenting like this.

Spaces are only beneficial if you use styles with alignment. I dislike them: they sometimes look pretty, but they waste a ton of space on the left and don't work well in all situations.

I wonder how much time have been wasted trying to make margins and columns look good with a proportional (non-monospace) font ...

Almost certainly none at all. Those of us who use proportional fonts simply don't try to do column alignment, because it would be a fool's errand.

In most situations, I consider column alignment to be detrimental to code maintainability. I actually stopped using it long before I switched to a proportional font.

When I later got curious about trying different fonts, I discovered to my surprise that the code looked just the same in a proportional font as it did in a monospaced font.

Regarding margins, if you mean indentation, that works the same in a proportional or monospaced font. The only thing that doesn't work well is the popular two-space indents. That ends up with very little visible indentation in a proportional font.

But to my eyes, two spaces isn't enough in a monospaced font either. It's just not enough spacing for me to see the code structure clearly. Four-space indents solve this problem; tabs solve it even better. When you use tabs, you don't have to argue about how many spaces to use.

I think these are related. Why do people want to use two-space indents? I believe it is often because their lines of code are getting too long. Why are the lines getting too long? Often that is because of the use of column alignment, especially with function arguments and the like.

If you stop using column alignment, your lines will naturally be shorter, and there is less reason to try to save horizontal space with narrow indents.

Reply on news.ycombinator.com