Tabs vs. spaces and other holy wars

https://wheresvic.gitlab.io/software-dawg/2018-08-01-the-holy-wars-tabs-vs-spaces-et-al.html

by wheresvic1 • 8 years ago

18 60 8 years ago

wheresvic.gitlab.io

wvenable2• 8 years ago

Ha ha. I love it; I disagree with every single conclusion! There is no end to the holy wars.

wheresvic1• 8 years ago

Lol, I wrote it as pure satire because I do exactly the opposite for every single conclusion!

tomcam• 8 years ago

Funny and enjoyable, but I have a serious question about tabs. I would actually like to provoke a religious war here because I’m developing yet another language and am trying to decide on spaces vs. tabs.

I don’t mind whitespace-significant languages like Python, but wouldn’t tabs be a better choice? Seems like you can easily get lost after a few levels of indentation, and much more to the point, it seems like tabs are superior because a) your IDE can display them with any width, making it easier to follow long passages with deep indentation, and b) they could free up the editor from requiring a mono space font.

Any thoughts?

ur-whale2• 8 years ago

Seriously?

Barrin922• 8 years ago

your IDE can display them with any width, making it easier to follow long passages with deep indentation

this to me is the crucial disadvantage because it baits people with low tab-width into writing deeply nested code, which is usually seen as a bad pattern, and also blows up on the screen on someone using a wider tab-width.

llukas• 8 years ago

How this would pass code review before submit?

logicallee3• 8 years ago

Any thoughts?

Yes. Model your language on Python except each level of indent must be exactly one space.

Really?? Let's check...

  if am == serious:
   print "Really."
  elif but == srs:
   print "Haha.  But really"
  else:
    print "This line actually a syntax error because wrong indent level."

Just my humble suggestion :)

EDIT: no fair downvoting, he said "any thoughts" and I gave some thoughts, with example.

userbinator• 8 years ago

I played around with various indentation styles and also eventually came to a preference of one space --- all the space savings(!) of tabs, with none of their odd behaviour. As an additional bonus, the column counter of the text editor doubles as a display of the indentation level.

That said, when working with shared code I believe what's more important is "micro-consistency" : the exact style doesn't really matter, as long as it's not so inconsistent that it confuses someone inspecting a function or file. One or ten spaces, or tabs, all applied consistently are far better than things like misleading indentation or mixed tabs and spaces in the same block of code.

http://www.richardrodger.com/2012/11/03/why-i-have-given-up-...

tristanj• 8 years ago

One space indenting makes nested if statements and nested for loops a pain to read. Especially in long functions.

aib• 8 years ago

Tabs for indentation, spaces for alignment.

I honestly think people prefer spaces because it's hard to get the above right. With spaces, if it looks right, it is right.

(Wow, I can't believe I just argued in favor of spaces.)

I'm a tab person myself. With tabs, those 2-space-loving perverts have no power over me!

raverbashing• 8 years ago

Yeah. You know, I'm a tabs live well, but the amount of time fighting indentation/alignment with tabs/spaces is longer than just with spaces.

So, my suggestion is that we indent with dots '.' .

jolmg• 8 years ago

The fact that the topic tends to "provoke a religious war" should be enough clue to know that you need to support both, not one or the other. There's also enough hate for Makefile's required use of tabs to now have yet another language with such a requirement.

If you want your language to have a wide range of users, let me tell that I wouldn't chose to use a language that required me to use tabs. I don't care what awesome features it has. It's a dealbreaker.

By the way, your reason "a" is the age-old argument in favour of tab indentation. You're not going to convince anyone that prefers spaces like that. We've all heard it.

However, your reason "b" is just horrid and invalid. I've never heard of a programmer that would prefer to code in variable width font. OMG.

I'm not going to reply further than this. You have to be trolling.

kjeetgill3• 8 years ago

Spaces 100%. Especially in cases with significant whitspace like Python or heredocs etc.

Personally, I don't get nor like the "adjust to taste" tab argument. I routinely look at the same code in multiple editors. Intellij, vim, code reviews, code search tools, git diff output. In the browser and in a terminal.

Don't break my vertical allignment. I don't need it often but when I do I really need it. Functions with long params. Data points in opengl arrays.

One consistent cannonical form. That's where it's at. That's what I want.

amanzi• 8 years ago

How would using tabs break your vertical alignment? You'd still get the exact same alignment but instead of pressing space four times, you just press tab once. Most IDEs will either convert tabs to spaces or auto-indent based on the language-specific rules anyway, so I really don't understand this argument either way.

JimDabell• 8 years ago

Don't break my vertical allignment.

Using tabs for indentation doesn't do that. Using tabs for alignment does that, and virtually nobody wants that, including people who use tabs for indentation. Indentation and alignment are two separate issues. "Use tabs" is shorthand for "Use tabs for indentation", not "Use tabs for indentation and alignment".

Felz• 8 years ago

I’m developing yet another language

Must you? Is there really no existing language sufficient for your needs?

Otherwise, you should be opinionated on this (and language design in general). Use tabs if you like them, nobody with a half decent editor will notice after two minutes of configuration anyway.

baddox2• 8 years ago

Two completely different rebuttal options to the “IDE can display them with any width” argument:

1) Your IDE can parse code and reformat it in literally any way you want. This includes indentation width (regardless of whether the code is actually stored using tabs or spaces), but also things like line width, semicolons, string quoting style, etc. (e.g. Prettier for JavaScript), or even using completely different language syntaxes that have the same semantics (e.g. Ocaml and ReasonML).

