Hacker News Reader

Comment by mjburgess | Hacker News Reader

The point of the "tab" option is that there is no consensus on the number of spaces to use -- so by using tab, one uses a single character, and allows the developer to determine screen spacing to their comfort.

"Tab" being a live option is a symptom of the war-never-over in absolute spacing degree -- since different people have different eye-sight, eye-strain, etc. constraints, different linguistic familiarities, code-density preferences, and so on.

View on HN

> so by using tab, one ... allows the developer to determine screen spacing to their comfort

(Allow me to reply to this age-old argument with the age-old counter argument...)

But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on indentation level. This invalidates the only advantage of tabs (assuming file size is no longer a concern).

A common retort is that each reader's auto format (or soft wrapping) can sort out the wrapping. But if each coder is going to reformat the code anyway then they get the benefit of choosing their own indentation level regardless of tabs vs spaces.

> But you also have to decide at what point to hard wrap each line based on a max line length

I think that you should not be doing this, for the same reason that you should use tabs. It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.

But all of this sort of thing is pointless debate these days, when it's pretty fast and easy to preprocess the files to match your preferences prior to editing.

>It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.

And then have merge conflicts between people who set different hard wrap points? Did you mean to say soft wrap point?

Yes, my mistake.

But you don't hard wrap at exactly the max line length anyway. You wrap at the somewhere sensible near the max line length. This is much more tolerable to size changes in indentation.

That's is a much worse user experience. The slack has to be greater for more-nested lines. In other words, you're really just catering to those who have wider tabs.

> But you also have to decide at what point to hard wrap each line based on a max line length

Exact and strictly enforced max line length IMHO unnecessary. Too wide code is hard to read, too narrow too but in between there is a wide range of acceptable values. When possible I treat max length as a recommendation, not hard limit.

When you don’t have a hard limit it’s not a problem if code added by someone who uses visual tab width 2 will go over 78 characters in the editor which tab width set to 4. Equally it’s not a problem when someone using 4 will make a line break sooner than one using 2.

The whole line of thought is just a waste of cycles. /Screams "tabs", sticks fingers in ears and walks away.

I dont even understand what youre trying to describe here. What is a wandering right column?

This argument fails by default if its not understandable.

Like if my tabs are 2 spaces and I save a file like this:

   line1 = wrapped
     + to_here_max
   if something:
     another_line
       = some_val
       + other

Of course this is exaggerated, especially because most lines won't be close to max width let alone exactly at it. But you can set the width of your editor to whatever number of columns that you're hard wrapping to (i.e. what you save in the file) and be sure every line will fit.

Then someone else loads it with tab width set to 6:

   line1 = wrapped
         + to_here_max
   if something:
         another_line
               = some_val
               + other

Now the max column width of a line depends on the syntactic indentation level of it! Any width you choose for your editor will either overflow for some deeply nested lines or waste loads of space on less-nested lines.

Of course it's not a real concern because your editor can probably automatically fix this. But if it's clever enough to do that, then the supposed extra flexibility of tabs is actually possible with spaces anyway.

The war is ending though.

It will be over when we finally format code at read-time so that we respect the viewer's preferences, instead of at save-time to reflect the authors'.

Vertical spacing, ideally, reflects the thought process behind the construction of code: it's semantic.

Read-time revisions to spacing need, only, to change the non-intentional elements of spacing -- indent depth is a very good candidate for this (hence the tab character!).

We already do format code at read-time if you use a decent editor/IDE. You can add smudge/clean filters to Git also.

And what say you about reaching a consensus on the number of tabs to use?!?!?!

If someone uses more than one tab per level of indentation he should be forbidden access to editors for life

And now you understand my method of driving nit picky code reviewers crazy! bwahahahahahhaha

The right number of spaces to use is one.

The problem with this is: 1. It's relatively hard to think it through to the point that you see and have the potential benefits in all cases(*). 2. All participants and tools must fully support the solution. It needs a momentum it never got so the world settled on a simpler solution.

(*) Tabs only and no hard wraps, only soft wraps.

I used to defend tabs for this reason, except I kept running into source code formatters/displays online that would attempt to display my code with the tabstop set to 8 spaces, which made it nigh-unreadable.

While I run into fewer that do this nowadays, it still reminds me that with tabs, What I Write May Not Be What You See, which can lead to readability issues, which I feel is a solid enough point against tabs that I've switched.

I write code so it is easy to read, and spaces are better for that than tabs, so now I use tabs. ¯\_(ツ)_/¯

> I write code so it is easy to read, and spaces are better for that than tabs, so now I use tabs. ¯\_(ツ)_/¯

This is a very confusing final sentence. :)

> that would attempt to display my code with the tabstop set to 8 spaces,

Which is the right thing to do. When did the tab stopped having 8 spaces ?

I personally went through a phase where I compromised by doing one space per indentation level.

