Developers who use spaces make more money than those who use tabs
stackoverflow.blog
stackoverflow.blog
I'm building an app to help you easily email your congressperson and ask them to create legislation requiring space/tab equality. This has to stop. Please consider donating to my Patreon.
Let's all work hand in hand and follow the style guide! (Which requires the use of tabs, of course)
I actually ask candidates "spaces or tabs?" in every single interview. I don't really care what the response is in regard to the holy war, and it doesn't mean anything on its own, but having SOME thought out response can be a GREAT indicator of how well versed someone is in general.
e.g. I'm going to think way more highly of someone that says "tabs, because then people can set the indentation render size to whatever they prefer in a way that doesn't affect other users" way more than someone who says "whatever my editor sets it to".
Also, fuck spaces. Long live tabs.
That's the computer's job - it should do it based on human readability rules though, clang-format is probably the best example of these rules applied, it uses a TeX-style formatting engine for code.
However it still amazes me how the majority of developers i work with either have no opinion on the topic or worse think this is a bad idea. some the reasons I've heard was it makes alot of changes to a file causing alot of diffs with previous version making it harder to figure was was actually changed, or they don't like they way its formatted .
https://channel9.msdn.com/Events/GoingNative/2013/The-Care-a...
In it, they mention an autoformatter as one of the best tools they gave their developers in terms of productivity gain and it really got me thinking about how this should be versus how it is in practice. There are some really bad autoformatters and some really good ones - find one that works and is configurable to match your standard and I think it really does result in a good productivity improvement.
As long as it's relatively transparent for everyone to be able to use.
You'd only have to do it once, all changes past that point would be good assuming you set it up in your IDE automatically or in your precommit. So if for some reason you needed to go back a long ways and blame something you could always check out back past that initial styling fix and see it.
Regardless, thats a pretty unnecessarily aggressive response to an interview question; or maybe I'm just reading it that way.
It's not meant to be aggressive, but to make a point. It's important that everybody uses the same coding style, regardless of personal preference. Spaces are fine, tabs are fine, but mixing them would be absolutely terrible. A programmer's personal preference for one or the other is irrelevant. What matters is that he's willing to adapt to the coding style of the company.
That sounds like a better answer to the question right there. It's the "some though out response" that the interviewer was looking for, willingness to put the team's decisions ahead of your own, and so on.
Spaces FtW!
Ps. On a more serious note, the editor (actually the vim plugin) takes care of this.. default is 2 spaces for ruby and 4 for python (PEP8). I like ruby more, the identation too.
HOWEVER, a default unconfigured instance of vim is not capable of editing, for example, a YAML file in a valid manner without the user knowing that they have to manually set the tab character to spaces or mash the spacebar 1000000 times instead of using the tab key. Thats some REALLY horribly UX. It's not VIMs fault, and its not the YAML spec's fault, but it adds up to some bullshit.
I can see for people sshing in, editing a file and getting back out without bothering, but you'd have to be a quite a purist to do all your development in an unconfigured Vim.
You can yank and modify existing lines which will keep your YAML spaces.
For years I never used Vim to develop full time so never invested the time to setup my vimrc file. But now that I use it for development and spent the time to set up my vimrc, it's brilliant to be able to just take the goodness with you.
Thats really the only instance. It's more of a "hey, look at this bullshit I'm pointing out from my fundamentalist high horse" argument than a legitimate one.
At most it's a matter of what tools you use as well as accepted standards in the individual programming language's community.
No, it signifies that you have spent enough time programming in a wide variety of platforms and with enough other peers to run in to the issue and understand that it exists.
I wouldn't consider the first to be a good indicator of someone's skill as a developer, and the second would be a good indicator that it was someone I didn't want to work with, but I'm guessing that's not how you're using it...
Or maybe it signifies youthful inexperience?
Of the programmers that I know, the longer they have been programming, and the more varied projects they have worked on, the less they care about tabs v. spaces. Whatever standard the project they're working on uses, that's how they set up their editor for that project, because it's one less thing to have to worry about.
I think that the OP would consider that a fine answer.
Absolutely not. Getting along with the team is a measure of competence. Asking this question can reveal that.
Did you cross-check this against any other measure? I can see it going both ways - maybe someone who saves their attention for more important matters would be better at producing value than someone who cares about such minutiae.
Whats wrong with this? I just accept the defaults. Whether that is what the current project demands or what the editor defaults to. Why waste my time over these things?
There's your answer: if letting your editor do whatever and not caring to 'waste time over these things' means you've committed a bunch of code ignorant of the convention respected by the rest of the project, that's not that great.
If your editor supports a common config format (.editorconfig), then use that... if you're all using the same IDE, then best to adapt to the defaults (mostly).
You are a lucky, lucky person.
To me it makes as much sense as replacing dots with commas, but space indenters have gone beyond their delusion now
To me it makes as much sense as having invisible characters scattered throughout your code, but tab indenters have gone beyond their delusion now
Most editors can be made to highlight it
> that are a different width from any other character on the screen
Yes, and? That's its purpose and it can be configured to your preferred value (beyond unicode)
Tabs for indent, spaces for formatting within. No need to push your tab size standards on the next person to edit your code, and no need to force their editor to retab it to their preference, and back again when it's saved.
"It's the editor's default", or worse, "I never really thought about it" are horrible reasons for doing anything, and hearing something else might be a sign of a pulse.
Therefore, writing 100% spaces to disk is the best way to insulate yourself from possible issues of people who _don't_ know what they're doing with spaces, tabs, or their editor.
That said, the convention for most languages seems to be towards spaces at this point, and I don't care enough to argue anymore as my choice of editor(s) allows me to set it per project at least.
Strong opinions loosely held and all that.
As others have mentioned, having a required auto-linting step helps a lot. But it really depends on your specific needs.
If my dreams come true I will work with Elixir next. https://github.com/christopheradams/elixir_style_guide#space... "Use two spaces per indentation level. No hard tabs." See, this is why I like Elixir, I do not need to change my spacing habits from Drupal! :D
That's where your issue lies; subconscious prejudice is happening during the hiring process, you just can't see it.
To achieve equality you should propose splitting a tab into four tabparts and equating each tabpart with a space. That's true égalité
Brace yourself: I use two spaces after the end of sentences too. [1] I am quite the rebel.
Modern IDE's (Sublime Text) let you easily convert spaces to tabs (or vice versa) and intention length of existing code. [2]
[1] http://www.slate.com/articles/technology/technology/2011/01/...
[2] https://css-tricks.com/changing-spaces-tabs-sublime-text/
This is exactly why I use tabs and the reason which appears to never get cited in the holy wars.
People who use spaces want to line up their '=' signs, that's fine, but I don't believe it's my position to enforce the amount of whitespace another developer has to use in their editor. It's an accessibility thing, they might have their font size really large because of eyesight problems in which case 8 spaces is going to make reading the code a lot harder.
The fact that Python's rule used to be 8 spaces, then got changed to 4 thereby invalidating old code really showed me how shortsighted it is to use a set number of spaces in a whitespace sensitive language.
How does that prevent the use of tabs? You can use tabs to indent, and spaces for your = signs.
> People who use spaces want to line up their '=' signs, that's fine
To me this feels like it's a good use of spaces as well as tabs. Tabs for indentation, to get your nesting right. Spaces to align things. That way setting your tabs to X spaces works just fine and everything remains nicely aligned.
Though I'm not sure how common this is, so I just use spaces.
Not sure what you're talking about here. In Python, as long as the indentation is consistent you could (e.g.) use 2-space indentation to make a code block. It's considered bad practice, and most linters will complain about it since 4-space indentation is the "golden rule."
If you're talking about the Python interpreter's interpretation of the tab character in indentation, that's different[1]. In any case, old code that has 8-space indentation using spaces rather than tabs is still good. The only issue would be old code that mixed tabs and spaces for indentation, which might not match up anymore to make correct code blocks. But, in general, it's just a bad idea to mix tabs and spaces for indentation.
[1] To the uninitiated, the Python interpreter treats a tab as X number of spaces when parsing the source code. This means that technically you could mix a block's indentation between tabs and a corresponding number of spaces. For example, if X = 4, then this code block would work:
def function():
<tab>something()
something_else()That's an irrational choice.
I see this cited every time. Unfortunately, it's bogus in practice. Consider:
print('some long thing',
further, arguments)
If you get this wrong in program parts that are by definition invisible, it might look good for you and look really bad for others (i.e., the opposite of the stated goal). In code I see mixing spaces and tabs, the latter tends to be the case.
also the fly by night devs who still don't see tabs on their text editors... I mean, ide.
This problem goes away if you indent parameters instead of aligning them:
print(
'some long thing',
further, arguments)
[1] https://github.com/pennersr/django-allauth/blob/a44134688f5b...
That being said, this problem and problems like it can be solved simply by not aligning things visually:
print(
'some long thing',
further,
arguments
)
I think that's what the argument really comes down to – alignment flexibility vs display flexibility. It's interesting to see which people generally prefer.
Yes, and I'd say that that's a big problem. I'm not a religious opponent of tabs, but making code less readable just so you can keep using them wouldn't fly if I were Malevolent Whitespace Dictator For Life.
Could you please clarify why do you consider "tabs for indentation, spaces for alignment" such a bad practice? I have never read any argument against it.
Alignment itself can be done automatically by any editor that supports smart tabs.
My process is as follows:
- tabs allow for custom settings
- tabs need spaces to allow for alignment, because previous
- automatically deciding what constitutes alignment vs
indent is a non-trivial problem, highly dependent on the
language†
- using spaces throughout is worse theoretically because
it flattens the theoretical problem but solves impedance
mismatch
- therefore I use spaces and am all the merrier in every practical
use case
- except for languages who make dash 3 easy (such as Go thanks
to gofmt)
- except for projects I have no say in, where I respect the will
of the maintainers, because conventions among well-behaved
people matter more than my highly individual opinion.
In most situations, I consider column alignment to be detrimental to code maintainability. I actually stopped using it long before I switched to a proportional font.
When I later got curious about trying different fonts, I discovered to my surprise that the code looked just the same in a proportional font as it did in a monospaced font.
Regarding margins, if you mean indentation, that works the same in a proportional or monospaced font. The only thing that doesn't work well is the popular two-space indents. That ends up with very little visible indentation in a proportional font.
But to my eyes, two spaces isn't enough in a monospaced font either. It's just not enough spacing for me to see the code structure clearly. Four-space indents solve this problem; tabs solve it even better. When you use tabs, you don't have to argue about how many spaces to use.
I think these are related. Why do people want to use two-space indents? I believe it is often because their lines of code are getting too long. Why are the lines getting too long? Often that is because of the use of column alignment, especially with function arguments and the like.
If you stop using column alignment, your lines will naturally be shorter, and there is less reason to try to save horizontal space with narrow indents.
I've worked with several projects that painfully switched from tabs to spaces because tabs didn't work for them in practice, in a setting where several people work on one thing. I haven't seen projects go the other way. (Yes, automated formatting would solve part of thise.)
One way to avoid this would be use a hanging indent. For example:
print(
'some long thing', further,
arguments)
some_function_name('some long thing',
further, arguments)
The longer the function name, the better the advantage of indenting like this.
When exactly did it use 8 spaces? I have been using Python since 1996 and I don't recall this 8-spaces thing. Almost all code I've seen uses 4 spaces.
In any case, it doesn't matter because, as another commenter pointed out, as long as your indentation is consistent, your code will work just fine, no matter how many spaces you use for indentation. Even if some code does use 8 spaces, it should work without problems. (Tabs as well, by the way... it's mixing tabs and spaces that is a problem.)
It's probably been mentioned 20 times in this thread alone.
Interesting. Unfortunately I cannot find anything on the internet regarding that. Care to share a link proving that?
I suspect this might not be my most popular comment, but I honestly think that this is why tab users might actually make less than space users on average. On average, it's more productive to enforce things than leave everything configurable, thus different everywhere, thus harder to make sense of and debug. I knew brilliant people who don't want to "enforce" and decide and dim people who happily enforced and decided and it's always amazing how badly the former do career-wise relatively to their talent and effort, and how well the latter do relatively to theirs.
(Of course there might be another explanation for the data and I don't claim that my just so story is in any way scientific; though I think it should pass as a scientific theory in the social sciences.)
This is an argument I hear often from tab proponents. What it misses out is the downside: my IDE has a certain arrangement on my screen, and I'll either have to invoke horizontal scrolling or I'll have a bunch of wasted space if you are using different size tabs from me. This is far from flexible.
There's also the (more minor) issue that you then can't line things up on a line below at an arbitrary place if the indentation of the two lines is to be different. This is admittedly less of an issue, but it does arise on the occasion one wants to structure text, for example in a table in a comment block.
I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere. But I'm not writing this to get into a holy war; only to point out that the "it adds flexibility" in your argument is a fallacy.
But the point of tabs is that you tell your editor how many spaces wide you want them to be, so unless I'm misunderstanding you, this is not an issue.
As for lining things up, tabs are used for the indentation level of the current line, but if you need to further nudge things within that line then you'd of course use spaces (after the initial tab indent).
If this arrangement is working, nobody has to scroll horizontally, and there is no arms race of ever-wider editor windows.
Now introduce tabs into this situation. In theory I can set tabs to be whatever size I like. But in practice, I can't make them wider than the last person who worked on the code, because then I'm back to horizontal scrolling. Moreover, if I make them narrower, then they have to narrow their tabs to keep pace. So you get an arms race of tab- narrowing instead of window widening.
I just want to code. I don't want to scroll horizontally, or constantly mess with my window width and/or tab settings to avoid that. It's extra work that doesn't accomplish anything.
Ah, the old argumentum ad ubiquitam, which has saddled us with the x86 ISA, Unix kernels, and other brokenness we can never shake.
So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs.
>I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less).
Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running.
Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...
explode if
> you view a file with a different tab size than it
was created
> with. Again, kind of the point...
It does, as I demonstrate in my quote of you above. Try reading source code like that.
The only sensible way of reading source code is by viewing it with at the same overall window width in which the author wrote it. Viewing at a different tab size destroys this.
> Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running.
Except that I need to figure out the most appropriate tab size to use on a per-file-author basis if "variable tabs" were used, so this doesn't work because I get the problem as described above.
I think that the point was that if your IDE displays tabs as 8 spaces, and you read code written by someone that sets their IDE to display tabs as 2 spaces, then the line lengths will display longer in your IDE.
It "just works" when the writer has configured longer tabs than the reader, but not necessarily in the opposite direction.
> Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...
One example: enforced line-length limits. If you are wrapping at 80 characters with tabs set to 2-spaces, you will display a longer than 80 characters when viewing with tabs set to 8-spaces.
Then open another file, change the tab size again. Or start setting up macros/extensions/whatever to remember or auto-detect settings. This flexibility to have different developers view the same code with different tab widths comes at a cost. Many of those same developers would rather not keep paying the cost, and would prefer that code written by many people fit in their editor/IDE windows and look consistent without any special settings.
I'm curious. Where does 80 characters not work now? How many people / industries are still using green-screen terminals with a fixed-width of 80 characters?
I'm generally in favour of enforcing line-wrapping requirements, because I've worked with people that would have a tendency to write code that trails off the end of the earth if you let them. But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done."
I realize that the 80-character limit is "everywhere"[1], but other than "it's everywhere" is there a more solid reason?
[1] When editing text emails in Vim the default textwidth value is 72, so that there is still some flex for quoting explicitly wrapped text (i.e. prepending "> " to the lines) and staying within the 80-character limit. The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters. etc...
Indented two levels (an 'if' block in a function in a class) and a couple of interpolated variables in an error message isn't unreasonable to have on a single line.
I see a lot of people work on large displays and with multi-monitor setups. Those who do not have their screens split into an 80-character or similar terminal and text editor width columns spend a lot of time switching between screens or applications. Couple this with the fact that you have to move your eyes around a lot on larger displays (and even head, in the case of multi-monitor set ups) and their setups actually make them navigate slower than they would on a smaller display.
IMO you'd need a pretty good reason not to use the de facto standard, even if it's arbitrary. IIRC it has something to do with the width of teletypes
Having shorter lines makes reading diffs easier (whether it's unified, context, or split diffs).
> The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters.
It's actually 72 characters for the commit message body for a similar reason that you mentioned for emails. Specifically, it's because the git log output indents the commit message relative to the diff (when using the -p option).
But is the difference that significant between 80-, 100- and (say) 120-characters wide? I personally wrap at 100 characters, I don't find that I'm fatigued by looking at diffs of the code.
Plus, it also depends on the tools one uses to review code. Github, for instance, will present a horizontal scroll bar for the unified diff view if there are lines that are too long. Using that scroll bar is not something I appreciate having to do when reviewing code.
Supposing I submitted code indented with spaces, but the wrong number. Would making the formatting match be easier, or harder?
Maybe you should just use tabs in your codebase.
Tabbers know how many tabs to use: one, per indent.
My experience is with emacs but to go from the left margin to the first non-whitespace character across a vast swath of spaces in auto indent mode, I just press <tab> once. I'm sure other editors have something similar.
If you're iterating over the whitespace manually you are doing it the slow way :).
Well, yes, if you use the arrow keys (unmodded) and nothing else. But who does that? Even Notepad lets you jump from word to word with CTRL-left/CTRL-right. Sublime Text must have something similar, surely?
- CMD with arrow keys moves to line ends
- Alt with arrow keys moves between words
- Ctrl, under some circumstances, lets you operate on parts of a camelCased or snake_cased word (with backspace and with shift + arrow keys, but not with arrow keys all by themselves)
It's the best setup for moving around code that I've encountered.
The paragraph above this one seems to use single spaces after periods. Is this a Hacker News formatting thing, or are you conning me?
Why don't you just use a tab character?
There are faster ways, at least with JetBrains products, to navigate code that doesn't involve arrowing through spaces/tabs
The only reason I use spaces is the formatting is the same everywhere without messing with settings.
> Brace yourself: I use two spaces after the end of sentences too.
Me too! I was brought up this way. If you want to get into really sick and demented old habbits, my wife indents the first sentence of each paragrah... in emails lol
Of course, if all of the top companies are requiring spaces, then there's probably a reason for that, and its impact on salary data is thus meaningful, not just a spurious correlation.
I'm impartial to downvoting as to reply literally doesn't usually add to the conversation, which is generally the point of downvoting. Losing karma shouldn't hurt your feelings.
Agreed, this is why I didn't want to take a hard position on downvoting someone for missing the sarcasm. We're in a public forum which crosses cultural boundaries. I see the argument for both sides.
Although I lean more towards downvoting as the majority of people on HN will get the joke and it's an opportunity to learn for those unfamiliar with the mainstream culture.
they are publishing a very limited, informal, unscientific, survey and having fun drawing outlandish conclusions.
if you think this was serious in any way you may want to bring back pirates to counter global warming.
It's official: science proves that highly paid tab users just don't need it.
I'd also like to see an analysis of space-vs-tabs as it relates to operating systems. Again, from anecdotal experience, it seems spaces are more common for folks with *nix background who tend to work in product-oriented companies (i.e. where code is an asset) and tabs are more common with windows folks, who tend to work on IT (i.e. where code is liability)
Case in point - I use the default Visual Studio settings which are spaces, BUT they weren't always. I remember as recently as 2008 tabs were the default.
I've mostly only ever worked in Windows environments with the odd linux machine here and there, but mostly Windows, I've worked in both I.T. and product-oriented shops. I've mostly favored spaces. I've never been questioned it or asked to do differently. Generally speaking, those that care about the money, don't give a fuck about whether I use tabs or spaces. I've worked in tight-ass shops that have nickeled and dimed for every cent savings and I've worked for shops flush with cash to pay developers to do it right.
In my actual experience, I've never seen any relation to tabs vs. spaces with regards to being paid more. Nobody that has ever paid me for what I do has cared about which I use, nor have they questioned it.
One thing I have noticed in programmers are an asset vs. programmers are a liability is that companies who understand that automation is going to extend their profitability by more of a margin than it costs them will pay you what you're worth. Those that view programming as a sunk cost, that just makes their lives easier or cuts costs will pay you what they can get away with.
Don't work for a company that views you as a cost centre. Work for a company that views you as a profit centre. The work will be more meaningful. You will be more fulfilled. You will most likely be less stressed and you will most certainly be appreciated and respected more.
You got it backwards. In companies that sell code, code is an asset. In companies that sell services code is a necessary evil.
If you're a software developer and you're part of the "IT" department, then you're a liability. Your code is a necessary evil.
If you're not part of the "IT" department, then you're working in a product-oriented environment where the company is selling your code (either as a good or as a service) or otherwise making money from the code. In that case, your code is an asset.
* Joe likes 4-space tabs, I like 2-space tabs, and Jane is old-school with 8-space tabs.
* All goes well until someone aligns something visually, like so:
void someNiceMethod(* Now it aligns perfectly on my machine, looks mostly ok on Joe's machine, and is ON MARS on Jane's machine.
Thus one-or-more of three futures happens:
* Someone implements a code re-formatter into version control
* Someone re-aligns the code, starting the process over again.
* Someone calls a meeting and demands we all switch to spaces
[tab]void someNiceMethod(
[tab][space*20]int arg1
[tab])
(edited for line breaks)
It seems to me that using tabs for indentation and spaces for alignment is a fragile technique. It's easy to make a mistake and not even notice. If you don't fix that mistake fast, people start to assume that maybe it's OK to ignore whitespace formatting issues. And so the problem compounds.
I would prefer to use a system that creates a "pit of success" so that even careless people have a hard time doing it wrong. I think sticking to just one whitespace character is better than mixed tabs and spaces, but best of all is using an editor that can automatically format your code.
That said, all you would need is editors to enforce "any line with spaces before a non-whitespace character must have exactly the same number of tabs as the previous line." Which would not be all that difficult, but currently (afaik) does not exist.
void someNiceMethod(
<tab>int myParam...
);
As a bonus, this indentation style works equally well if Jim uses a non-fixedwidth typeface.
http://www.stroustrup.com/3rd_notes.pdf
> At first glance, this presentation style will seem ‘‘unnatural’’ to programmers accustomed to seeing code in constant-width fonts. However, proportional-width fonts are generally regarded as better than constant-width fonts for presentation of text. Using a proportional-width font also allows me to present code with fewer illogical line breaks. Furthermore, my experiments show that most people find the new style more readable after a short while
Great book, and I have used proportional fonts occasionally. It's much much better than you might imagine (as long as you are sane and use tabs for indentation). Obviously you can't get "perfect" alignment like you can with fixed-width fonts, but it is certainly nicer to read, so there is a trade-off.
All-spaces lets the code look as-intended for everyone, and then their IDEs can let them hit the tab-key and get the look-and-feel they're after. It is the best option that gives the most freedom to everyone whilst also making us all play well together.
[tab]void some nice method(int param a,
[tab] int param b
[tab]void some nice method(int param a,
[tab][tab][tab][space][space]int param b
So whether to prefer tabs or spaces, to me, depends entirely on how much you can/want to trust your coworkers to follow the coding standards.
Edit:
Or as pointed out below, change your coding style to this:
[tab]void some nice method(
[tab][tab]int param a,
[tab][tab]int param bSpaces in a fixed width typeface will be up to about 5 times as wide as in some proportional width ones.
What actual benefit does tabbing even get you at that point?
"Could" happen the other way too, but I think: If you use spaces you typically dont repeatedly hit space to produce a single indent. You use tab which gets translated to spaces. Once the editor is set up for this, you don't accidently insert tabs for indentation.
> * Someone calls a meeting and demands we all switch to spaces
They compromise on the average 5 spaces per tab and everybody is dissatisfied.
I have been programming for most of my life, and I still don't know why people do this. I just don't feel the need to align stuff.
I generally prefer tabs because I feel that they're more egalitarian: I like 4-space indentation, but don't want to force that on everyone encountering my code. Similarly, I find 2-space indentation very hard to parse in most languages, so I don't want that affecting me if I can get away with it. While this is possible with spaces and maybe a series of Git hooks, it's trivial with tabs.
On the other hand, I always use spaces in languages like Python or Ruby where there are well-codified style standards. I also always show invisible characters on any editor which allows it, and have cleanup scripts to ensure that whitespace is standardized across any non-vendor code in the project.
Maybe most tab users don't feel this way? Maybe most aren't as careful/picky as I am? Maybe tabs are more popular with younger devs? But I feel like tabs can offer more interoperability than spaces when many coders are working on the same project when the language/community doesn't strongly specify whitespace.
wat
Tabs are better for indentation preferences. Spaces ensure that everyone sees the same thing, which can help in multi-line situations.
So I wish people would avoid this black-and-white discussion. Use tabs for indentation, and spaces for multi-line alignment...
I think the real problem with tabs is that so many people use weak editors.
--def myfunc(
---foobar = 1,
---...baz = 2
--)
No matter what size tab stops you use, the `=` will always line up vertically, because the tabs are only used for the indentation (nesting level), not the visual alignment.
^ complaint about "black-and-white" discussion
"Use tabs for indentation, and spaces for multi-line alignment..."
^ totally "black-and-white" solution
:-D
If you configure your editor to drop spaces when you hit 'tab', then the file is guaranteed to look the same for everyone, and stops being context-dependent-- a bad thing for plain text, IMO.
This will keep the vertical alignment regardless of the preferred width of the tab.
int f() {
int someVariableName = myFunctionCall(expr(5), // <--- line A
somethingElse(9), // <--- line B
a_long * expression + involving(multiple.subExprs));
int d = somethingElse; // <-- line C
}
Or are you saying that both A and B are indented with spaces? Then what about line C, which will misalign with A and B if your tab stop is a different width?
Or do we indent the entire body of f() with spaces, and then in that case you're basically using spaces everywhere, which the good idea that sparked this whole thing?
B is indented with a tab, plus the requisite number of spaces to line up with the above line.
C is indented with a tab.
1 int f() {
2 >---int someVariableName = myFunctionCall(expr(5),
3 >--- somethingElse(9),
4 >--- a_long * expression + involving(multiple.subExprs));
5 >---int d = somethingElse;
6 }
/*t*/int f() {
/*tabs*/int someVariableName = myFunctionCall(expr(5), // <--- line A
/*tabs*//*--------------spaces--------------*/somethingElse(9), // <--- line B
/*tabs*//*--------------spaces--------------*/a_long * expression + involving(multiple.subExprs));
/*tabs*/int d = somethingElse; // <-- line C
/*t*/} int f() {
<tab> someVariableName = myFunctionCall(
<tab><tab> expr(5),
<tab><tab> somethingElse(9),
<tab><tab> a_long * expression + involving(multiple.subExprs)
<tab> );
<tab> d = somethingElse;
}Soft tabs FTW.
(F#, where indentation matters, and Clojure using Parinfer where indentation matters to get the form placement correct both make tab characters horrible to use.)
silly js devs and their var block...
Hm,... that could actually be a feature! Adding inertia. Not that I would use that, but it makes me think..^^
If I was working on a project where there was a strong preference for indenting assignments, or any other case like this, I would use spaces throughout.
If I was working on a project where there was a strong preference for indenting assignments, or any other case like this, I would use spaces throughout.
So by choosing tabs, either the file must be consistently formatted with tabs by everyone always, or everyone must look at the code in the same editor configured in the same way always.
I remember reading jwz's rant on this long time ago and not getting it until I had the first what-is-going-on-here moment due to wrong indentation from mixed tabs and spaces. jwz is right. Stop using tabs.
About your argument, though: Isn't is also possible for someone to copy/paste something with tabs into space-indented code? Isn't is also possible for someone's editor to start off with tab-based indentation by default instead of space-based and mistakenly add the wrong whitespace to the project?
If everyone used tabs perfectly, I'd be fine with them...
As I've said in other parts of this thread, I'm not that worked up about tabs vs. spaces, and I use spaces most of the time. I just don't find this argument for space superiority very convincing.
PS: If everyone showed invisible characters in their editors, I think the world would be a better place.
And if you stick to only spaces it is trivial to reject tab containing code in commit hooks. It's harder to reject code that uses spaces wrong in tab-indented code, unless you outlaw spaces for alignment too.
I would expect there simply is a confounding factor that the author did not look at. Maybe the info is not in the data.
I can imagine that the space/tab choice is related to the "upbringing" of the developer. Maybe which language or editor they used first in their life.
Or maybe it's related to culture. For example when using IRC, tabs are usually not used to communicate. Maybe that impacts the general choice of tabs/spaces.
Or maybe more sophisticated users tend to exchange the tab key for something else:
The years of experience variable might be taken to explain away the effect of experience, and then conclude that tabs vs. spaces must be due to another effect than years of experience. But chances are, that "years of experience" and "tabs vs. spaces" are just correlated to a common, causal property (like "programming proficiency" or however you want to call it). Both "years of experience" and "tabs vs. spaces" are then just incomplete reflections of the underlying cause, both rendering the effect of the underlying cause incompletely.
What I am trying to say is: Its complicated, probably you won't be able to find the one true cause for the effect in the data. If this were physics, one could come up with a predictive theory to put this to the test. In social studies, we just cannot control the parameters well enough.
If you are interested in reading more on this, "Causality" by Judea Pearl is a good (but exhausting read).
If you hit Tab in IntelliJ or a related IDE you get a file with spaces.
If you hit Tab in an older version of VS (the kind you'd expect in certain types of settings where high pay is not usually expected) you get tabs, but in newer versions you get spaces (with defaults)
In this case it is supposed to override your IDE settings.
The average "sweatshop/devshop" developer probably doesn't even know/care about tabs vs spaces.
It's a holdover from my emacs days; the one thing I could not give up from emacs...
Those who grew up in a shell often ended up building a much more diverse set of skills, the commonality of which is a lot of text based files with a favourite editor.
This extended to using tools like IntelliJ, Eclipse, etc.
Hope a follow up of this study can include the IDE's and if that has some say in this.
If you are not born in the nobility that uses spaces, but if at first contact the people in power see you using spaces they might assume you are born a noble, and lower their anti-commoner guard for you and you have a greater chance of entering the nobility without a proper title (don't forget to slam the door after you, nobility only works on exclusivity).
So there is a path for taking the implication completely backwards and still reaching the expected outcome.
Then forcing yourself to use spaces might reduce your productivity, your self-esteem and your mood.
Big companies tend to pay more in the software industry. Big companies also tend to have standardized on tabs or spaces internally to simplify the problem of merging code across developer teams. So if you find out that, hypothetically, Amazon, Microsoft, Google, and Facebook have all standardized internally on spaces, that alone could account for the data.
It looks good that I'm such a hard worker. So I get paid more.
- "TABS WORK GREAT FOR ME" -> First-order effect
- "If someone else views this file with a different tab width preference, the indenting will match their preference" -> Secondary effect
- "If users' preferences can change the indenting of a file, then vertically aligned elements will align or misalign depending on who's viewing it and who wrote it." -> Tertiary effect.
- "Randomly broken formatting and/or forcing users to constantly change their personal tab preferences is a bad way to work with code" -> Quaternery effect, etc.
In other words, a whole-system view that accounts for interactions with other decisions might lead you toward using spaces, while an immediate "local" view might lead you to choose the thing that seems most convenient right now.
This means you consider consequences beyond "but it works on my machine" so you're a better programmer. Ergo, higher salary.
Unless the project's settings are to use spaces.
Respect .editorconfig files
So in the long run, the indentation WILL get fucked up and you WILL miss something when fixing a bug in code that you or someone else wrote 6 months ago. And your 10 minute bug fix will take 3 hours. Multiply both values by a constant factor as necessary.
It's simply not worth the trouble.
Huh? Things indented to 1 tab will align with everything else on 1 tab. Things aligned to 2 will align with everything else at 2 tabs.
>you have to use a space or three somewhere
Why? Tabs will indent with other tabs.
>you never know if it's spaces, tabs or a combination of them in existing code
Well they should never be combined for indentation. Unless you mean using tabs for indentation and spaces for alignment, but this wouldn't create any issues. Using tabs for spacing is objectively poor form.
I open space- and tab-indented files in my IDE, they are all converted to tabs. It is always consistent.
Um... I always know because I always set my IDEs to show those characters. You don't?
Also, most people who do have several years of experience under their belt will tell you: don't align. Mid-line alignment is a waste of a maintainer's time to have to update alignment blocks every time you add/remove variables... and statement-alignment is unreadable[1].
[1] https://github.com/pennersr/django-allauth/blob/a44134688f5b...
On a large code base with multiple committers, I've never seen this rule followed consistently. In fact, I think this shows a poor engineering decision: "Let's make a rule where everything looks OK 95% of the time, except when you change tab widths (which is, presumably, why we made the rule in the first place.)"
The crux of the issue is poor tooling. Aligning correctly is a pain because most editors suck terribly at it. For instance neither emacs nor vim align correctly when using tabs by default (they use as many tabs as they can and then pad using spaces, instead of indenting only with tabs and aligning only with spaces). If they did it would be painless to indent and re-indent.
When some of the most venerable code editors out there can't even seem to get it right I think there's no point in fighting it. Learn to stop worrying and love the space, I know I did. Or alternatively use a language like go which provides a standard tool to indent everything, make it mandatory pre-commit and never look back.
But I never found a single editor that handles spaces correctly. I currently use vscode with vim bindings and whenever I deal with a space-indented codebase I want to tear my hair out: I inconsistently have to hit backspace sometimes once, sometimes multiple times to get rid of an indent level in insert mode. And don't get me started with yaml, a really painful experience to edit it.
If you try this, it fails for people who use a different tab size than you, which is the whole supposed point of using tabs.
But yes, the correct answer is don't align. Utter waste of time.
If it fails, then you have not understood and you are not using your tools correctly. If your alignment depends on tab width, then you are not using tabs for indentation and spaces for alignment, you are using tabs for indentation and alignment and spaces for alignment, which of course breaks when you change your tab width.
I believe older versions of Xcode did that by default with objc (maybe still; didn't check lately) if you press enter in the middle of a function argument list. Really annoying.
The other thing you need to do is stop people from checking in code that doesn't follow project conventions.
https://github.com/ioquatix/rack-freeze/issues/2 https://github.com/ioquatix/latinum/pull/1
>deliberately have my editor set up to change tab width based on editor width (responsive indentation width)
What editor are you using that has this setting?
Firstly, I've explored using responsive tab width in https://github.com/ioquatix/jquery-syntax which is nice when presenting code on a mobile phone.
Secondly, I've got hard coded tab width on my desktop with a huge screen vs my laptop with a smaller screen, and this works for all editors, including my primary editors Atom and vim.
Finally, I've played around with using responsive CSS within Atom, but due to recent changes in the text rendering my current CSS doesn't appear to be working.
Trivially easy to set up your editor correctly once (if you even need to) and now everyone gets their preferred intenting size
If anyone can post a sizable production code base that uses tabs that DOESN'T look like shit with a different tab width, I'm certainly open to being proven wrong.
Here and there's the problem. Too many people with editors that go round replacing N spaces with tabs everywhere to have sane alignment in a code base with >1 developer...
Notice there are a couple examples in that code where multiline method calls are meant to line up, and if tabs are not set to 8 they don't line up.
I do it myself but it requires a bit of maintenance and I wouldn't trust teammates with it. There will always be some guys who don't understand the idea and mess everything up.
In a team environment, now, I wouldn't chose anything but 4 spaces. Speaking from experience.
- with anything but 2, 4 or 8 spaces, some guys with incorrectly set up editors will mess everything up.
- tabs don't work well for alignment, and as long as you allow the tab character, someone will make a mess.
- 2 spaces is not enough to properly distinguish between blocks.
- 8 spaces can look very nice if your code is very clean. It won't be the case of your project.
On the other hand, I find 2-space-indented code unreadable; in fact, 4-space wide indentation is the only size I find to be readable. I know plenty of people for whom that isn't the case. Using tabs lets the reader set the indentation level.
¯\_(ツ)_/¯
Edit: All the anti-tab arguments I'm reading below boil down to alignment. Don't align folks; there's good reasons not to align regardless of your indent style.
They're fine for solo projects i guess, if you only ever use one editor.
Edit: Also, in the long run the best thing you can do to your code is to make it easily readable. You will forget what you did. Not to mention your colleagues that have never seen it. So time spent aligning parameters to make code more readable is well spent, if you ask me.
How is this[1] more readable than this[2]?
[1] https://github.com/HearthSim/python-hslog/blob/5a6ad9a29a7d4...
[2] https://gist.github.com/jleclanche/ef40058731061e26d218e2a4c...
Let the lines get long enough and the latter is actually quite a bit harder to read; try to follow the variable all the way to its value and you might actually jump and be one line off.
I deeply care about readability and code style, that's why I'm replying here :) And in all the codebases I have read and written, alignment has consistently been harmful to readability and maintenance.
someFunction(firstParam, secondParam,
thirdParam, fourthParam);
someFunction(firstParam, secondParam,
thirdParam, fourthParam);
I agree that aligning '=' is actively harmful in the example you give, and that it's harmful in most situations where it's used. I've encountered very rare instances where it's helpful, though. Sometimes you have a sequence of values defined by expressions that follow a pattern:
enum someEnum {
FIRST = BASE + MASK & (1 << 0),
SECOND_VALUE = BASE + MASK & (1 << 1),
TH = BASE + MASK & (1 << 2)
}
enum someEnum {
FIRST = BASE + MASK & (1 << 0),
SECOND_VALUE = BASE + MASK & (1 << 1),
TH = BASE + MASK & (1 << 2)
}
You haven't looked very far! Most open source projects these days enforce code style through some forms of tooling.
But saying that "Any coding standard that relies on humans to do something right is going to fail" is basically giving up and saying "do whatever". I mean, why even ask people to indent consistently if it's doomed to fail? It's a mixed indent party for everybody!
Sure, but I've never seen a tool that was able to enforce that no-one was doing alignment.
> But saying that "Any coding standard that relies on humans to do something right is going to fail" is basically giving up and saying "do whatever".
Coding standards that you can implement in your enforcement tool are fine. But any rule you can't automate is not worth bothering with, IMO.
> I mean, why even ask people to indent consistently if it's doomed to fail? It's a mixed indent party for everybody!
Use a language that enforces indentation, or use a tool to autoindent. Trying to get people to indent consistently by hand is a waste of time.
Examples of autoformatters:
YAPF for Python
Gofmt for Go
Rustfmt for Rust
1 tab will render to whatever the next programmer prefers, it's only courteous.
Many languages have a coding style preference. Go is super opinionated, Python in the middle, with C being as conflicted as it gets. Whatever you use, follow the style the language or team is a proponent of.
Sure, but how many spaces? grabs popcorn
Visually I can have it display in my editor of choice (Kakoune at the moment) however I want.
I guess I'm just saying, I would have thought the most common answer to this question would be: Whatever my employer / language standards dictate.
Imagine that half of those interviewed worked at Google.
Awyis I'll be rich in no time!
https://en.wikipedia.org/wiki/Whitespace_(programming_langua...
From the Wikipedia article (https://en.wikipedia.org/wiki/Tab_key):
> A common horizontal tab size of eight characters evolved, despite five characters being half an inch and the typical paragraph indentation of the time, because as a power of two it was easier to calculate in binary for the limited digital electronics available.
Why someone decided to round up to 8 instead of down to a much more sensible 4 spaces is beyond me.
We finally compromised and we're using 3 tabs.
* Large organisation -> pays more.
* Organisation that has power to enforce coding style rules -> pays more.
* Morons -> they are paid more.
Only, in Go, you don't have a choice -- gofmt enforces tabs only (with spaces for alignment). So something seems odd there.
Are there any highly-paid Go programmers who refuse to use gofmt? That's a serious amount of effort to go to in order to make your code non-standard. Your projects will be criticised and you'll get PR's to correct them for just that reason alone.
If there are no highly-paid Go programmers who use spaces, and it seems utterly reasonable to assume that there are not since the language itself enforces tabs, then who exactly are they talking about in the data?
The answer, as always, is: lisp with parinfer - makes the whole debate irrelevant.
Unlike "traditional" formatters, it parses your code into a syntax tree completely disregarding any original formatting, meaning the output is entirely consistent. It's pretty liberating to devote zero time to manually formatting and can make code reviews more constructive and less superficial. It is what is is, and it's pretty opinionated based on Facebook's code style. Works great for us, enforced with a git hook.
My personal guess would be that using spaces is a practical decision and might be more popular towards older, more experienced devs (who are therefore better paid).
On paper tabs sounds better, they're "configurable", you should indent with tabs and align with spaces, yada yada and everything is good in the world.
In practice however it becomes a big mess real quick unless you only work on projects with very good and perfectionist developers who understand when they should indent and when they should align and how they should configure their editors to do the right thing. See for instance the linux kernel codebase, it looks like arse if you don't use 8-space tabs and the coding style even tells you to use that value (it shouldn't really matter if tabs were used "right", except maybe for 80-column limits). So why even bother with tabs in this situation? Do we really care that much about wasting a few bytes?
Therefore I gave up on tabs a long time ago and tell everybody to just use spaces in all the projects I maintain.
Also some languages are "tab friendly" and there are correlations between language and salary; see previous HN posts on the topic.
They explicitly rejected this explanation after controlling for years of experience.
That being said I'd be curious to see "years of experience working in a team", because that's really when using tabs starts becoming tricky. If you're well disciplined and are the only person messing with your codebase the issues I mentioned in my previous post don't really apply.
If you know another variable that explains the difference please let us know.
Just oldsters cargo culting old kludges into the 21st century.
If a tree falls in the forest, etc
Case closed! :)
Because bigger corps generally set company wide standards on the code indentation and that more often that not prescribes spaces.
People who use spaces are just better than those who use tabs.
The Go community was on to something with gofmt (even if they did decide on tabs).
I suppose that maybe none of the really popular languages follow this though...my bad.
I know for a fact that an auto-formatter like `gofmt` or something would have avoided at least one argument, so it would probably would make the code better in some respects.
That said, I like the whitespace. I like that it forces you to think about how the code is formatted and it tends to make the code a lot less verbose.
That said, in the imperfect world we live in, I always use spaces. "Indent with tabs, align with spaces" is obviously not rocket science, but its just too opaque unless you have a strong code review process.
[1]: https://dmitryfrank.com/articles/indent_with_tabs_align_with...
When I was working on my own small projects I was using tabs, or tabs combined with spaces, which yielded me not a lot of money.
Once I started working for a big corporation, the coding standards mandated by the company meant I could only use spaces, because people couldn't be trusted to use a nice space/tab combination.
These people have a particular gusto in constantly one-upping each other with the latest good practice; the one that adopts the highest number of good practices wins. Their constant talk of the latest fad and push for the "right ways" of doing things usually puts them in positions where they end up evaluating and hiring new developers (I got interviewed just the other day by somebody that didn't ask me to design or structure any code, but rather if I use == or ===).
Some of these are actually excellent developers nonetheless; others will drive entire teams into rewriting a perfectly working application into a completely useless mess of a thousand microservices. Endeavour that will end up in their CV anyway, helping them to find another excellently paid job once it's time to migrate.
In a perfect world you'd use tabs for semantic indentation and spaces for stylistic indentation but this is too hard to implement in 100+ person teams and also can't be automated via an IDE style sheet.
I'm not a PHP guy (so I'm not sure about this) but it looks like PHP-FIG suggests it too... http://www.php-fig.org/psr/psr-2/
So are we really saying software developers who follow style guides earn more? That doesn't surprise me. Adhering to guidelines is a good way to work well on teams and thus become a more valuable team member.
Set the tab stop to what ever your project/team style guides requires. Tabs to spaces is just plain stupid. Why on earth would you ignore the x09 character, a single character that exists for this exact reason, and replace it with multiple x20 in the file. Just set your tab stop to what you like to look at, be it 2, 4, or 42 characters. By the way the default is 4 characters for most editors/IDE's.
vim - :set tabstop=4 vscode - to your settings add the following. "editor.tabSize": 4
Everyone else's comments are moot!
Debate over.
If the 95% confidence intervals for tabs and the 95% confidence intervals for spaces intersect at a point, there is a possibility for failing to reject the hypothesis that the difference between the two is nonzero at the alpha = 0.05 level. Since there is little overlap in most cases, the original hypothesis holds.
Who do I contact for my check?
Hard G. for graphics. Not "jif."
The matter is settled.
Anyone who dissents gets sent to the camps.
The point is that, unlike the English "dzj" (jif) or "gh" sounds, you can pronounce a Dutch hard "g" for as long as you want to. And therefore make it louder. And therefore we will win this argument:
ggggggggggggggggggggggggggggggif!
:-p
With this, I instantly conform to how the file is formatted. Is it 3 space indentation, made with a mixture of 8-tabs and spaces? Autotab will figure it out, spit out the Vim params, and you're modifying away without causing spurious diffs in version control.
You have to learn to use Ctrl-T for indent and Ctrl-D for deindent in Vim; those obey the shiftwidth and generate indentation according to the shiftwidth, tabsize and expandtab setting.
Or do some people actually use the space bar to indent code? (which is obviously insane)
I don't really care that much, Go says tabs so whatever. But spaces have the benefit (or drawback to some) of rendering exactly the same way for everyone (assuming fixed width fonts, does anyone code with proportional fonts?). Also I've always got two thumbs on the space bar. And it's much bigger than the tab key.
So settled then?
I never thought that such styling would really matter much ... I wonder how much a developer using a beautifier earns in average..
Anyhow, statistics sometimes brings up some weird conclusions.
Am i missing something here? this sounds really dumb, as tabs make the most sense, and it appears use less memory as well.
Then somebody asked me why. The answer was that Sun Solaris was a crappy operating system which would fail to boot if you used tabs in files like /etc/vfstab.
For some odd reason, I carried around a weird bias about tabs rather than regarding Sun as being shitty.
I worked somewhere where a bunch of folks preferred four spaces (because they came from Python), others two (because they came from JS). Use tabs, set your preferred tab size, boom, everyone gets along.
I use vim with vim-sleuth now. If anybody knows how I can achieve what I described above in vim, please tell me how.
That someone with this many different types of experience can have accidentally avoided encountering whole class of people and their code, really puts into perspective how small the experience of any 1 person is.
Do Visual Studio and SSMS support the space equivalent of "Select X rows and tab them all at once"? I just tried now and all the code is wiped out, replaced by a single space.
But that's still not a good reason to use spaces (especially 2 spaces) and say "FU" to programmers suffering from diplopia.
I do this on a daily basis to adjust my indentation in json/yaml files.
It lets you check in an .editorconfig file that specifies whether your project uses spaces or tabs. And a bunch of editors and IDEs already have built-in support for it!
Doesn't solve the holy wars, but it can sure help reduce the friction.
"There were 28,657 survey respondents who provided an answer to tabs versus spaces and who considered themselves a professional developer (as opposed to a student or former programmer). Within this group, 40.7% use tabs and 41.8% use spaces"
Without filtering to the 'professional developers', meaning overall, there are more tab users (32% vs. 28%).
...
"format": "prettier-eslint --write --trailing-comma es5 --single-quote true \"_src/**/*.js\"",
"lint": "eslint \"_src/**/*.js\"",
"precommit": "npm run format && npm run lint"
...
(Am I wrong? I would hope a Data Scientist would know a basic thing like this, but I don't know R so I can't tell for sure from their code.)
...but at least with tabs everyone can adjust the gap size to their liking. :>
Is it possible that tab-aversive people making hiring decisions act on their aversions (consciously or unconsciously), while tab-friendly hiring managers do not?
I think it's the best of both worlds, really.
Use whatever's right for you! And, if you come to a workplace where there are "rules" about that, try to obey them.
Never take part in any of those wars of Tabs vs Spaces, VIM vs Emacs vs Sublime vs whatever.
Spend time on writing more tests instead!
Now that's a fact for your next job interview!
I mean how are we to achieve world peace when we still have people using and being awarded for wasting precious bytes.
It's because they get more keystrokes in!
Depending on your tab/indent settings you might get as much as 4x or even 8x the XP by using spaces.
Tabs are more often used in languages like C and C++ which are more traditional and pay less despite being more technical.
Indeed, it does means that.
The internets giveth, and the internets taketh away.
;; if indent-tabs-mode is off, untabify before saving
(add-hook 'write-file-hooks
(lambda () (if (not indent-tabs-mode)
(untabify (point-min) (point-max)))
nil))
Many of those who answered tabs are actually using an IDE which inserts spaces when they push tab. They believe they are using tabs, because they've never realized that this is going on. People under that misapprehrension are likely to be less skilled.
Additionally, if a coder, is in fact, deliberately choosing the use tabs, they are going against the majority opion of coders and almost all style guides. That attitude might be correlated with lesser income.
Spaces are for people still using 80 column monitors.
You tabbers are costing me money!
Use and respect .editorconfig files in your projects.
Let's move on to ASCII vs Unicode ....
Are you guys all programming in vi or notepad or something?
I suspect this has more to do with the sorts of programmers who work with Clojure, though.
It's also not very mainstream. Stuff like Java or C# has millions of developers in lower-paying countries that bring their averages down (I'm one of them :) ).
I'd like to see the split of age vs tabs and spaces. I'm with a few other people that may say experienced programmers prefer spaces as it causes them less formatting issues over time when working in larger teams or on differing IDEs - and experience pays more.
(J.k.: spaces FTW)
Maybe I'm not up on my statistics lingo, but saying "using spaces instead of tabs leads to a higher salary" sounds much more causal than "using spaces instead of tabs is correlated with a higher salary."
If they're going to say something leads to something else, I don't see how that one's justified over the reverse: "having a higher salary leads to using spaces." Isn't that's just as valid a conclusion from the data?
Correlation still:
(a) implies causation (it's a necessary attribute of causation, just not a sufficient one).
(b) makes it statistically more probable for someone to be making more money than another, if they use spaces and the other doesn't
Eventually leadership got annoyed at the amount of time developers were wasting punting code reviews back and forth over this silly nonsense, let alone the loud altercations around the office. Who ever could have guessed that developers would be such an opinionated bunch?
So they mandated spaces, and all was peaceful in the office.
For about a day.
Naively they put something along the lines of "spaces are to be used for indentation" in the code style document, but failed to specify how many spaces.
So the new arguments started up amongst the office. 3 spaces or 4? Whoever could have guessed that a number of developers were actually belligerent types who would go out of their way to find something to argue about, and also stubborn? Such a rare trait in developers.
So the arguments raged again, and eventually management decided they'd had enough. After all the fuss and grumbling over making an arbitrary decision on the tabs vs spaces debate, they decided this time to be democratic.
They scheduled a big all-hands meeting for the developers, and tolerating no interruptions, outlined that a binding vote was going to be taken. The code style document would be updated to reflect the democratic consensus, and also warning that future arguments on any other points would result in verbal warnings, and potentially dismissal.
With the software development managers standing at the front each to independently do the count, they asked all developers in favour of 3 spaces to raise their right hand, and all developers in favour of 4 spaces to raise their left.
The count started, but soon the managers realised that with all the raised hands, they couldn't see the fours for the threes.
BTW, I wonder how many raised both hands...
If you care about clean code, being orderly and organized probably extends to other areas, too, and that helps you make more money.
In my experience, developers who mostly use default settings are often unorganized and easily confused. They also know very little about the systems they are working with, because everything outside their IDE doesn't interest them.
I'd also bet that many tab users had to check what they use, because they didn't know or care.
tl;dr: Developers who change the settings are more dedicated to their job.
I.e. you fix the whitespace in your files, then rewrite history as if it was always that way. Then you don't get git blame showing you whitespace-only commits.
(Yes I know there is an option to ignore whitespace in git blame, but it isn't on by default so it is useless everywhere except the command line.)
So the model actually predicts causality, instead of correlation? That's amazing. I'll start using spaces instead of tabs today and I will ask for a 8.6% raise.
According to this model, I should get it!
Boring corporations like boring spaces, and have to pay big, boring salaries to get any talent at all.
On the other hand, cool code slingers may or may not prefer tabs out of personal idiosyncracies, but as long as all of them get shortchanged by the VCs and/or startup founders...
I don't think the fact that you use spaces automatically makes you a richer programmer.
Correlation does not imply causation
Correlation does not imply causation
Correlation does not imply causation
Just a guess.