Hacker News Reader

Comment by redm | Hacker News Reader

The reason I use tabs is pretty simple. It's faster to move around only using the keyboard. It's also faster if I'm changing code that requires reformatting. Finally, when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc. In other words, it adds flexibility.

Brace yourself: I use two spaces after the end of sentences too. [1] I am quite the rebel.

Modern IDE's (Sublime Text) let you easily convert spaces to tabs (or vice versa) and intention length of existing code. [2]

[1] http://www.slate.com/articles/technology/technology/2011/01/...

[2] https://css-tricks.com/changing-spaces-tabs-sublime-text/

View on HN

> Finally, when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc. In other words, it adds flexibility.

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

People who use spaces want to line up their '=' signs, that's fine, but I don't believe it's my position to enforce the amount of whitespace another developer has to use in their editor. It's an accessibility thing, they might have their font size really large because of eyesight problems in which case 8 spaces is going to make reading the code a lot harder.

The fact that Python's rule used to be 8 spaces, then got changed to 4 thereby invalidating old code really showed me how shortsighted it is to use a set number of spaces in a whitespace sensitive language.

> People who use spaces want to line up their '=' signs

How does that prevent the use of tabs? You can use tabs to indent, and spaces for your = signs.

Mixing tabs and spaces is a nightmare, unless it is your personal non-open project. If a project is open or shared with anyone you need a simple rule to follow. There shouldn't be another leaf in the decision tree for when to use tabs or spaces. We have enough decisions to make the way it is.

First, my golden rule is "do whatever the other devs using the repo do" but

> People who use spaces want to line up their '=' signs, that's fine

To me this feels like it's a good use of spaces as well as tabs. Tabs for indentation, to get your nesting right. Spaces to align things. That way setting your tabs to X spaces works just fine and everything remains nicely aligned.

Though I'm not sure how common this is, so I just use spaces.

Get your blasphemous mixing of spaces and tabs out of this holy war!

> The fact that Python's rule used to be 8 spaces, then got changed to 4 thereby invalidating old code really showed me how shortsighted it is to use a set number of spaces in a whitespace sensitive language.

Not sure what you're talking about here. In Python, as long as the indentation is consistent you could (e.g.) use 2-space indentation to make a code block. It's considered bad practice, and most linters will complain about it since 4-space indentation is the "golden rule."

If you're talking about the Python interpreter's interpretation of the tab character in indentation, that's different[1]. In any case, old code that has 8-space indentation using spaces rather than tabs is still good. The only issue would be old code that mixed tabs and spaces for indentation, which might not match up anymore to make correct code blocks. But, in general, it's just a bad idea to mix tabs and spaces for indentation.

[1] To the uninitiated, the Python interpreter treats a tab as X number of spaces when parsing the source code. This means that technically you could mix a block's indentation between tabs and a corresponding number of spaces. For example, if X = 4, then this code block would work:

  def function():
  <tab>something()
      something_else()

The right solution here would be to treat a tab as exactly pi spaces. This, while not forbidding the use of tabs, would guarantee that any inconsistent mixture of tabs and spaces would be considered misaligned.

I think pi*pi is even better. Twice the pi!

> exactly pi spaces

That's an irrational choice.

> 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.

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.

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'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.

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.)

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.

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.

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.)

> 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.

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.

"""The fact that Python's rule used to be 8 spaces, then got changed to 4 thereby invalidating old code really showed me how shortsighted it is to use a set number of spaces in a whitespace sensitive language."""

When exactly did it use 8 spaces? I have been using Python since 1996 and I don't recall this 8-spaces thing. Almost all code I've seen uses 4 spaces.

In any case, it doesn't matter because, as another commenter pointed out, as long as your indentation is consistent, your code will work just fine, no matter how many spaces you use for indentation. Even if some code does use 8 spaces, it should work without problems. (Tabs as well, by the way... it's mixing tabs and spaces that is a problem.)

I may be misremembering since it has been a long time since I've used it, but I thought at one point Python treated one tab as equivalent to eight spaces.

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

It's probably been mentioned 20 times in this thread alone.

