This is fantastic, and is how I'm picturing the IDE of the future would work internally, even if it lets people store the files with a variable number of spaces for indentation and does the transformation when reading and writing the file.
Suppose (1) some of your newlines are indented but some are aligned for readability, and (2) mixing whitespace has a tendency to create subtle bugs.
Under those constraints, the only possible choice is spaces. Tabs can indent, but only spaces can either indent or align. Process of elimination forces you to prefer spaces over tabs in that situation.
The problem with this is that if you have added tab indenting to line up with a certain character in the line above, the length of the tab character would affect where the text on the next line is actually placed, depending on individual users' preferences. Spaces are uniform and standard length.
I believe this is the only real argument against tabs. I'd prefer to use tabs because that's exactly what they were designed for, however this use case is fairly prevalent in programming so it can't be ignored.
Mere humans are incapable of doing this right as most don't run with show whitespace (so tabs and spaces look different) & many don't grok the difference between indentation and alignment.
I wonder if gofmt logic can be extended to other languages.
Well, in my opinion doing any sort of aligning-things by hand is pretty tedious. I tend to just use indentation and not worry about alignment in languages that don't have a formatter to do it for me.
E.g. I would write
struct Foo {
int bob;
string alice;
};
and not worry about lining up variables, whereas gofmt would give you
type Foo struct {
bob int
alice string
}
which is fine too but not worth doing by hand IMO.
But if you are, it's not too hard to know where to use spaces and where to use tabs, even w/o show whitespace. But it is true that this is more deeply more than most programmers want to think about indentation. :)
Nah, it works almost everywhere (ignoring things like nim or make that treat them differently); it's not just a Go thing. Here's a random page I found advocating the style for js and css:
And here's what codinghorror had to say about the style:
> This way, in theory at least, the level of indent can be adjusted dynamically without destroying alignment. But I'm more inclined to think of it as combining all the complexity and pitfalls of both approaches, myself.
Which sadly seems to be most people's reaction -- basically, it might be better, but I'll be damned if I'm going to have BOTH tabs and spaces in my files!
Oh well...
Spaces are obviously a workable solution, but there are two really big downsides: (1) it throws away information -- when should I insert or remove a indentation block of spaces? You can make your editor guess, but it won't always guess right, and you won't always be editing inside your properly configured editor. A tab simply says what it means and requires no editor trickiness. (2) The obvious inability to adjust the visual width of the indentation, though personally as long as it's not too crazy I'm happy with anything from 2-8, so this doesn't bother me. (I normally run with tabs at 4.)
Sounds like an argument against spaces. If you indent using spaces, there is no easy way to change the indentation. But with tabs you can change that global width of the tab.
Notably, Go makes a few other decisions that help with this approach:
1) `go fmt` fixes up whitespace, and is fast enough to run on every file-save. Although this sometimes screws up my undo stack.
2) Spaces are still used for alignment, but...
3) Only tabs are used before the content of a line, and...
4) Only spaces are used throughout the content of a line.
The primary reason that I prefer spaces is that it means that I don't have to constantly look at hidden characters while editing. However, go fix's enforcement of the begin/intra-line separation of tabs and spaces alleviates that problem: If it's touching the left margin, it's a tab, otherwise, it's a space.