2) Stylistic code formatting choices, while completely ignored by the computer, are important for humans. Some style choices can have significant effects on engineering quality. The obvious example is variable names, but perhaps a subtler example is that a wide indentation width can discourage deep nesting.

bigdubs• 8 years ago

Can always go the `gofmt` route and provide something in the language tooling and take this choice somewhat out of the developer's hands.

gofmt's choices are no one's favorite, but gofmt is everyone's favorite.

zokier2• 8 years ago

I would go further than that and only allow single formatting style in the language at all. Make inconsistent/non-standard formatting a syntax error.

greglindahl2• 8 years ago

I love that concept, but it turns out to be kinda difficult in many languages that weren't designed around the concept.

Here's Black for python: https://github.com/ambv/black

I'm not sure if my future co-workers would kill me or not for using it on projects.

zokier2• 8 years ago

a) your IDE can display them with any width, making it easier to follow long passages with deep indentation, and b) they could free up the editor from requiring a mono space font.

Both points (and more!) can be resolved if the on-disk format is not considered directly the on-screen format. Instead if the on-disk format is considered a serialization of the AST and editors would display it with "just-in-time" formatting based on user-preferences, then that would resolve the tabs vs spaces discussion once and for all.

Incidentally I'm a fan of the concept of structured editing etc.

billforsternz2• 8 years ago

Making tabs compulsory would kill your language dead in the marketplace of ideas even if it was somehow miraculously better than every other language in every single detail.

RobAtticus• 8 years ago

Golang is not better than every other language in every single detail, yet gofmt uses tabs...

chrisweekly• 8 years ago

The tabs advantages you mention are largely hypothetical / theoretical in nature, because there will inevitably be a mix of spaces AND tabs. So the choice is really: "spaces only" vs "tabs and spaces". Which is why spaces wins.

mygo2• 8 years ago

Tabs 100%. Especially in cases with significant whitespace like Python.

Personally, I don't get nor like the "just press the space bar 12 times when you want to indent to 3 levels“ argument. I routinely look at different code in the same editor. Someone’s Python code, another open source library’s Javascript code, some abandoned Wordpress theme.

Don't break my horizontal cadence. If I’m used to single-level indentations being 4 characters wide it really throws me off when I’m looking at indentations a single character wide. I have to refactor the entire code just for the step-indentations to be “normal” for me. A tab-indentation on my editor is as wide as I’m comfortable with.

I don’t care what form someone uses. I’m probably selecting all and converting spaces to tabs when I’m working with it. And maybe I’ll program my editor to automatically convert tabs to spaces when I’m uploading to GIT to make everyone happy. That's where it's at.

antidesitter2• 8 years ago

Personally, I don't get nor like the "just press the space bar 12 times when you want to indent to 3 levels“ argument.

This sounds like a strawman. Most people who use spaces configure their editor so pressing tab inserts spaces. You don’t have to press space 12 times to indent to 3 levels.

tarboreus• 8 years ago

If you're hitting the spacebar more than once, you're using the wrong IDE.

jasonkostempski• 8 years ago

We choose monospace fonts for programming for a reason. Tab shouldn't even exist is a monospace font. If tab hadn't existed out of the gate, no sane person would ask for it to be added.

slavik81• 8 years ago

I used tabs for a bit, then I saw my code looked awful on GitHub because they used a tabwidth of 8. At the time there was no way to change that. I was the only person working on the project, so I switched to spaces. You're still stuck with a tabwidth of 8 on GitLab. And everywhere else it seems to be based on the project's .editorconfig, so you're stuck with whatever the project authors decided anyways.

Tabs are configurable, but configuration is required. You must configure every project for every editor to get reasonable display, which is annoying when possible and even more annoying when impossible.

pseudalopex• 8 years ago

The whole point of using tabs is that the configuration can be per person instead of per project, and pretty much the whole point of EditorConfig is that spaces also require configuration.

another-cuppa• 8 years ago

Tabs are better, yes, for the reasons you stated. But people have too much difficulty using them correctly so we have to make do with spaces.

ur-whale2• 8 years ago

If the tab vs. space conversation ever gets settled, the world will be a little more boring.

mrwilhelm2• 8 years ago

>> It has even been recently surmised that developers using spaces make more money than those who use tabs.

It's even a little less boring after seeing this. :)

Go0the0gophers• 8 years ago

Gofmt, and the problem is done.

