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.
Honestly, the hours that have been wasted debating tedium like this in programming...
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.
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 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.
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.
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.)
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. :)
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.
Which (including the default for windows of 4 and for *nix of 8 spaces per tab) is probably why Python went for breaking everyone's stuff if they didn't use spaces...
> 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.
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 :)
Auto CrLf is a terrible thing that can change the meaning of programs. Source control shouldn't be changing the contents of files (though a hook to format wouldn't be bad necessarily).
Any language that allows string literals to wrap lines without normalizing it. Like C# or F#. Anything with HERE docs might do it, but Ruby and Python seem to normalize.
But I have seen a solution to this problem, back in subversion days. With help from perl-tidy and php-tidy.
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?
that kind of stuff is a nightmare in source control.
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.
Assume that github could do that for you. There would still be some based on tabs some on two sieves and some on 4. This was just looking at what people were using.
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.
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!
Here's the thing though, Python has PEP-8, which is _the_ style guide for Python, and even that is only 91% 4-spaces. So that's pretty much the upper limit on the impact of a style guide on a language's conventions, I would imagine.
Go gets even higher, but only because there's an expectation of gofmt usage which converts spaces to tabs.
I was taken aback by this as well. The Ruby community lets opinions be strong, and tends to converge on 'standards,' so I expected 2 spaces to be a strong winner. But beating out go, which ships with `go fmt`, is a pretty impressive community-wide commitment.
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.
If you use tabs the indentation is broken depending tab size. Some languages prefer needless symbols to do this; I prefer the cleanliness of just whitespace.
I interpreted this to indicate a tribal connection. Where Ruby developers have explored and migrated to other languages like Scala and JavaScript their indent preferences have remained. Obviously this is conjecture but one could test the theory to see which users commit to which types of languages to spot some trends.
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.
Most IDEs I use have 1 tab = 4 spaces visually at least as their default though. It's only old Unixy tools (e.g. Emacs) that default to 8 space tab display.
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.
Not sure I follow. Go fmt is a built-in linter (for lack of a better word) tool. It's not required, it's not unique to Go nor is not using a linter unique to Go users.
In general it tends to have much more religious support among users because of its ease of use and rigid, inarguable formatting.
Yep, gofmt defines and applies a standard formatting that uses tabs for indentation. Using tabs means that everyone can use their own preferred tab stop in their editor while operating on the same code.
I was curious about that too, so I did a little searching around to find out why. Apparently tabs are the officially recommended format and are emitted by the code formatting tool `go fmt`.
In case of C it's not just makefiles, in fact I would guess that the reason makefiles use tabs is because there is a historical preference for tabs in C programmers (just a wild guess really). Various C style guides mandate the use of tabs for indentation (and spaces for alignment), for example FreeBSD's Kernel Normal Form Style[0] (which is really an older standard going back to how K&R formatted the code), I think other BSD's use a simmilar style, and Linux kernel coding style[1].
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.
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.
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.
I believe you are misunderstanding what they're saying. they are saying you use the special characters and your editor can display it as you please (2char wide or 4char wide). if you literally replace the tab char with N spaces, my editor will now show it as N spaces.
> Every editor out there worth its salt can adjust the tab size the way you want
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 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.
Honestly, the hours that have been wasted debating tedium like this in programming...
The proper way to do that would be for everyone to use tabs for indentation. The authors of golang seem to have taken this view.
It'll be an interesting experiment to see if there are any problems with that approach. If not, maybe we can all finally move on.
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.
Doesn't work with comments that float to the right of the code (such as the ones you get with M-; in emacs). Along these lines:
(The reader must make up their own mind about whether this is important or not.)
I'm not sure if you're trolling, but obviously not everyone would agree that this is the "proper way."
I'm not. The obvious way to fix it would be to add a token signifying indenting one level. Why not choose the tab character as the token?
... its almost as if it was entered into the character set for that precise purpose even. XD
Obvious depends on your constraints.
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.
Google's current Python style guide absolutely calls for two spaces. All of the languages I'm familiar with (at Google) do this. Except golang ...
Go actually uses a mix of tabs and spaces in gofmt, tabs for baseline indentation and spaces after that for vertical alignment.
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.
it's objectively the best way to indent, and yet so rare ;(
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.
tabs to indent, spaces to align.
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!
There are more languages than Go and some of them work better with spaces.
Spaces work everywhere.
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.)
It's pretty simple, tabs are clearly superior in theory, by a decent margin. And spaces are superior in practice, by an enormous margin.
Go is making a play to make tab/space mixing work nicely in practice and that's quite interesting to watch.
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
and not worry about lining up variables, whereas gofmt would give you
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. :)
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.
The authors of golang understand that tabs would be the right solution to this, but only if the entire toolchain makes the same choice.
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.
What you're talking about is tabs. Spaces are for people who like to enforce their viewing preferences on others.
Which (including the default for windows of 4 and for *nix of 8 spaces per tab) is probably why Python went for breaking everyone's stuff if they didn't use spaces...
> 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.
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 :)
Wouldn't this feature be similar to how Git converts line endings?
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.
Auto CrLf is a terrible thing that can change the meaning of programs. Source control shouldn't be changing the contents of files (though a hook to format wouldn't be bad necessarily).
Auto CRLF is awesome for languages I use. Which ones can it change meaning in?
Any language that allows string literals to wrap lines without normalizing it. Like C# or F#. Anything with HERE docs might do it, but Ruby and Python seem to normalize.
I believe mapping is 1:1 when only the initial indentation is used with tab/space, and further indentation is done with spaces.
But I have seen a solution to this problem, back in subversion days. With help from perl-tidy and php-tidy.
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'm quite happy with my SCM keeping it's greasy fingers out of my source.
Makefiles need hard tabs. The hours that have been wasted on that insanity... (bonus points for useless error printing)
that kind of stuff is a nightmare in source control.
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.
Assume that github could do that for you. There would still be some based on tabs some on two sieves and some on 4. This was just looking at what people were using.
It's so stupid. And precisely the kind of bikeshedding silliness that persnickety programmers love to waste time with.
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.
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!
http://editorconfig.org/
Huh. Never noticed that GH itself supported EditorConfig. Cool :)
Anyone know why Ruby is 100% for 2 spaces? That seems impossible. Even Go isn't that consistent and it has gofmt which seemingly everyone uses.
The GitHub style guide agrees: https://github.com/styleguide/ruby
Here's the thing though, Python has PEP-8, which is _the_ style guide for Python, and even that is only 91% 4-spaces. So that's pretty much the upper limit on the impact of a style guide on a language's conventions, I would imagine.
Go gets even higher, but only because there's an expectation of gofmt usage which converts spaces to tabs.
I was taken aback by this as well. The Ruby community lets opinions be strong, and tends to converge on 'standards,' so I expected 2 spaces to be a strong winner. But beating out go, which ships with `go fmt`, is a pretty impressive community-wide commitment.
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.
Example:
If you use tabs the indentation is broken depending tab size. Some languages prefer needless symbols to do this; I prefer the cleanliness of just whitespace.
The indentation is fine, the alignment is broken. Tab to the indent level and align after that with spaces.
The actual indent level is wherever the second let begins. It's equivalent to:
Seems inconsistent to have to use a mix of tabs and spaces in different scenarios of visual preference.
I interpreted this to indicate a tribal connection. Where Ruby developers have explored and migrated to other languages like Scala and JavaScript their indent preferences have remained. Obviously this is conjecture but one could test the theory to see which users commit to which types of languages to spot some trends.
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.
Three spaces fares horribly in this analysis. I wonder why the aversion for three? Are odd numbers inherently less appealing?
It's not a power of two!
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..
I will try out three space on my next project.
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
> Your ideas are intriguing to me and I wish to subscribe to your newsletter.
You must be confusing me with someone else
It's a humorous quote from the Simpsons.
When I started out (in C in 1997) I learned doing 3 spaces. That's why I try to get used to 4 (or even 8?) but in reality I still like the 3 most :).
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.
Most IDEs I use have 1 tab = 4 spaces visually at least as their default though. It's only old Unixy tools (e.g. Emacs) that default to 8 space tab display.
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.
gofmt enforces tabs.
Given that, I'm surprised to see that tabs are less prevalent in golang than two spaces are in ruby.
That would be disturbing - it would indicate that people are eschewing go fmt.
It could be more non-go files in the go repos throwing off the numbers?
Go users aren't satisfied with what's already being used? Big surprise.
Not sure I follow. Go fmt is a built-in linter (for lack of a better word) tool. It's not required, it's not unique to Go nor is not using a linter unique to Go users.
In general it tends to have much more religious support among users because of its ease of use and rigid, inarguable formatting.
Yep, gofmt defines and applies a standard formatting that uses tabs for indentation. Using tabs means that everyone can use their own preferred tab stop in their editor while operating on the same code.
I was curious about that too, so I did a little searching around to find out why. Apparently tabs are the officially recommended format and are emitted by the code formatting tool `go fmt`.
http://stackoverflow.com/questions/19094704/indentation-in-g...
In case of C it's not just makefiles, in fact I would guess that the reason makefiles use tabs is because there is a historical preference for tabs in C programmers (just a wild guess really). Various C style guides mandate the use of tabs for indentation (and spaces for alignment), for example FreeBSD's Kernel Normal Form Style[0] (which is really an older standard going back to how K&R formatted the code), I think other BSD's use a simmilar style, and Linux kernel coding style[1].
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...
[1]: https://www.kernel.org/doc/Documentation/CodingStyle
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!
The pie chart would be more readable if the "space count" is directly on the pie slice (instead of tooltip/legend)
Why use such a small selection of repositories? and why does Go seem to use all tabs?
I like the Ruby, it really have example "standard".
Just a side note: why does a website still need to alter my browser's scroll in 2015?
I don't think it does?
Scrolling is really janky for me in FF, but afaict it's just due to the charts being expensive to render rather than the site screwing with scrolling.
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.
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.
You just described spaces for indentation.
A tab is a special ascii character, which most IDE's replace with spaces if you want to (like you described).
I believe you are misunderstanding what they're saying. they are saying you use the special characters and your editor can display it as you please (2char wide or 4char wide). if you literally replace the tab char with N spaces, my editor will now show it as N spaces.
> Every editor out there worth its salt can adjust the tab size the way you want
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...
Spaces for the beauty of code
That's alignment, not indentation. There's a semantic difference there.