6 ms·

Tabs vs. spaces and other holy wars

18 points by wheresvic1 8y ago

wvenable 8y ago
Ha ha. I love it; I disagree with every single conclusion! There is no end to the holy wars.
- wheresvic1 8y ago
  Lol, I wrote it as pure satire because I do exactly the opposite for every single conclusion!
tomcam 8y 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-whale 8y ago
  Seriously?
- Barrin92 8y 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 8y ago
    How this would pass code review before submit?
    - Barrin92 8y ago
      It wouldn't necessarily, but then again it's another thing that code reviewers have to look out for, which is time wasted on other things they could do. I'm in favour of strong uniform rules. Make it 4 spaces, line width 80 and then everybody lives in the same formatting world.
  - 11235813213455 8y ago
    Linting is a better way for that, ex: https://eslint.org/docs/rules/max-depth https://eslint.org/docs/rules/max-depth
- logicallee 8y 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 8y 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-on-coding-standards/ http://www.richardrodger.com/2012/11/03/why-i-have-given-up-...
    - logicallee 8y ago
      Thanks for that feedback :) I suggested it because OP asked for suggestions and thoughts for their new language. I'm kind of peeved at the downvotes because at a minimum it's a reasonable idea to look into - as you've just confirmed, saying you've picked it as the best solution. I thought it's worth considering as the syntax solution for a new language! It's fully orthogonal and removes all style decisions. The compiler never has to guess. That actually means the IDE could be fully sure of it in every case and could let you adjust the tabs, as in this example I put together (using excel and a C program): https://imgur.com/a/s7zQMpw https://imgur.com/a/s7zQMpw ---- I chose my suggestion based on orthogonality. Originally I started suggesting 2-space tabs for OP's new languages (as a syntax feature), since they're a pretty common style convention used by many in the C world, so not totally absurd. But that is not fully orthogonal and hard to automate: if the compiler encounters 3 spaces, what is that supposed to be? Automatically a syntax error? How many indents is 6 spaces again? -- when you use 2-space tabs the answer is 3 //Guess below line's indent level (2-space indents) x With two-space tabs, the answer is 3: //This is indented how many? x a b c x but when you use 1-space tabs the same is: //Guess below line's indent level? (1-space indents) x //Answer: x a b c x You can just count, and it is visually also very clear. As mentioned your IDE can treat leading spaces as indents. (Visually indent them.) It's a 1:1 correspondence. Anyway just my humble suggestion for tomcam's new language, who solicited ideas with "Any ideas?". I gave actual code snippets in my original comment. :)
- aib 8y 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 8y 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 8y 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.
- kjeetgill 8y 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 8y 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.
    - greglindahl 8y ago
      Why would you press space four times? I hit tab and my editor does the right thing. Is there a popular editor that lacks this sort of feature? Edit: it's worth mentioning that this kind of tooling is extremely important, as reducing the issues that drive religious wars is a priceless sort of feature.
    - nicoburns 8y ago
      The point is if you use tabs, the different text-editora which you may need to use foe various specialised tasks can display it differently.
  - JimDabell 8y 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 8y 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.
- baddox 8y 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 8y 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.
  - zokier 8y 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.
  - greglindahl 8y 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 https://github.com/ambv/black I'm not sure if my future co-workers would kill me or not for using it on projects.
    - drunkpotato 8y ago
      I love black. I hooked up blacken-mode for Emacs and never looked back. The best choice is not having to decide at all!
- zokier 8y 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.
- billforsternz 8y 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 8y ago
    Golang is not better than every other language in every single detail, yet gofmt uses tabs...
    - billforsternz 8y ago
      Sorry missed this at the time. Sure, gofmt formats with tabs, perfectly understandable. But very different from Golang refusing to compile code that doesn't use tabs, i.e. "compulsory use of tabs".
- chrisweekly 8y 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.
- mygo 8y 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.
  - antidesitter 8y 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.
    - mygo 8y ago
      this sounds like a non-sequitor. most people complaining about tabs can also configure their editor to make it work for them. Why must I have to? I like my tab bar to actually create real tabs because I actually have my editor show space & tab characters and tabs tell me the intent of the programmer (to indent) better than spaces do.
      - antidesitter 8y ago
        What’s the non-sequitur? I was simply addressing your comment that you must “press the space bar 12 times when you want to indent to 3 levels“.
  - tarboreus 8y ago
- jasonkostempski 8y 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 8y 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 8y 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.
    - deleted 8y ago
      [deleted]
- another-cuppa 8y 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-whale 8y ago
If the tab vs. space conversation ever gets settled, the world will be a little more boring.
- mrwilhelm 8y 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 8y ago
Gofmt, and the problem is done.
- wvenable 8y ago
  But then you have to use Go... :)
  - baddox 8y ago
    Or Prettier for JavaScript, or Black for Python, or refmt for ReasonML.
    - mrwilhelm 8y ago
      Here another wars
    - kjeetgill 8y ago
      Sure, but not everyone uses them. Or uses different formatters. Or different configurations for the formatters. The key thing for gofmt is that it's universal and community backed.
repsilat 8y 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 8y 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 8y 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 8y 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 8y 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.
  - groestl 8y 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 8y ago
