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.
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.
It sounds like he's fine w/ anyone using a tool to format by spaces.
That said, this is quite un-newsworthy.
- 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.
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".
Now, with tabs, anyone may customize how the width is VIEWED, but the representation on disk is universal.
What issues have you seen with regards to using tabs?
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.
See Grandpa Zawinski's post on same: http://www.jwz.org/doc/tabs-vs-spaces.html
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.
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.
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.
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 is Docker. Docker's code base contains Go files with lines of code that are hundreds of columns wide. Gross. ;-)
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)
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.
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.
You should really try not to use the word "retarded" like this.