Tabs or Spaces? The Top Starred Repositories in GitHub Analysed(ukupat.github.io) |
Tabs or Spaces? The Top Starred Repositories in GitHub Analysed(ukupat.github.io) |
Honestly, the hours that have been wasted debating tedium like this in programming...
Because the mapping from one whitespace style to another is not a bijection. Moreover, our source control tools rely on things like content hashes which change when even a single bit of the source has changed, and sometimes even our language parsers depend on whitespace format.
Frustrating, I know, but you will not see a resolution to this problem with automated tools alone. You will, however, when the Tab key is removed from keyboards altogether :)
https://help.github.com/articles/dealing-with-line-endings/
It would probably have to be configured per repo so that it doesn't mess with tab delimited files etc.
Pre commit hooks, combined with an appropriate *-tidy program for your language. Code is formatted according to the repo tidy config with a pre-commit hook and formatted according to the developers preference on checkout.
I'm missing why whitespace style mapping is not a bijection, you do have to accept some limits to code style in terms of completely rigid indentation rules, and it is obviously language specific. But it seems to be a bijection to me, what am I missing?
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.
Everyone else uses spaces because spaces are better than a mix of tabs and spaces and it's extraordinarily difficult to keep spaces out of your files.
i'm always cringing when i see a text encoding option - what I want from source control, is, byte-for-byte, what I checked-in, regardless as to line ending issues that haven't caused a real world issue that i have ever seen... (even in the 90s...).
use windows line endings - they are the way they are for a reason - they work fine if interpreted as unix or mac style line endings. every modern text editor supports all three options (and even some crusty things like notepad or textpad do too).
as for tabs? i find that using any convention works fine in practice, and i stick with 4-spaces/tabs depending on the default configuration of my editor. there is no (good) reason to care about mixing them in the vast majority of languages/compiler environments.
GitHub has addressed them by supporting .editorconfig. Setting a tab size in .editorconfig changes the tab size for viewing files but not diffs (last I checked, a couple of months ago). If any GitHubber is reading, it would be great for that preference to be used for diffs as well!
Go gets even higher, but only because there's an expectation of gofmt usage which converts spaces to tabs.
let x = let x = 1
x + 1
But really, I recently worked on a project where we used 3 spaces, and it's works quite well. Not too little, not too much.
I can't remember why I've never considered it before..
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
I'm not old enough to know personally, but I have a feeling tabs were preferred in the old days in general at least on Unix platforms. Some of that sentiment might have spilled over into Go.
[0]: https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&se...
http://stackoverflow.com/questions/19094704/indentation-in-g...
I say tabs for all!
this is the one strong argument for tabs that i have heard, over and again. it makes a lot of sense.
if this was a real issue i'd fall that side of the argument, since its not i go with the consensus and /prefer/ 4 spaces.
in reality though i end up mixing 4 spaces with tabs based on default editor configurations and i what i end up working with.
it doesn't cause real world problems.
2 spaces is nice if you work in exceptionally backwards command line environments and have no tab character input mechanism (this is not uncommon, although it /is/ stupid imo).
... now a long time ago i did switch from tabs to spaces, the reason was simple, google code and other web based code viewers would use the standard 5 spaces for a tab, so mixed and matched tabs and spaces looked ugly and ascii art in comments would get broken.
i'm not sure thats a real issue any more...
A tab is a special ascii character, which most IDE's replace with spaces if you want to (like you described).
let x =
let x = 1
x + 1
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.
fred /* Fred */
fred(fred) { /* Fred */
fred /* Fred */
} fred {
fred /* Fred */
}
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.
This might be why PEP 0008 urges, "Spaces are the preferred indentation method." https://www.python.org/dev/peps/pep-0008/ [Specifically, four spaces.]
I had heard Google urged two spaces for indentation of Python, per some old style guide, but not sure if that's still followed or not.
In general it tends to have much more religious support among users because of its ease of use and rigid, inarguable formatting.
this is what go does, and it works great. take any gofmt-formatted style, set your tab size to anything you like, and it will still look great.
it's baffling and slightly tragic that this style of indentation is not more popular!
I wonder if gofmt logic can be extended to other languages.
E.g. I would write
struct Foo {
int bob;
string alice;
};
type Foo struct {
bob int
alice string
}
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. :)
Spaces work everywhere.
http://lea.verou.me/2012/01/why-tabs-are-clearly-superior/
> 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.)
Go is making a play to make tab/space mixing work nicely in practice and that's quite interesting to watch.