> Python's rule used to be 8 spaces

Interesting. Unfortunately I cannot find anything on the internet regarding that. Care to share a link proving that?

"I don't believe it's my position to enforce the amount of whitespace another developer has to use in their editor."

I suspect this might not be my most popular comment, but I honestly think that this is why tab users might actually make less than space users on average. On average, it's more productive to enforce things than leave everything configurable, thus different everywhere, thus harder to make sense of and debug. I knew brilliant people who don't want to "enforce" and decide and dim people who happily enforced and decided and it's always amazing how badly the former do career-wise relatively to their talent and effort, and how well the latter do relatively to theirs.

(Of course there might be another explanation for the data and I don't claim that my just so story is in any way scientific; though I think it should pass as a scientific theory in the social sciences.)

It's plausible and goes to show why the blog post choosing salary is itself a bad metric to begin with. It has skewed the entire discussion.

> when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc.

This is an argument I hear often from tab proponents. What it misses out is the downside: my IDE has a certain arrangement on my screen, and I'll either have to invoke horizontal scrolling or I'll have a bunch of wasted space if you are using different size tabs from me. This is far from flexible.

There's also the (more minor) issue that you then can't line things up on a line below at an arbitrary place if the indentation of the two lines is to be different. This is admittedly less of an issue, but it does arise on the occasion one wants to structure text, for example in a table in a comment block.

I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere. But I'm not writing this to get into a holy war; only to point out that the "it adds flexibility" in your argument is a fallacy.

> if you are using different size tabs from me.

But the point of tabs is that you tell your editor how many spaces wide you want them to be, so unless I'm misunderstanding you, this is not an issue.

As for lining things up, tabs are used for the indentation level of the current line, but if you need to further nudge things within that line then you'd of course use spaces (after the initial tab indent).

You misunderstand me. I can set my tab size different from yours, but doing that will change the horizontal window width required to view your code. This is the problem I'm describing.

How is that problematic though? I'm not aware of any language or situation where the width of the window has any impact on anything.

Someone who uses 8 spaces for tab will do less nesting them someone who users 2. Thay is how I read the above comment.

Assume you want to eliminate horizontal scrolling. This is a valuable enough goal that a lot of coding style guides have a width guideline. That keeps everybody from having to make their editor windows as wide as the last person who worked on the code.

If this arrangement is working, nobody has to scroll horizontally, and there is no arms race of ever-wider editor windows.

Now introduce tabs into this situation. In theory I can set tabs to be whatever size I like. But in practice, I can't make them wider than the last person who worked on the code, because then I'm back to horizontal scrolling. Moreover, if I make them narrower, then they have to narrow their tabs to keep pace. So you get an arms race of tab- narrowing instead of window widening.

I just want to code. I don't want to scroll horizontally, or constantly mess with my window width and/or tab settings to avoid that. It's extra work that doesn't accomplish anything.

I am genuinely baffled (but I don't think I'm right and you're wrong... I trust HN people to be smart and capable). Can you please explain to me how using tabs vs spaces would encourage people to indent their code differently? I mean, if I have an "if" statement, then I indent my code -- but why would people indent their code for reasons other than what the flow of the code suggests? And if these hypothetical "indenting just because I can and not because I should" people exist, how would their inconsiderate behavior be any different whether they are using tabs or spaces?

I'm not talking about using a different style. I'm saying that different tab widths lead to different requirements for how many columns wide my window must be.

> I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere.

Ah, the old argumentum ad ubiquitam, which has saddled us with the x86 ISA, Unix kernels, and other brokenness we can never shake.

You're begging the question. There's nothing wrong with the principle of having a standard format, or the currently accepted standard format.

> I'll either have to invoke horizontal scrolling or I'll have a bunch of wasted space if you are using different size tabs from me.

So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs.

>I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less).

Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running.

Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...

> Also, what do you mean "works"? The world doesn't

explode if

> you view a file with a different tab size than it

was created

> with. Again, kind of the point...

It does, as I demonstrate in my quote of you above. Try reading source code like that.

The only sensible way of reading source code is by viewing it with at the same overall window width in which the author wrote it. Viewing at a different tab size destroys this.

> Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running.

Except that I need to figure out the most appropriate tab size to use on a per-file-author basis if "variable tabs" were used, so this doesn't work because I get the problem as described above.

> So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs.

I think that the point was that if your IDE displays tabs as 8 spaces, and you read code written by someone that sets their IDE to display tabs as 2 spaces, then the line lengths will display longer in your IDE.

It "just works" when the writer has configured longer tabs than the reader, but not necessarily in the opposite direction.

> Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...

One example: enforced line-length limits. If you are wrapping at 80 characters with tabs set to 2-spaces, you will display a longer than 80 characters when viewing with tabs set to 8-spaces.

> So change your tab size?

Then open another file, change the tab size again. Or start setting up macros/extensions/whatever to remember or auto-detect settings. This flexibility to have different developers view the same code with different tab widths comes at a cost. Many of those same developers would rather not keep paying the cost, and would prefer that code written by many people fit in their editor/IDE windows and look consistent without any special settings.

> Further, the only sensible screen width is 80 characters, since that also works everywhere.

I'm curious. Where does 80 characters not work now? How many people / industries are still using green-screen terminals with a fixed-width of 80 characters?

I'm generally in favour of enforcing line-wrapping requirements, because I've worked with people that would have a tendency to write code that trails off the end of the earth if you let them. But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done."

I realize that the 80-character limit is "everywhere"[1], but other than "it's everywhere" is there a more solid reason?

[1] When editing text emails in Vim the default textwidth value is 72, so that there is still some flex for quoting explicitly wrapped text (i.e. prepending "> " to the lines) and staying within the 80-character limit. The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters. etc...

Further, given that you're dealing with a language that uses significant indentation, you end up having to use stupid tricks that make your code less readable to stay under the bar.

Indented two levels (an 'if' block in a function in a class) and a couple of interpolated variables in an error message isn't unreasonable to have on a single line.

80 character line wrapping is IMO more important on larger and wider-aspect ratio screens. Even the smallest 16:9 aspect ratio screen can be split into two columns, one being an 80 character column for code and the other left wide for a web browser or document viewer (this is now my setup when working on 16:9 aspect ratio laptops).

I see a lot of people work on large displays and with multi-monitor setups. Those who do not have their screens split into an 80-character or similar terminal and text editor width columns spend a lot of time switching between screens or applications. Couple this with the fact that you have to move your eyes around a lot on larger displays (and even head, in the case of multi-monitor set ups) and their setups actually make them navigate slower than they would on a smaller display.

> but other than "it's everywhere" is there a more solid reason?

IMO you'd need a pretty good reason not to use the de facto standard, even if it's arbitrary. IIRC it has something to do with the width of teletypes

I know that it has to do with the width of older terminals, perhaps even back to the teletypes. But those hard restrictions don't exist anymore, yet some people treat "80 characters" as some golden law passed down from heaven that cannot be broken lest you incites the wrath of the gods. That kind of fervour (without some sort of concrete, logical reasoning) is nothing but cargo-cultism so far as I'm concerned. E.g. "we do it this way because it's always been done this way."

Just because it originates from teletypes that are no longer used doesn't mean that there's a problem with that width today. We need some standard, because otherwise you end up in formatting hell. There's nothing wrong with 80, so it might as well continue to be 80.

> But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done."

Having shorter lines makes reading diffs easier (whether it's unified, context, or split diffs).

> The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters.

It's actually 72 characters for the commit message body for a similar reason that you mentioned for emails. Specifically, it's because the git log output indents the commit message relative to the diff (when using the -p option).

> Having shorter lines makes reading diffs easier (whether it's unified, context, or split diffs).

But is the difference that significant between 80-, 100- and (say) 120-characters wide? I personally wrap at 100 characters, I don't find that I'm fatigued by looking at diffs of the code.

It is subjective to some extent, but I do find that those who don't wrap their code at 80 characters aren't really particular in terms of wrapping their code at all. So most lines may be between 70 to 130 characters, but there may be the occasional line that's a bit longer.

Plus, it also depends on the tools one uses to review code. Github, for instance, will present a horizontal scroll bar for the unified diff view if there are lines that are too long. Using that scroll bar is not something I appreciate having to do when reviewing code.

Too long lines are harder even in prose as they make you confuse the start of the next line when you reach the end of one.

> The reason I use tabs is pretty simple. It's faster to move around only using the keyboard.

Well, yes, if you use the arrow keys (unmodded) and nothing else. But who does that? Even Notepad lets you jump from word to word with CTRL-left/CTRL-right. Sublime Text must have something similar, surely?

On OSX, in Sublime Text:

- CMD with arrow keys moves to line ends

- Alt with arrow keys moves between words

- Ctrl, under some circumstances, lets you operate on parts of a camelCased or snake_cased word (with backspace and with shift + arrow keys, but not with arrow keys all by themselves)

It's the best setup for moving around code that I've encountered.

I like vims better to be honest. More granularity, and I can stay on home row instead of moving my hand to and from the arrow keys.

Beyond that, this tends to work across all input fields in your OS. If you're missing this you're missing out on being more efficient in any typing based activity.

You are among friends, in your use of tabs and two-spacing at the end of sentences. There aren't many of us, and seemingly fewer every day, but we are a force.

If you're looking for efficiency for text navigation/editing you should consider learning vim/using vim mode in your editor.

Rubber duck is trying to lead you astray. Use emacs!

Every editor made for coding supports moving through whitespace with a single command.

This is extended to all text editing -- use ctrl to modify your movement (arrows, backspace, delete) to word boundaries.

Problem is that moving from and to the arrow keys to navigate is an anti-pattern that is not present in at least vim where you can stay on home row at all times, which is why I dread having to write in editors that don't support a vim mode.

You think you're a rebel? I have my tabs set to three spaces.

You must be stopped!

> Brace yourself: I use two spaces after the end of sentences too. [1] I am quite the rebel.

The paragraph above this one seems to use single spaces after periods. Is this a Hacker News formatting thing, or are you conning me?

Don Knuth seems to agree with you a bit; TeX automatically inserts some extra spacing between the end of a sentence and the beginning of the next one. You don't have to type it yourself though!

That's why most people stopped inserting the extra spaces themselves, instead allowing the layout engine/word processor etc to do it for them.

Then your editor / layout engine has to be smart enough to distinguish between Dr. Smith and the end of a sentence.

> It's faster to move around only using the keyboard.

There are faster ways, at least with JetBrains products, to navigate code that doesn't involve arrowing through spaces/tabs

The only reason I use spaces is the formatting is the same everywhere without messing with settings.

> Brace yourself: I use two spaces after the end of sentences too.

Me too! I was brought up this way. If you want to get into really sick and demented old habbits, my wife indents the first sentence of each paragrah... in emails lol

To me, moving around faster using only the keyboard is an editor feature.

My experience is with emacs but to go from the left margin to the first non-whitespace character across a vast swath of spaces in auto indent mode, I just press <tab> once. I'm sure other editors have something similar.

If you're iterating over the whitespace manually you are doing it the slow way :).

> I use two spaces after the end of sentences too. [1] I am quite the rebel.

Why don't you just use a tab character?

Don Knuth seems to agree with you a bit; TeX automatically inserts some extra spacing between the end of a sentence and the beginning of the next one. (But the extra space is less than one full inter-word space.) You don't have to type it yourself though!

You think you are doing others a favor by using tabs, but in fact you are creating a hassle instead. When I open your tabbed code the first thing I have to do is run it through some script that replaces all tabs with spaces, so that the files will be formatted the same way as the rest of the code base.

Some script? You mean the built in Unix utility 'expand'?

Supposing I submitted code indented with spaces, but the wrong number. Would making the formatting match be easier, or harder?

Maybe you should just use tabs in your codebase.

Maybe you should use the right number of spaces in your codebase.

But what's the "right number"? Space enthusiasts can't agree.

Tabbers know how many tabs to use: one, per indent.

Reply on news.ycombinator.com