I say this as a currently predominantly Python dev, where spaces are encouraged and recommended, but I disagree as stated above.
Currently, I prefer a 2 space indent after previously using a 4 space indent for decades.
Practically, I eventually got fed up explaining this. Spaces only is easier to explain, because there is very little to get wrong with "spaces only".
IIRC the original Sun Java source used an 8-space tab width, and looking at it with a 4-space width made it much more difficult to read.
This probably happens because there are tabs used for alignment too. Like many many many people have said, tabs are for indentation, spaces are for alignment. When people advocate for tabs, they understand their meaning, and they also use spaces for alignment. If someone uses tabs for everything always forever everywhere, they might as well just use only spaces.
The lost freedom can be found again: hack an open source editor to render leading spaces as elements that have a configurable width.
Nobody who calls themselves a programmer should be whining about this, really.
That freedom isn't lost. As the pro-space camp is wont to point out, you're free to pile on another layer of translation software to revert the translation software that transformed the original tab input to a set of spaces.
And because everybody is using programmable IDEs (or IDEs that have had all possible programs precompiled into them), this translation will be part of your 10MB init config file, and because it's 2019 the translation is guaranteed to work with 100% fidelity. It's seamless!
Also, Google uses spaces, and if it's good enough for them, end of story. No matter that KNF (kernel normal form) for Linux, Solaris, and all the BSDs uses hard tabs, not to mention countless GNU projects. Unix developers aren't accustomed to writing readable, shareable source code that interoperates with a diverse set of tooling.
Google using spaces means jack didly squat to me. I dont work for them and never will. Frankly, I disagree with a lot of their published coding styles for Python and C++. It may work for them, and I understand why they may want that homogony internally, but doesn't mean I have to like or use their style.
Don't want to start a holy war, but just my perspective.
That's no argument
EDIT: The commenter is being sarcastic. Don't downvote them :)
Btw, Bill Gates uses tabs[0], so any decisive argument is impossible these days, because of legoog.
Personally, I prefer to make up my own mind on what I use rather than relying on big/ ¿evil corps design practices. I'm with GP and BG on this one though.
[0] https://www.businessinsider.com.au/bill-gates-on-tabs-versus...
All tabs for me. We can configure your editors to show it as whatever we want; no post and pre check in transformation needed. Accessibility is another reason. So really, why is this even an argument?
FWIW, I believe there are other opinions that are at least worthy of consideration, but I think other commenters have made those points as well.
in your company code that only a known set of people need to work with, you can choose whatever suits the group.
but in a public project, the argument that tabs help visually impaired coders is a serious point that is hard to refute.
this reply was killed (probably for good reason) but i want to respond anyways:
there are no IDEs for visually impaired developers. at least i could not find any. all i found was workarounds and extensions. so that supposedly impossible to refute point is hereby refuted.
https://www.microsoft.com/en-us/research/blog/codetalk-rethi...
sure it is possible to add such features but the market for this is by no means mature, and it is not a given that a developer will have these tools available for their use.
If some visually impaired people insist that 80 column punched cards are the best for them, do we switch to that? Or maybe we should all work with Braille or Morse Code? I'm not convinced by lowest-common-denominator arguments. Suppose that no code representation method suits every possible programming minority; do we give up and not code at all?
Here is a counterargument: I'm not switching to idiotic tabs even if doing so saves puppies from being drowned. Not caring is a perfectly valid argument.
Its possible using font ligautures to turn predefined sequences of characters into a different set of glyphs. This is usually used to display nicely joined letters, or rendering multi-character math symbols as a nicer single wide character. An example of the letters thing is the sequence "fi" on mac. It's one I see on macs and in my android keyboard autocomplete.
But you can abuse it. I took a mac fixed width font and added a ligature that turned four spaces into three spaces. And what do you know, it actually worked. I tried it in IntelliJ and with whitespace highlighting on, it correctly takes up 3 spaces but has 4 space markings - so IntelliJ handles it properly.
I don't advocate this, but i would like to make a cli tool someday that lets you take a ttf and add in whater spacing conversion ligature you want.
Every time this subject comes up I get farther down on the opinion that not moving forward from file formats based on what a Model 33 Teletype was capable dealing with is a mistake that keeps on giving.
Which is true. But what if my tools don’t all do that? What if doing so makes it harder to work for some reason or another? Users who use this tab emulation will experience all of the downsides that spaces are supposed to avoid, like misaligning justified comments. I think it’s a waste of effort.
All I can say is, I appreciate the Go team’s decision to use tabs. It makes semantic sense, it puts everyone on the same playing field, and it doesn’t require editor support. Even Windows 98 notepad can be used comfortably as a code editor for tabs-based code, if you for some reason wanted to do that. In reality that is not necessary or desired, but it illustrates that this is the path of least resistance.
That web browsers handle tabs poorly is of no concern to me. If it were really a huge problem, pretty much any editor in existence can do a Replace All to get back perfect spaces-indented code.
The issue is not tabs vs. spaces. It is block indentation vs. alignment. If you use alignment you are forced to use monospace fonts, if you use alignment with tabs, everyone is forced to set the same tab-stop (missing the point of tabs).
Block indentation on the other hand allows people to use whatever font they want (including non-monospace fonts) and what ever tab-stop they want. At that point it doesn’t matter anymore whether the indentation is done using tabs or spaces. The preferred font settings of the developers can deal with it.
Great on new code, but if you're doing this with older and messier codebases and not limiting the formatting to just your changes then you will ruin git/svn blame, at least places that don't ignore whitespace. If others are using the blame tool and frequently see your name then your coworkers might think less of you, even though it was just an auto formatter change.
Ah, so you're That Guy who messes up hundreds of irrelevant lines with whitespace changes along with their bug fix commit. :)
I mean good luck with diffing that.
Sometimes tabs or spaces are data, like in strings. Replace All is too blunt.
Also paste is suboptimal but that’s forgivable.
And finally open a file without /r characters for new lines and have fun!
I've been a proponent of spaces until now because of consistency, but this argument has won me over to tabs.
It seems everyone is giving their opinion except the affected population.
"I will fight Frank to the death on tabs vs. spaces, but Marry wears glasses so she is always right!" Humans are weird.
And to weigh in on tabs vs spaces, or rather not, while I always set my preferred tab with and use the tab key to indent, I don't know what characters my tools insert and I don't or ever have cared.
There's a difference between having a petty argument about something that might cause a slight discomfort to someone, and something that will potentially exclude members of team.
I don't think the form of that reddit post is great as it does have some guilt tripping, but I think the intention behind it is well meaning.
Now whether it's true or not I'm not sure, we can only ask more visually impaired developers to join the debate so we can be informed
So the guy who has his tabs set to 2 and huge font sizes, that's me, because I am disabled, but it could also be my dad, who is just old and would want a larger font size because its easier on the eyes. But we both would still be able to work with bigger tabs or smaller font, it would just be annoying. But that can be true for every coworker, so I think the disabled persons opinion should not have more weight in such a debate.
Leaving alt tags from images makes them unusable for a screen reader though. That argument carries more weight, because the user would not be inconvenienced, but excluded.
And really, I am not arguing against any form of effort to make something work good for all involved, but rather that it often seems that empathy gets only switched on in people when someone plays a minority card. And that sucks.
Is that anything of which to be ashamed?
No, it indicates empathy and a willingness to change to make a task easier for someone.
I don't understand why you think that is weird. Perhaps the zealot hadn't considered that perspective beforehand.
printk(KERN_INFO "%s: blah, blah %d\n",
__func__, arg)
[tab][tab]printk(KERN_INFO "%s: blah, blah %d\n",
[tab][tab] __func__, arg)
Problem is, many editors in "mixed tabs and spaces" mode wants to fill the second line with the maximum possible number of tabs, and minimum spaces. It has no idea that the two belong to the same nesting level. Say that we have four-space tabs. Then the editor does this:
[tab][tab]printk(KERN_INFO "%s: blah, blah %d\n",
[tab][tab][tab] __func_, arg)
Even if your True Scotsman's editor is smarter than this, someone on the team will use something that isn't and mess things up.
Editors ship with spaces over tabs as default, so you should use spaces over tabs. You will be more consistent with others and reduce errors if people somehow haven't picked up your configuration.
Anything else is just fighting the tooling.
Without consistency (hopefully brought by automation) you will find team members struggling with merge conflicts that were unecessary and only brought about because of whitespace changes.
Since we started forcing prettier on stage we've seen a reduction in manual merge resolution being necessary.
And if you're using a tool anyway to apply this consistency, the decision just becomes the following, do you use the defaults or a custom configuration? Your life will be a lot easier if you just go along with the defaults, even if they aren't your first preference.
That's not to say you can't custommise anything (e.g. the default line width of 80 in prettier is too low) but you should have a very good reason to do so. And as others have pointed out, this isn't one of them because tooling can recognise spaces as tabs just as they recognise tabs and still adjust accordingly.
Actually, no, that's a very recent thing. Tabs were the default for decades in the vast majority of editors, particularly on Unix. Even today, if I fire up most vi implementations (I really only use nvi on BSD) tab is the default. Pretty sure this is still the case for vim and emacs, too, and might still be the case for other common text editors like nano.
There's no denying that spaces are far more popular now in general, but I'll have to draw the line at whitewashing history. I haven't been programming for nearly as long as many people here, but IME it felt like the mainstreaming of C++, which brought the Windows/Visual Studio crowd into open source, in tandem with Python[1], were responsible for the dominance of spaces. Even Java code eventually capitulated, where standard practice was originally all tabs owing to it's genesis at Sun. Unix-related software and open source was almost entirely tabs until the early aughts. You can look at the source code yourself, though it's not always obvious because tabs being tabs the indentation usually looks natural regardless of your tab stop.
As I mention elsethread, Linux, all the BSDs, etc still use tabs. Projects with a sufficiently long pedigree typically still use tabs.
(Says a user of JOE, still bitter that Joe relented and changed the default indentation to spaces a few years ago.)
[1] I always wondered how Python ended up standardizing on spaces. I was never into Python, but IIRC Guido preferred tabs. I'm sure there's a story behind it, and have an inkling it's related to the onslaught of developers who cut their teeth in the Windows ecosystem.
Just because tabs would have been the right choice in the past doesn't make it the right choice today.
Also there's a lot of crappy editors that don't handle smart tabs well, including some big, expensive, proprietary IDE's.
(Yes, poor QC and Dev ops went along with it.)
After the first git commit it was obvious that this was going to be a problem, the diff lines didn't match at all.
So I'm seriously considering, after 38 years of being a die-hard 'spaces or death!' user to switch to using tabs with my tab-stop size configured to match my spaces preference.
I just changed my VS Code settings to not insert spaces when pressing tab ("editor.insertSpaces": false) and will see how it goes. Being able to change the tab size ("editor.tabSize": 4) already seems like a neat feature that will come in useful.
It is more work in the editor, so I don't expect it anytime soon. Especially not with consistency. But it is doable.
You have to say how many spaces.
Is it 2? 3? 4? 8? How many?
If you use spaces, you are committing to say how many will represent one indent. And please take note of how your choice affects the visually impaired programmers from the Reddit thread. Or someone like me who finds monospaced fonts hard to read and proportional fonts much more legible.
But why do you even need to say this? Why should it matter how many spaces represent an indent level?
The only time it really matters is when you not only use indentation, you use column alignment, like this:
myFunctionThatDoesStuff(someArgument,
andThisCalculatedOne(anArgumentThatMeansSomething,
anotherWordyName));
What would happen if you abandon column alignment and use only indentation:
myFunctionThatDoesStuff(
someArgument,
andThisCalculatedOne(
anArgumentThatMeansSomething,
anotherWordyName
)
);
Now your code will be just as readable if it's indented with tabs, or with whatever number of spaces you like.
If we coded curly brace blocks the way these standards require us to use parenthesized expressions, our code would end up looking like this:
if(someBooleanExpression) {someFunctionCall();
if(anotherBooleanExpression) {doSomething();
doAnotherThing();}}
If you stop using column alignment, and start using indentation instead, so many problems go away. Space indentation (and how many spaces?) no longer has any advantage over tabs.
I sometimes wonder why so many coding standards mandate column alignment. I think it is because people get tired of talking about it and say "we must agree on something, now! And we will stick with it forever."
I've been in these discussions, and what happens is whoever is most "passionate" about their particular style gets their way. And that will usually be the person who is fussiest about these things, the person who loves fiddly column alignment. Why else would such an impractical approach be baked into so many coding standards?
myFunctionThatDoesStuff(someArgument,
andThisCalculatedOne(anArgumentThatMeansSomething,
anotherWordyName));
The editor has to understand the language fairly well. (In the case of C or C++, it also has to recognize preprocessor lines and treat them specially, as well as certain elements like goto labels that are out of indentation.)
It won't work in Lisps, because in Lisp, nested expressions have their own internal indentation which can be relative to alignment:
(long-function-name (lambda (arg)
(aligned ...)
(stuff ...)))
(long-function-name (lambda (arg)
(let ((var ...))
(stuff arg arg
v v v v v
arg))))
Basically tabs should intelligently be based on preceding material, as if an invisible helper were setting tab stops on our typewriter.
One problem with this is that any piece of software that has to format the code has to implement the same thing, exactly.
Because control freaks still can't accept personal preferences and insist on uniformity, the idea that I won't indentation to look slightly different on my computer than it does on there's is a heresy. If they world were up to them they'd enforce other things like editor schemes, in fact some have tried to: https://vim.fandom.com/wiki/Modeline_magic
First shalt thou press the Holy Tab. Then, shalt thou space to three. No more. No less. Three shalt be the number thou shalt space, and the number of the spacing shall be three. Four shalt thou not space, nor either space thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then, writest thou thy Holy code.
Control freaks should be in politics, management, education, nursing and such, and stay the hell out of software.
sounds like a perfect embodiment of modern software development style.