I don't understand why this is still an issue in 2015. Why can't our source control software take code indented any way, any how, and convert it to your personal preference when you pull the repo? It's not like we enforce what color syntax highlighting you use or what font.<p>Honestly, the hours that have been wasted debating tedium like this in programming...
I wonder how many of those with tabs prefer their tab stops to be at something other than multiples of eight spaces. If it's half of them that would be about a sixth of the repositories.<p>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!<p><a href="http://editorconfig.org/" rel="nofollow">http://editorconfig.org/</a>
Anyone know why Ruby is 100% for 2 spaces? That seems impossible. Even Go isn't <i>that</i> consistent and it has gofmt which seemingly everyone uses.
I find it interesting that certain languages (F#, Ruby, Scala) are so polarized against tabs. Some make sense, like Haskell, Go, or Python (and, to an extent, CSS), but the rest kind of baffle me.
I prefer leading tabs and spaces for everything else. The fight over tab size is irrelevant in the case where you align with spaces outside of indenting with tabs.
Personally I prefer tabs for indentation and spaces for alignment. Also what's wrong with these charts? They keep shrinking and expanding you can't tell what's going on.
Looking at this just made me realise that IDLE (Python IDE) inserts four spaces instead of tab when you indent using the tab key. I've always used tabs (1 tab = 1 level of indentation) for my personal projects, and only just realised why IDLE's "tabs" seem short by default.
Interesting! I assume tabs being so common in C projects has to do with their use in makefiles. But what is up with Go? Why are tabs used exclusively there? Not a Go programmer so I assume that must reflect something in the language or typical tool chain.
That is a fun analysis, I use 4 space tabs (where hard tabs are in the code, and ts=4 in .vimrc). Hard tabs are essential on proportional font editing systems, otherwise your code goes all over the screen!
I really cringe when dealing with spaces, which is a real problem since I code in Python a lot, which cannot deal with a mix of both. I don't understand people using 2 or 4 spaces at every line, it's so much slower. Sure the first time they probably use a tab and their editor is setup to replace with spaces, but as soon as you go back to edit you need to deal with the multiple spaces.<p>I say tabs for all!
Tabs for indentation, hands down. Every editor out there worth its salt can adjust the tab size the way you want. If you want 1 tab = 2 spaces, you can do that. If I want 1 tab = 4 spaces, I can do that. Either way, it's one tab, and we're all happy. It's literally a win/win scenario. I have never understood the argument for spaces for indentation, not when tabs are at our disposal.