Tabs, spaces and your salary – how is it really?
evelinag.com
evelinag.com
“There's a good part of Computer Science that's like magic. Unfortunately there's a bad part of Computer Science that's like religion.” - Hal Abelson
I don't worry about indentation because emacs does it for me. However, if this is your personal pet peeve then you should provide all of your developers / contributors with a plugin, script or other utility that formats their code to your standards. This issue has long been solved programmatically and it is a waste of mindspace to deal with it any other way.
And to go along with that, some things like GNU Make still requires tabs, which is definitely annoying when you have your editor set to autoconvert. And some sects like Go or Python don't technically REQUIRE one or the other, but still try to aggressively purge the heretics.
Is this actually a problem? Every editor I've ever used has detected that I'm writing a makefile and has changed the indentation to tabs automatically.
go fmt
[0]: https://clang.llvm.org/docs/ClangFormat.html
[1]: https://github.com/google/google-java-format
The go language has /a/ (single) correct formatting syntax.
In my experience, m4 is an arcane bit of software that surprisingly few people know about and one that frankly should have been replaced years ago.
Personally, I try to never use autoconf because of this.
So, none of the above, in itself. It is a historical anomaly which has been preserved.
I.e., you can also use a single `tab` on an over-indented line to correct indentation.
Your point stands, of course.
I've had this in basic code editors for... 10 years or so? It's hardly an emacs thing.
I hear it all the time. People saying things like "I use vi/vim instead of an IDE because I can do X" where X is a feature that every IDE worth using has had for 10 years.
I've literally had someone say that they use vi/vim because it does syntax highlighting. What were they using before? Notepad? gedit? Even gedit has syntax highlighting.
"Oh, I use this magical vim plugin that lets me hit this magical key combination and all my code gets automatically formatted." Yeah, but Visual Studio, PyCharm, Eclipse, and basically any other IDE do that out of the box. No plugins necessary.
I don't think I've ever seen someone describe a feature that vi/vim/emacs has that an IDE doesn't (EDIT: Other than the fact that every *nix system is going to have vi, but that's just an argument for knowing how to use it, not one for preferring it over an IDE if one is available). It's like iPhone versus Android about five years ago, where the iPhone fanboys/girls would praise Apple for their innovation for implementing features Android had over a year prior.
Emacs can seamlessly access files over ssh, ftp and/or sudo.
Emacs lets me add custom hook commands to run before a file is saved (to check a file’s syntax using an external command), and after it’s saved (to signal reloading of the file to the relevant process).
Emacs also includes my mail reader, my diary, my organizer, a spreadsheet, an stack-based algebraic calculator, etc. but those may be unfair comparisons. :)
Note: All of the above are part of the built-in functionality of Emacs. Third-party extensions can of course do anything.
That being said I don't think it's that big a deal but I've seen some fucking vim wizards churn out code faster than what's reasonable for human beings
As far as I'm aware multicursors are a superset of block editing (i.e. multicursors can emulate block editing but the reverse is not true), so many (most?) modern IDEs can at least emulate block editing.
Maybe this has changed in recent years, but in the past whenever I tried IDEs I would be amazed that they didn't have keyboard macros.
Not that it's hard, it's just that other editors haven't done it (that I've seen).
Emacs still has a quirk that stands out :)
It's already a must-have editor plugin for myself and any underlings. It's real nice.
More languages should provide standardized ways of writing and formatting code. It makes everything easier - from diffing to subjectivity.
In what way? It looks like a fairly standard formatter to me.
This issue has long been solved programmatically
and it is a waste of mindspace to deal with it
any other way.
Ultimately, the spaces vs. tabs debate really comes down to which policy is less likely to result in mixed tabs/spaces. If people use tabs, it seems inevitable that some spaces will sneak in there as well. If people use spaces, tabs are unlikely to sneak in. Obviously that's a combination of common default editor configs and human behavior, but that's just how it works out in practice.
Except for Go programmers.
It works because it allows everyone to configure their code editor to have tabs be whatever width they want without messing up how it looks for other people.
But it's futile. Unless there's a git hook setup or you're using Python 3 which throws errors when tabs and spaces are both used for indentation, you're gonna end up with source files with both being used.
The problem is, everyone's editor "does it for" them, but everyone wants to use a different editor. And there are interoperability issues when one person's editor produces tabs and another produces spaces.
It's a relatively minor tower of babel situation.
I earn my living from converting each company I work for to use a proper development process, and that more often than not includes migrating to Git. Why would anyone want to use Subversion in the presence of clearly superior tool, is beyond me.
Why this matters is, contrary to popular belief, not because Git is distributed or is more sound technically. It is because it allows you to create better and more readable commits by not requiring you to immediately commit to a shared pool of code that you then aren't allowed to change.
This means that you can commit locally to your repository as soon as you do any development. You can then work for however long you want to make your changes structured correctly in a readable way which is akin to refactoring code, only for changes. Only then you commit to the big ole repository maintained by your company.
Good developers will recognize that the readability of your code and of your changes is of paramount importance. They will prefer tools that make it easier to create good and good looking code because they take pride in what they do.
I can't see any reason why git would work better with spaces than tabs so that seems like a weak argument too.
Only if you don't care about the indent size, which many people do (otherwise we wouldn't be having this discussion).
I mean you may as well say everyone should use Times New Roman because then it always looks good.
Tabs first, ALWAYS, one tab is one level of indent.
go fmt uses the UNIX lineage of defaulting to 8 spaces converting to a tab (worded in reverse).
Your editor should easily display tab stops at a value that is ideal for you; you could set this to 2, 3, 4, or any other value if it makes things more readable to you.
Unless your team has a very strict "80 chars max" limit on line width I guess.
I used 3 spaces for Pascal and PL/I and PLUS and I liked it.
I used no indentation whatsoever for APL and I liked it.
I used spaces for CDC and Cray-1 assembly, tabs for microprocessors, and had no productivity difference.
I used tabs for C and I liked it.
I aligned everything on the ':-' in Prolog and I liked it.
I use 2 spaces for C++ and that's the only part of C++ that I like.
I use no regular pattern for Haskell and it's perfect.
It doesn't matter. Let your team's format zealot win this argument. Find another hill to die on, like naming conventions or "using namespace std;".
https://perldoc.perl.org/perlstyle.html
> Just because you CAN do something a particular way doesn’t mean that you SHOULD do it that way. Perl is designed to give you several ways to do anything, so consider picking the most readable one.
I don't think I've ever seen a professional programmer defend the usage of "using namespace std;". It's just a trap newbies get into.
Python seems to be a big problem, as it leads to code one would copy and paste, and despite what PEP8 says, there are 'unconverted' tools that will use tabs.
The Haskell situation superficially annoys me, because it leads to constant reflowing. But well, it doesn't annoy me enough to do anything about it.
e.g.
https://google.github.io/styleguide/cppguide.html#Spaces_vs....
https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
I can't find an Apple style guide, but the first file on the most recent commit to Swift uses spaces as well.
https://github.com/apple/swift/blob/e0f75bf841631a50f9ab6502...
https://twitter.com/drob/status/875493967865008129
Perhaps it could play a role as a more indirect effect: people leaving Google/Microsoft/Apple/etc, starting new companies or joining senior positions at others, and spreading this particular practice.
There is probably some underlying cause to both trends, something like "there are people who tend to be really ticked off about 'this operates slightly different in two different environments', such people are more likely to (a) use spaces and (b) have an engineering-type job that pays a little more." Another possible correlation would be "people who are more worried that they will someday have to SSH into a machine where they have not yet configured an editor in order to insert debugging statements into the live production code, tend to come from DevOps backgrounds that earn slightly more, and also tend to favor spaces instead of tabs because that damn default tabstop is 8 and I can handle 2, 4, and maybe even 3, but 8 is too damn high..." or so.
I personally really preferred tabs in my youth as a sort of nod to democracy and "everyone can set their tabstops however they like!" -- and it was Python that finally got me to use spaces instead, with the "hey when you want to do multi-line stuff" arguments[1] and PEP-8 and community agreement and such. But I do miss my little tab characters a lot.
[1] You know, stuff like "If you want to do multi-line stuff, then you need to keep a conceptual split between using tabs for indentation but spaces for alignment; and if you're using spaces for everything then you don't: you can even use your tab key to insert many spaces at once. So it's tab-tab-tab-hit-space-twenty-one-times versus tab-8-times-then-space-once. Worse, if you screw up the mixed tabs-and-spaces format then you won't know about it unless tabs are clearly visible by default, which adds visual noise to your file..." etc. etc.
> I'm not sure I'd agree with the conclusion that version control breaks the indentation pattern found elsewhere
The graph still looks like git-spaces is significantly higher
If you're collaborating, spaces are a much better default. If you're collaborating, your job is harder than coding solo, so you should get paid more.
The theory of tabs for indent and spaces for alignment works. But when collaborating, the practice requires too much support from tooling and too much education for humans -- so it's just not worth the tiny benefit.
Just use spaces! You can't mess it up. ;)
Oh how I envy someone who can say that.
But when I start running diff, less, and so on, I'm left with the conclusion that every tool has to be configured in a separate way for every user, in every environment. And this makes their code a PITA to deal with.
I'm generally not the one to complain. And I'll still use tabs if that is the standard for the code base that I'm working with. But tabs are strictly worse, and your flippant answer won't particularly please people that you need to collaborate with.
plus, I can run vim on a terminal on my phone. vs-code isn't there yet.
Yes, you may not notice or care. But if you're told about why other people don't like it, and dismiss them with flippant answers, you're going to make those other people unhappy.
Remember that the key to successful collaboration is to be strict in what you emit, and generous in what you receive. No matter how unreasonable you think the other is, in this case you're failing as well.
Most people have settled with somewhere between 2-4 spaces, and a max of 80-120 character lines. I have an opinion on what I prefer in that range, but I'll live with a variety of stuff. And most others can as well.
Yes, why? You were the one that said:
> If you don't want that, then each tool has to be configured separately, with a different method for each.
First of all how deeply you go when you align text isn't particularly important. But actually aligning it is super important for it to be readable. It is therefore hard to read a mix of tabs and spaces with the tabstop set wrong.
Secondly while how deep isn't as important, research has found that comprehension drops outside of the range from 2-4 spaces. Therefore the 8 space default that every tool uses for tabs is suboptimal even if you consistently only have tabs everywhere.
The fact that many tools across many environments with many users all have to get it right, and the standard default is bad, makes tabs worse for collaboration.
function foo() {
- if (baz) {
+ if (bar) {
baz();
}
}
This is also a problem if a line is merged to the line above and an unaware developer leaves a tab character—previously used as indentation—thinking it is a space character. To the developer with the tab-stop set to four there is a one in a four chance they look identical.
In theory it would work out ok. In practice, people use different tab widths, and don't always notice they are "wrong" when doing a quick change. Next thing you know, you've got spacing like your tab width should be 2, 4, and 8 spaces and you really have a mess.
I can't understand this! First thing I do when I open up an editor is show whitespace characters. They are part of the source code this should be always be displayed! It would feel wrong to code without showing whitespace.
If you can see your whitespace you can tell right away that it's wrong.
[1] https://kau-boys.com/1128/shortcut/shortcut-of-the-month-ctr...
But you've also pointed out a cost to what you are doing. If everyone adopted one or the other, you wouldn't need an .editorconfig setting. You've increased the burden of collaborating with you by requiring a particular configuration setting.
Models about things like salaries and prices have to be careful to disentangle supply and demand.
The insinuation when you hear that space-users earn more than tab-users is that space-users are somehow more productive, sexier or in with the times. When, as other commenters here have noted, large cool corporations tend to contribute to and use open source code, which is more often space-aligned.
The money question here is -- can I improve my earnings potential by switching to spaces? And this isn't solved by just noting that spaces correlate to Git and open-source; what I need to know if switching to spaces (or using Git) changes my supply of productivity-adjusted labor; or if it's just what they use in higher-paying jobs.
Here's how you disentangle this: you pick a variable that correlates to X (spaces vs tabs) but not to y (salaries). The textbook example is the demand for foodstuffs. Regressing quantity bought versus price tells you very little (supply and demand may be moving simultaneously); instead, you add something like crop productivities as an instrumental variable to filter out the supply effects and see the demand only.
It's important today too, depending on details of the dev process. The IDE or editor handles formatting, sure. Different ones do it differently though, and keeping things consistent between environments often requires some reconfiguration of the software (or automated converters on checkin/checkout, if you want to go that far...)
For reference, the question from the questionnaire:
> BASE: professional developer (Q100 == 1) AND currently employed (Q135 <= 3) Q320. What is your current annual salary, in [currency from Q310]? Please enter a whole number in the box below, without any punctuation. If you prefer not to answer, please leave the box empty / blank.
EDIT: OK, another comment specified that it's common to receive monthly pay in parts of Europe, rather than weekly/biweekly.
As a Swede I find the concept strange. I get a monthly salary, and of course it is paid monthly (almost universally sometime between day 20 and 25 of the month).
No, what my parent comment says is that getting paid twice a month is very rare in the US. ("Months aren't all the same, especially if you get paid weekly/biweekly, which seems universal here in the US.")
My parent comment is mistaken.
...Unless you're talking about the difference between biweekly and semimonthly?
I was flabbergasted. I'd never had someone ask me how much I make an expect me to say per month. I don't know how much I make per month. I know per year or per paycheck. If you want per month you'll have to get out the calculator, buddy.
It's a slight difference, where the end result is a difference of 2 paychecks per year (24 for semi-monthly vs 26 for bi-weekly)
Either you're paid twice a month rather than every other week, or the biweekly number is your annual salary divided by _26_, or, I guess, you're subject to a strict requirement to take two weeks of unpaid vacation every year.
That's really something you should know and understand because you want to make sure you are getting paid correctly and catch any payroll errors. They are not uncommon, I've caught a couple myself, including an $1,800 mistake.
If you're paid biweekly (say, every other Friday) you have 26 pay periods. If you are paid semi monthly (say the first and the fifteenth) then you'll have 24 pay periods.
I'd hate to be loaning the company money that long every month.
Yes, it's pretty typical.
> I'd hate to be loaning the company money that long every month
That doesn't make any sense.
An if you get paid per hour, your payment is usually for the previous month, so 56 days late.
Also there is another flaw, the salary should have been multiplied by 14, because I believe that many European countries pay 2 extra salaries, one in summer and one in December.
Not true at all.
I enjoyed the original article and I especially enjoyed the semi-facetious flamewar that broke out here on HN, but I thought it was pretty well understood that it was a meaningless, albeit interesting, correlation.
But it's also an incredibly clear correlation. It must be caused by something (because it's too clear to appear by chance, and too stable on sub-populations). It may be very interesting to find that cause.
You'd be surprised: http://www.tylervigen.com/spurious-correlations
IMHO while the author touches on Git/OpenSource contributions as part of higher salaries. What it also touches on is people who are working on improving their skills and contributing understanding which is a different individual than somebody who just takes surveys and works at a big company.
Now I can imagine if a company pays you >100k you have to work 40+ hours a week. So annual salary should be corrected for actual working hours
In this case it's too small a sample for this finding to be significant, but increase the sample size and also increase the number of data points per person and you get similar problems. Determining significance is not straightforward.
This does not mean the effect isn't confounded with some other factor, but it does mean it's not a multiple hypothesis testing issue.
You can explore the code and regression yourself! Take a look: https://github.com/dgrtwo/tabs-spaces-post
a common reason for a study to be total junk.
I think it also shows where a lot of people get confused, that being in the "spaces" camp doesn't necessarily mean you are pressing the space bar each time
Also, amusingly, when IBM hired me (in the US), my contract listed my salary as $x per month. I'd seen it before from recruiters for jobs in London and such, but I don't think I'd ever seen it put that way in the states before.
For example, I use Emacs, and when I press the tab key, it is actually inserting several spaces, not a tab character, at least in the language modes that I use.
For my case, vim handles a bunch of auto-format and auto-indent options turned on, and replaces the tab key with 4 spaces, unless I'm editing a Makefile (where commands to execute are preceded by a tab character).
I did never notice it.
I've yet too see a modern IDE or code editor that wouldn't allow to chose what you want to used for indentation.
Spaces are content.
They are both part of the SET.
Everybody, just give it up. They have their users. They have their uses.
(:set shiftwidth=4;noexpandtab)
----> everyone upset about this story
https://insights.stackoverflow.com/survey/2017#work-salary-a...
* 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:
[tab]void someNiceMethod(int myParamA,
[tab][tab][tab][tab][space][space]int myParamB...);
[tab]void someNiceMethod(int myParamA,
[tab] int myParamB...);
* 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 AND IDEs that let you treat spaces like tabs.
[1]: This came up last week (https://news.ycombinator.com/item?id=14560042) and this comment is shamelessly copied from that discussion (https://news.ycombinator.com/item?id=14561223).
[tab]void someNiceMethod(
[tab][tab]int myParamA,
[tab][tab]int myParamB,
[tab][tab]...
[tab]);After talking to several people, I've realised this is very subjective though (what isn't!). I certainly prefer indenting only, without worrying about alignment.
Alignment is what makes ASCII art possible. Without alignment, we might as well be using modern proportional fonts rather than old-fashioned type writer fixed-width fonts (ducks).
Aside from that, in the stylistic sense, it's like reading a newspaper article in cursive or an academic paper in comic sans.
Those are the things that struck me when I've pasted code into an editor with proportional fonts, anyhow.
Proportional fonts have less mismatch when used for code, but they still tend to look "wrong" to me. A font like "Input" is attractive and offers proportional and monospaced versions. You're still left with the larger problem: fighting the font to line up data across multiple lines.
Maybe you don't care about that, but in both my hobby and professional projects, I've found that alignment makes the code easier to read and easier to work with. I would need a very compelling reason to abandon that, and I haven't seen one offered.
Going back to your original comment, you said:
> Proportional fonts are so much more legible and nicer to look at.
You also provided a convenient reply, which I think applies here:
> You should just use better fonts.
Hack, Input Mono, and a zoo of others are very attractive monospaced fonts. You aren't stuck with whichever ugly ones you're thinking of.
Yes, you give up the ability to do ascii art in your code. I find that this doesn't really matter to me or much of the code I use professionally (I can open up some random javascript code off of GitHub and they don't do non indent alignments). I guess if I was programming in C, this might be much more of a problem.
var something =
[tab]someReallyLongCallThatWouldExceedMargin()
someObject
[tab].call()
[tab].otherCall(param)
[tab].yetAnother(
[tab][tab]withLong,
[tab][tab]parameters);
But using alignment doesn't mean you are childish. It's just a bad habit that leads to many problems.
A couple of examples from the Servo source code, whose coding standard at one time required column alignment:
let construction_item = ConstructionItem::TableColumnFragment(Fragment::new(node,
specific));
self.set_flow_construction_result(&kid,
ConstructionResult::Flow(kid_flow,
Descendants::new()))
Another example from an earlier version of the code:
ConstructionResult::ConstructionItem(ConstructionItem::Whitespace(whitespace_node,
whitespace_style,
whitespace_damage)) => {
...
}
If you use indentation instead of alignment, these problems never happen. And in fact, the Servo coding standard finally allows the use of indentation, and this particular call has been changed to use it.
Now back to the question of tabs and spaces. If you use tabs and only use indentation with no alignment, then it doesn't matter what anyone uses for their tab width. The code will always look perfect whether someone likes their tabs rendered as 2, 4, 8, or any number of spaces.
The code will also look fine for someone like me who prefers proportional fonts. In fact, I think every developer should try using a proportional font for a while. It's a good way to get over the bad habit of column alignment.
A similar issue is formatting for 80 columns. In general, this is a good idea, because long lines can be hard to read and hard to edit. That doesn't mean that you should contort the formatting of your code in bizarre ways to avoid an 85 character line.
[1] not columns. Bitmapped displays don't have columns, and it's objectively measurable that humans read fixed-pitch fonts more slowly.
Problem solved and it works for them
Shoot, just myself using a single IDE I always end up with spaces and tabs and missing indents and oddities. When I have something that's nested and I copy/paste it into another file, some of the spaces/tabs get preserved, some don't, and I end up having to either reformat it or ignore it, and then I forget which div closes which and it's just a headache.
~Humanity
(╯°□°）╯︵ ┻━┻
I mean, when I first started, I was only making minimum wage. I had to use tabs, my life was horrible!
Then I switched to spaces. Instantly, my boss noticed my increased productivity, and my character count went up! I started getting free lunches! My dogs became straight-A students! I started winning in League of Legends!
...and my salary increased by $90k! It was amazing!