Realistically tabs are best when you're alone and spaces are better when you're collaborating IMO.

"The war of accessible vs inaccessible is over; 90% of websites don't use ARIA attributes correctly, so the other 10% ought to give up already."

That's how TFA reads to me. Never give up, never surrender.

But an editor can just as well let the user choose what width to display spaces at the start of a line. Nothing forces them to be the same width as spaces in the middle of a line.

Nope, an editor can do that, but it can’t do it just as well because not all spaces at the beginning are indentation, so then you need to have more complicated rules to differentiate between those cases

Too bad editors can't do something as complex as recognize language syntax. Imagine if we had that feature, then we could do things like syntax coloring.

Sarcasm aside, if your editor can't recognize indentation or adjust indentation according to arbitrary preferences, you really need to update your toolset.

Too bad indeed that your fantasy toolset doesn't exist in reality

which editor does that? space width is defined by the font, and normally you use monospace fonts. i am unfamiliar with any editor that allows you to choose a different font for spaces. besides, it would only work for indents, it would mess up any alignment of code into columns.

None, but it's clearly possible to add since such handling is already present for tabs in almost any editor. I merely mean that there's no technical restriction.

But this option already exists for tabs that are pretty much built for this purpose. It's like adding a fifth wheel to a car because there's no technical restriction even though 4 work fine

But don't fixed width fonts, which many consider the best for code, mean fixed width spaces too?

If that were the case tabs would be fixed width too. But they're not. There's no fundamental reason tabs have to be the only variable-width character.

Tabs would only be variable in the number of spaces uses, but those spaces will be fixed width.

And spaces could be variable in the number of "sub-spaces" used. Each could be say 1/8 of a regular space.

Didn't you read the post? The WAR is OVER. End of discussion!!1

(golang converted me to tabs too)

Not OP, but the article ends with the following question:

> Is it truly over? ;-)

One or two tabs though?! /s

I’d say that one’s approaching resolution, too. And 4 has won.

According to the table in the article there are more languages with a recommended value of 2 than languages with 4. I'm using 2 for Ruby and 4 for Python. I don't remember what I'm using for JavaScript, maybe the same value of the main language of the project.

You should really use 3 since obviously people want a bit more than 2 and a bit less than 4. I use 3 for that reason, as I was most productive at 3. At 2 I don't get an overview easily enough, at 4 indents start to creep too far out making it hard to work in larger functions. 3 is really the smallest number where I still easily saw the big picture structure of a file, so I feel that is the optimal one, at 2 I start to not be able to eyeball how indented a piece of code is.

Not sure why people are so obsessed with having power of 2 spaces, can anyone explain that? Why argue over 2 vs 4 when you can have 3 for everything? I think 4 is better than 2 since 2 is too hard to track, but 3 obviously is better than 4.

I use tab at three. And will do to the day I die.

A friend of mine worked at a place which used three column indents and now I’m fully converted

Sometimes I remember a workplace system I used, where someone had set tabs to 8 space.

I don't know why it was 8, but it was.

It's how they've been interpreted forever on Unix and other old systems

It's probably the main reason why they're so controversial.

Which was influenced by tab stops on typewriters... which were adjustable, but were generally set at 1/2", 3/4", or 1"... which was the equivalent to 5-12 characters, depending on your font (monospaced, but sometimes 10 cpi, sometimes 12 cpi).

The VAX/VMS terminals we used at university to learn Pascal defaulted to 8 space tabs, on a 80 column screen. That certainly pushed some people towards using spaces.

I use 8-sized tabs with 72 columns in C. The human eye doesn't like moving all that much while reading and more windows fit one the screen even if it is annotated with git blame. In addition there is this argument from Torvalds, that you should mind your maximum nesting in a single function, which I also find useful.

> In addition there is this argument from Torvalds, that you should mind your maximum nesting in a single function, which I also find useful.

Note that nesting is a much bigger issue in a language like C where you have to clean up after yourself, in most languages having a lot of nesting in a function isn't an issue.

There absolutely is a consensus: a hard tab is defined as 8 spaces in numerous standards (obviously this only applies to monospace fonts).

The fact that people choose to reject this does not change the reality.

Like what standards, exactly? POSIX in its tabs(1) [0] and expand(1) [1] clearly states that tab stops can be wherever, and "every 8 columns" is just a default.

[0] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t...

[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/e...

That still wouldn't give consensus on how many spaces people using spaces should use, it would (originally) give consensus on how many spaces a tab was supposed to be.

Reality is what people use. Consensus is what almost all people agree on. Standard is just some rule a few people thought would be good to follow.

The few applications that don't let you configure it are less relevant now, and the alternative to consider tabs of varying lentgh would be to introduce a new spacing character in their place; hardly feasible.

Really? What standards are they?

Reply on news.ycombinator.com