wvenable2• 8 years ago

But then you have to use Go... :)

baddox2• 8 years ago

Or Prettier for JavaScript, or Black for Python, or refmt for ReasonML.

repsilat• 8 years ago

Well, at least the article doesn't take itself too seriously.

Most bikeshed discussions, especially wrt code style, are excuses for guys to trot out some toxic masculinity in the workplace. They aren't telling you to alphabetise your imports to improve the codebase but to start an argument they think they can win. It leads to a hostile environment.

The reason spaces "are winning" is that tabs are the "live and let live" solution (read the code however you like) and spaces are the totalitarian solution -- "My code must look the same on your screen." Totalitarianism is naturally proselytising.

Thankfully the end is in sight. "Auto-formatters" are the "total control" endgame. They are probably a net drag on productivity, but they come with one incredible upside: nobody need ever talk about code style again, making the workplace safer for people who don't want to spend their time arguing about things that don't matter.

gsich• 8 years ago

It isn't about saving space. When I ssh into a machine and need to edit a file I use tabs to indent. Those machines usually don't have a vim config deployed and for bash scripts - who cares.

It becomes messed up if you need to edit python files. First check which indendation is used (chances are, that the file was created there, not with an IDE), then use either the tab key (maybe some editor magic makes spaces if spaces are detected for indendation) or space, which makes it more annoying.

wavefunction• 8 years ago

In my highly opinionated...opinion it's far easier to transform a tab into 1 space, 2 spaces, 3 spaces or n spaces than to attempt the reverse for coding while still preserving the underlying indentation.

TuGuQuKu• 8 years ago

It is maddening that there is even still a "discussion" happening. Tabs for indentation, spaces for alignment. Didn't even get mentioned in the article. All the pros, zero cons. Enough of this. Enough, enough.

"Use tabs for indentation, spaces for alignment: the superior approach. Code is indented and aligned properly, and indentation is flexible. Use spaces for both indentation and alignment: still fine, but not flexible enough. Use tabs for both indentation and alignment: completely unacceptable, leads to headaches."

Since this also happens every time, if you're currently writing a harebrained reply about "mixing tabs and spaces!!!!", you don't understand what's being discussed and should permanently recuse yourself from the conversation.

guns• 8 years ago

The problem is that most programmers do not bother to make whitespace visible, so tabs-for-indentation-spaces-for-alignment inevitably leads to a mess of mixed tabs and spaces.

I personally use tabs-for-indentation-spaces-for-alignment in my personal code, but I think I'd lose my mind if I tried to mandate it for a public or team project without a standard code formatter like gofmt.

groestl2• 8 years ago

Even though I'd push for tabs-for-indentation-spaces-for-alignment, I agree with your sentiment.

The "both"-camp is divided in two groups: the "don't care"-group and the "strict rules"-group (the former probably being much larger).

There was a Stack Overflow developer survey in 2017 which concluded that space users make more than tab/both users. Would be interesting to see the results when accounting for above difference in the both group.

jpitz• 8 years ago

All I want is a reasonable standard where I can use a tool to format and enforce it.

groestl2• 8 years ago

Classic false dichotomy, it's both. Tabs for indentation, spaces for alignment.

teddyh2• 8 years ago

The only solution is, and has always been, elastic tabstops:

http://nickgravgaard.com/elastic-tabstops/

andrepd• 8 years ago

It's camelCase, not CamelCase.

bdowling• 8 years ago

That’s lowerCamelCase. CamelCase probably means UpperCamelCase to most people, because it’s what Microsoft standardized on long ago and that’s what so many people learned first.

teddyh2• 8 years ago

Emacs was initially released in 1976 and Vim came much later with its initial release in 1991.

Technically true, but so horribly misleading that I must assume it to be intentional.

You could just as well say that “VI was written in 1976 as a visual version of the older ‘ed’ and ‘ex’ editors, while GNU Emacs was first released in 1985.”

The truth is that both editors have their roots in 1976, got substantial re-writes in the ’80s and ’90s, respectively, and have been actively developed ever since.

The more important (to me) differing factors are things like:

1. Do they follow new developments in computer interfaces?

Emacs got its first graphical version in 1994 (1991 if you count XEmacs, 1985 if you count Zmacs), and keeps improving its graphical fidelity to this day by supporting multiple graphical environments on different platforms (Unix X11, Windows, macOS). While Vim technically has GTK support which adds a menu bar and tool bar, nobody uses it in this way since there is no point; in the main window, it is still is a terminal-style application, same as it was in 1976, with the only addition since then being colors. Compare that to what modern Emacs can look like: (https://www.gnu.org/software/emacs/tour/).

2. Do they get third-party support with packages, extensions, etc?

Emacs has always been very strong here, and modern Emacs has its own packaging system with an app store-style system built-in. From what little I hear about Vimscript, almost nobody uses it, it is not meant for serious programming, and the developers are unsure if it is worth bothering about.

Tabs vs. spaces and other holy wars

Related Stories