All I want is a reasonable standard where I can use a tool to format and enforce it.
groestl 8y ago
Classic false dichotomy, it's both. Tabs for indentation, spaces for alignment.
teddyh 8y ago
The only solution is, and has always been, elastic tabstops: http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/
andrepd 8y ago
It's camelCase, not CamelCase.
- bdowling 8y 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.
deleted 8y ago
[deleted]
teddyh 8y 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/ 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.

18 points by wheresvic1 8y ago

wvenable 8y ago

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

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

tomcam 8y 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-whale 8y ago
Seriously?
Barrin92 8y 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 8y ago
  How this would pass code review before submit?
  - Barrin92 8y ago
    It wouldn't necessarily, but then again it's another thing that code reviewers have to look out for, which is time wasted on other things they could do. I'm in favour of strong uniform rules. Make it 4 spaces, line width 80 and then everybody lives in the same formatting world.
- 11235813213455 8y ago
  Linting is a better way for that, ex: https://eslint.org/docs/rules/max-depth https://eslint.org/docs/rules/max-depth
logicallee 8y 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 8y 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-on-coding-standards/ http://www.richardrodger.com/2012/11/03/why-i-have-given-up-...
  - logicallee 8y ago
    Thanks for that feedback :) I suggested it because OP asked for suggestions and thoughts for their new language. I'm kind of peeved at the downvotes because at a minimum it's a reasonable idea to look into - as you've just confirmed, saying you've picked it as the best solution. I thought it's worth considering as the syntax solution for a new language! It's fully orthogonal and removes all style decisions. The compiler never has to guess. That actually means the IDE could be fully sure of it in every case and could let you adjust the tabs, as in this example I put together (using excel and a C program): https://imgur.com/a/s7zQMpw https://imgur.com/a/s7zQMpw ---- I chose my suggestion based on orthogonality. Originally I started suggesting 2-space tabs for OP's new languages (as a syntax feature), since they're a pretty common style convention used by many in the C world, so not totally absurd. But that is not fully orthogonal and hard to automate: if the compiler encounters 3 spaces, what is that supposed to be? Automatically a syntax error? How many indents is 6 spaces again? -- when you use 2-space tabs the answer is 3 //Guess below line's indent level (2-space indents) x With two-space tabs, the answer is 3: //This is indented how many? x a b c x but when you use 1-space tabs the same is: //Guess below line's indent level? (1-space indents) x //Answer: x a b c x You can just count, and it is visually also very clear. As mentioned your IDE can treat leading spaces as indents. (Visually indent them.) It's a 1:1 correspondence. Anyway just my humble suggestion for tomcam's new language, who solicited ideas with "Any ideas?". I gave actual code snippets in my original comment. :)
aib 8y 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 8y 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 8y 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.
kjeetgill 8y 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 8y 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.
  - greglindahl 8y ago
    Why would you press space four times? I hit tab and my editor does the right thing. Is there a popular editor that lacks this sort of feature? Edit: it's worth mentioning that this kind of tooling is extremely important, as reducing the issues that drive religious wars is a priceless sort of feature.
  - nicoburns 8y ago
    The point is if you use tabs, the different text-editora which you may need to use foe various specialised tasks can display it differently.
- JimDabell 8y 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 8y 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.
baddox 8y 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 8y 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.
- zokier 8y 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.
- greglindahl 8y 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 https://github.com/ambv/black I'm not sure if my future co-workers would kill me or not for using it on projects.
  - drunkpotato 8y ago
    I love black. I hooked up blacken-mode for Emacs and never looked back. The best choice is not having to decide at all!
zokier 8y 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.
billforsternz 8y 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 8y ago
  Golang is not better than every other language in every single detail, yet gofmt uses tabs...
  - billforsternz 8y ago
    Sorry missed this at the time. Sure, gofmt formats with tabs, perfectly understandable. But very different from Golang refusing to compile code that doesn't use tabs, i.e. "compulsory use of tabs".
chrisweekly 8y 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.
mygo 8y 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.
- antidesitter 8y 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.
  - mygo 8y ago
    this sounds like a non-sequitor. most people complaining about tabs can also configure their editor to make it work for them. Why must I have to? I like my tab bar to actually create real tabs because I actually have my editor show space & tab characters and tabs tell me the intent of the programmer (to indent) better than spaces do.
    - antidesitter 8y ago
      What’s the non-sequitur? I was simply addressing your comment that you must “press the space bar 12 times when you want to indent to 3 levels“.
- tarboreus 8y ago
jasonkostempski 8y 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 8y 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 8y 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.
  - deleted 8y ago
    [deleted]
another-cuppa 8y 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-whale 8y ago

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

mrwilhelm 8y 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 8y ago

Gofmt, and the problem is done.

wvenable 8y ago
But then you have to use Go... :)
- baddox 8y ago
  Or Prettier for JavaScript, or Black for Python, or refmt for ReasonML.
  - mrwilhelm 8y ago
    Here another wars
  - kjeetgill 8y ago
    Sure, but not everyone uses them. Or uses different formatters. Or different configurations for the formatters. The key thing for gofmt is that it's universal and community backed.

repsilat 8y 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 8y 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 8y 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 8y 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 8y 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.
- groestl 8y 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 8y ago

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

groestl 8y ago

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

teddyh 8y ago

The only solution is, and has always been, elastic tabstops: http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/

andrepd 8y ago

It's camelCase, not CamelCase.

bdowling 8y 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.

deleted 8y ago

[deleted]

teddyh 8y 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/ 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.