Gofmt No Longer Allows Spaces. Tabs Only(code.google.com)
code.google.com
Gofmt No Longer Allows Spaces. Tabs Only
https://code.google.com/p/go/issues/detail?id=7101
9 comments
Yep. Asking a developer about style/formatting is an amazing filter if you have a lot of candidates... the answers I am looking for include "the language / platform standard", "the overwhelming most popular standard". The answers I have gotten have been nothing short of insane at times. I had a guy explain to me for almost 25 minutes why HIS system is UNIVERSALLY applicable to our code base, from C and C++ (multi platform) to Python to Makefiles...
Awesome. The only thing that really matters is to have a convention, and tabs has been the accepted convention in the Go community since forever.
Changing go fmt to enforce the convention is simply making sure that people write code the same and frees the developers from the tireless discussion about which one is better. That alone outweigh any disadvantage of choosing one or the other.
Changing go fmt to enforce the convention is simply making sure that people write code the same and frees the developers from the tireless discussion about which one is better. That alone outweigh any disadvantage of choosing one or the other.
This is the oldest most persistent argument in programming.
It seems like a pretty silly argument. As long as there's a standard defined, any competent text editor can handle it for you. Go now has a standard - use tabs instead of spaces - and so the debate is over for this language, everybody set your editors accordingly.
No, Fitz is not advocating tabs over spaces in coding. He is saying gofmt loses a large part of its purpose if it does not enforce a particular style, and the Go devs happen to prefer tabs.
It sounds like he's fine w/ anyone using a tool to format by spaces.
That said, this is quite un-newsworthy.
It sounds like he's fine w/ anyone using a tool to format by spaces.
That said, this is quite un-newsworthy.
I'd say it's newsworthy to large Go shops that use spaces with gofmt and now have to change indentation in their repos. This isn't insignificant. Also it requires additional flags for things like blame/diff to ignore whitespace changes.
no such large go shops exist.
Is it that unbelievable to you that a company that previously used other languages with spaces for indentation would desire to have a consistent indentation policy, especially considering that up until now the tooling supported such desires?
Oooh yes they do. GP and I both happen to work for one. :-)
I wonder if other professions have similar arguments.
I got into beekeeping recently, and it's like this, except applied to everything.
Can you give some examples? I'm really curious.
Easily. Just get any two beekeepers to talk to each other and you'll find plenty of examples. Some common ones:
- Whether to use a [queen excluder](http://en.wikipedia.org/wiki/Queen_excluder) or not.
- What [kind of hive](http://www.beethinking.com/pages/what-is-the-best-bee-hive) to use, even.
- If using a Langstroth hive, whether to use [10-frame or 8-frame boxes](http://www.beesource.com/forums/showthread.php?291373-10-fra...).
- How/when/whether to [feed your bees](http://www.bushfarms.com/beesfeeding.htm).
However, despite having all these disagreements, it's an incredibly friendly community. It's expected that anyone you meet will do things differently from you, so people swap advice and adopt things that work with their style.
Edit: whelp, markdown doesn't work here but I'm too lazy to change it.
- Whether to use a [queen excluder](http://en.wikipedia.org/wiki/Queen_excluder) or not.
- What [kind of hive](http://www.beethinking.com/pages/what-is-the-best-bee-hive) to use, even.
- If using a Langstroth hive, whether to use [10-frame or 8-frame boxes](http://www.beesource.com/forums/showthread.php?291373-10-fra...).
- How/when/whether to [feed your bees](http://www.bushfarms.com/beesfeeding.htm).
However, despite having all these disagreements, it's an incredibly friendly community. It's expected that anyone you meet will do things differently from you, so people swap advice and adopt things that work with their style.
Edit: whelp, markdown doesn't work here but I'm too lazy to change it.
So... tabs or spaces?
I'm personally in the spaces camp but my favorite point in favor of tabs no one has mentioned is all of the bytes you're saving. In a large codebase you can save kilobytes to megabytes by switching from spaces to tabs. :)
Yes, I see the smiley, but I thought it would be fun to measure this effect anyway. I whipped up a small Python script to measure the potential savings, and ran it across the 450kLOC GlusterFS codebase. It reported 3.4MB of savings (both realized and potential because our code isn't as consistent as it could be). I'm generally in the spaces camp myself, and believe that 3.4MB just isn't worth worrying about any more (despite being worth ten of the floppies that were omnipresent even several years into my career), but it's still a surprisingly high number.
Did you take into account filesystem block size?
The right way to solve all this tabs/spaces indentation mess would be to use Elastic Tabstops¹.
1) http://nickgravgaard.com/elastictabstops/
1) http://nickgravgaard.com/elastictabstops/
gofmt already uses elastic tabstops.
To quote [1]:
Not really. Elastic tabstops is about enabling variable width fonts to be used in text (and especially programming) while still lining up tabular columns. What gofmt does is to use spaces to align columns; a method described in http://nickgravgaard.com/elastictabstops/ as a "kludge".
1) https://groups.google.com/d/msg/golang-nuts/93t0LWvHrKM/y6oI...
Not really. Elastic tabstops is about enabling variable width fonts to be used in text (and especially programming) while still lining up tabular columns. What gofmt does is to use spaces to align columns; a method described in http://nickgravgaard.com/elastictabstops/ as a "kludge".
1) https://groups.google.com/d/msg/golang-nuts/93t0LWvHrKM/y6oI...
I predict that this change will be reverted in a few months when the Go team realizes that code is read in a lot of different places, most of which never display hard tabs correctly.
I've read a lot of Go code in many different places during the last years, all with tabs, and I did not have any problems.
Browser <pre supports tabs and defaults to the value of 8 (as is standard), so that shouldn't be a problem.
You can also change it to 4 (which is what most editors use by default) via `tab-size`:
https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size
https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size
What are the pros and cons of each?
Who actually uses tabs instead of spaces? I'm genuinely curious--one of the first things pretty much any project I've ever been involved in has been the setting of tabs characters to become spaces, simply because all text editors are retarded in this regard. This is quite strange.
I do. Tabs are universal. Three indentations? Three tabs. The same cannot be said for spaces. You have to agree upon the width and make sure everyone sticks to that width.
Now, with tabs, anyone may customize how the width is VIEWED, but the representation on disk is universal.
Now, with tabs, anyone may customize how the width is VIEWED, but the representation on disk is universal.
Unsure if trolling or not. It's quite easy to have your editor represent a tab character as "n spaces" - where n is the number of spaces you find pleasing. In fact, I can't recall a serious editor where this isn't the case.
What issues have you seen with regards to using tabs?
What issues have you seen with regards to using tabs?
Grabbing some Clojure code because it's nearest to hand.
Look here: https://github.com/clojure/clojure/blob/master/src/clj/cloju...
I want the bindings being declared within that let to line up with one another. the first one immediately follows "(let [" so I need the rest to be indented six characters past where the let was originally indented. Six, not N times whatever the tab width happens to be in whichever editor someone's looking at the code in. This is the problem with tabs.
Look here: https://github.com/clojure/clojure/blob/master/src/clj/cloju...
I want the bindings being declared within that let to line up with one another. the first one immediately follows "(let [" so I need the rest to be indented six characters past where the let was originally indented. Six, not N times whatever the tab width happens to be in whichever editor someone's looking at the code in. This is the problem with tabs.
> I want
Which is actually the problem gofmt solves.
The desire to express your individual preference through the way code is formatted is an issue not a feature.
The code may be read, maintained and handled by many other individuals during the life of the code, and gofmt is an attempt to provide an incredibly high degree of consistency in the way that the code is formatted to improve those things.
The Go way is simplicity, readability, maintainability.
Once you accept that consistency in formatting is important and a good thing to strive for, the only question is spaces vs tabs. But spaces is a highly opinionated option as the number of spaces used for indentation has to be uniform, whereas tabs allows for each individual to configure their editing tool to permit a degree of individual preference that does not sacrifice any of the consistency.
Tabs have the advantage, please configure your editor to suit your preference and not the code.
Which is actually the problem gofmt solves.
The desire to express your individual preference through the way code is formatted is an issue not a feature.
The code may be read, maintained and handled by many other individuals during the life of the code, and gofmt is an attempt to provide an incredibly high degree of consistency in the way that the code is formatted to improve those things.
The Go way is simplicity, readability, maintainability.
Once you accept that consistency in formatting is important and a good thing to strive for, the only question is spaces vs tabs. But spaces is a highly opinionated option as the number of spaces used for indentation has to be uniform, whereas tabs allows for each individual to configure their editing tool to permit a degree of individual preference that does not sacrifice any of the consistency.
Tabs have the advantage, please configure your editor to suit your preference and not the code.
The way people solve that is tabs for indentation and spaces for alignment. In my opinion this is a terrible compromise as mixing tabs and spaces is sacrilegious.
There is nothing wrong with mixing tabs and spaces. It works great.
Until Python. Then it doesn't.
tabs for indent, spaces for alignment works great with Python.
What's a compromise about it? Alignment and indentation are different semantic things, so it makes perfect sense to mix them.
I'm not sure if there's an "issue" with tabs, but I have to agree that I pretty much never come across tabs in any of the languages I use regularly and find it jarring when I do so despite the obvious theoretical benefit of flexible tab widths enabling user preference.
I can't come up with a particularly good reason for it, but I'm so used to spaces at this point that tabs feel very wrong.
If anyone else has a good explanation I'd love to hear it.
I can't come up with a particularly good reason for it, but I'm so used to spaces at this point that tabs feel very wrong.
If anyone else has a good explanation I'd love to hear it.
> What issues have you seen with regards to using tabs?
How does a team adopt a standard regarding line length if their code base uses tabs and the team members specify different tab widths in their editors?
In my experience, devs that prefer tabs over spaces have a tendency to be unconcerned about line lengths, and their lines of code can become annoyingly long.
For example, the most popular Go project at GitHub[1] is Docker. Docker's code base contains Go files with lines of code that are hundreds of columns wide.[2] Gross. ;-)
[1] https://github.com/search?l=Go&q=stars%3A%3E0&type=Repositor...
[2] https://github.com/dotcloud/docker/blob/master/api/client/co...
How does a team adopt a standard regarding line length if their code base uses tabs and the team members specify different tab widths in their editors?
In my experience, devs that prefer tabs over spaces have a tendency to be unconcerned about line lengths, and their lines of code can become annoyingly long.
For example, the most popular Go project at GitHub[1] is Docker. Docker's code base contains Go files with lines of code that are hundreds of columns wide.[2] Gross. ;-)
[1] https://github.com/search?l=Go&q=stars%3A%3E0&type=Repositor...
[2] https://github.com/dotcloud/docker/blob/master/api/client/co...
Often different editors on a project (hell, even between computers for the same user) may display the same file different ways, and you almost always end up with weird mixes of spaces/tabs when indenting things (especially if you're super picky like I can be and really, really care about things lining up).
Simply having the editor expand tabs (to whatever people agreed on, usually 4 for C/C++ that I've seen) and save spaces, always, makes life simpler.
EDIT:
See Grandpa Zawinski's post on same: http://www.jwz.org/doc/tabs-vs-spaces.html
Simply having the editor expand tabs (to whatever people agreed on, usually 4 for C/C++ that I've seen) and save spaces, always, makes life simpler.
EDIT:
See Grandpa Zawinski's post on same: http://www.jwz.org/doc/tabs-vs-spaces.html
I hate that Zawinsky post. At the top, he says "I'm trying to avoid espousing my personal religion here, I just thought it would be good to try and explain the various sects." At the bottom, after thoroughly missing the point about semantic indentation, he says "So go forth and untabify!"
My project, Pokémon Showdown (https://github.com/Zarel/Pokemon-Showdown) uses tabs, although it's not for any religious reasons, it's just what I was used to when I created the project. I suggested changing to spaces when I learned they were more popular, but my most opinionated coder preferred tabs so I kept it at tabs.
Tabs and spaces both have their respective advantages and disadvantages.
Advantages of tabs:
- you can choose your indentation width in most editors, so coders don't have to agree on indentation width (this is really the only major advantage)
- most very-basic editors that can't be configured, such as Notepad or the command-line directly, will default to having the tab key insert a tab character, which is easier to press than space N times (it's rare to edit code in such cases, though)
- slightly smaller file-size, although this is pretty irrelevant in modern times
Advantages of spaces:
- certain editors are dumb and will mangle tabs in various ways (for instance, converting "3 tabs for indentation, 9 spaces for alignment" into 5 tabs and 1 space)
- most file viewers that won't let you configure tab width (for instance, browsers, which is relevant to viewing code on GitHub) will have tab width set to 8 spaces, which is very awkward
- avoids the problem of some people accidentally using tab for alignment and then having alignment be messed up when coders have different tab width settings
- certain text fields, such as browser text boxes, will have the tab key focus the next input field instead of inserting a tab character, which makes inserting tab characters difficult sometimes (it's rare to edit code in such cases, though)
Tabs and spaces both have their respective advantages and disadvantages.
Advantages of tabs:
- you can choose your indentation width in most editors, so coders don't have to agree on indentation width (this is really the only major advantage)
- most very-basic editors that can't be configured, such as Notepad or the command-line directly, will default to having the tab key insert a tab character, which is easier to press than space N times (it's rare to edit code in such cases, though)
- slightly smaller file-size, although this is pretty irrelevant in modern times
Advantages of spaces:
- certain editors are dumb and will mangle tabs in various ways (for instance, converting "3 tabs for indentation, 9 spaces for alignment" into 5 tabs and 1 space)
- most file viewers that won't let you configure tab width (for instance, browsers, which is relevant to viewing code on GitHub) will have tab width set to 8 spaces, which is very awkward
- avoids the problem of some people accidentally using tab for alignment and then having alignment be messed up when coders have different tab width settings
- certain text fields, such as browser text boxes, will have the tab key focus the next input field instead of inserting a tab character, which makes inserting tab characters difficult sometimes (it's rare to edit code in such cases, though)
You can style tab width in CSS though. If you want GitHub to have smaller tabs add tab-size: 2; to an appropriate selection in your site-specific CSS. I’m sure there are extensions that will do this for you. More info: https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size
This is a huge speculation based only on personal observations, but I'd guess people who got started coding in editors where a space was only a space, so I could indent with one keystroke, tab or with 4+, spaces.
These days I use spaces, because apparently that what is "correct" these days, but I still press tab. Sublime just turns it into spaces and displays the indent as a tab.
These days I use spaces, because apparently that what is "correct" these days, but I still press tab. Sublime just turns it into spaces and displays the indent as a tab.
Linux kernel uses tabs. I'm a fan of kernel-style, so I use it in my personal projects as well. It seems common in C projects, anyway.
https://www.kernel.org/doc/Documentation/CodingStyle
https://www.kernel.org/doc/Documentation/CodingStyle
While I use 2 spaces in all my code because that's the winning convention in languages / frameworks I use, I've always felt tabs were a superior option, most notably because everyone can set tab width to what he likes, so you have a standard file with custom look and feel. I set my tab width to 2 chars ; if an other dev prefers to use 4 chars, there is no conflict.
The annoying part is that you can't set tab width in browser (afaik), which makes it painful reading code on, say, github, and being displayed an indent as the equivalent of 8 spaces. Browsers have to fix that.
So, to answer your question : I do not use tabs, but I would gladly do if offered the possibility.
The annoying part is that you can't set tab width in browser (afaik), which makes it painful reading code on, say, github, and being displayed an indent as the equivalent of 8 spaces. Browsers have to fix that.
So, to answer your question : I do not use tabs, but I would gladly do if offered the possibility.
Virtually every Go programmer does, at least.
Go developers typically use tabs.
You should really try not to use the word "retarded" like this.
You should really try not to use the word "retarded" like this.
Tabs for scope, spaces for alignment.
Spaces make zero sense for indentation. Why would you want to use them instead of tabs, which were invented for indentation and make perfectly logical sense (3 indents, 3 tabs and editors can dynamically adjust the width of your tabs). You get none of that logic with spaces.
Dart, for example, uses 2 spaces. When I write Dart code, I use 2 spaces.
And that's the end of that. As history has shown, there is absolutely no point in discussing this. There is no clear winner.