Whenever this old debate comes up, I am reminded of this quote
“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.
> 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.
You don't even have to do that. Just use whatever format is in the main repository. Then use git smudge and clean filters[0] to convert to your preferred format whenever git checks out the files. This way your editor does not need to care about the format everybody else uses.
Interesting idea and it would certainly help to alleviate the "how many editors do we need to provide code style config for" problem, but it looks rather limited in scope at the moment (for instance it doesn't even try to address "brace on current line or line of its own", let alone more odd things like GNU coding style brace indent).
It's only really targeting text-editor-level settings, things like encoding, EOLs, and "what characters does the tab key emit". It doesn't attempt to solve every formatting/linting/style issue, that would make the editor plugins really hard to keep compatible.
That quote reminds me of one of Joseph Campbell's - "computers are like Old Testament gods; lots of rules and no mercy."
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.
> which is definitely annoying when you have your editor set to autoconvert
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.
The parent post's point wasn't about add-on formats. The point was that the language spec it's /self/ has an included lint tool to eliminate controversy.
The go language has /a/ (single) correct formatting syntax.
Tab as the prefix for command lines is a property of all Makefile formats I'm aware of (though not of many other build script formats). Make itself (including GNU Make) does not generally use M4, though both Autoconf and Automake use it, often in conjunction with Make, as part of the Autotools suite which is also published by GNU.
So, none of the above, in itself. It is a historical anomaly which has been preserved.
emacs' makefile-gmake-mode, loaded automatically for makefiles, also hides this. I've set indent-tabs-mode to nil in my .emacs for years, but the mode knows it's needed, and will indent the line with a highlighted tab ( until you begin writing in the command to follow it, when it unhighlights it ).
This tabs vs spaces thing is a recurring joke and source of conflict on HBO's Silicon Valley, and I always thought having a raging debate over tabs and spaces was one of the less realistic things about the show. But what I'm hearing now is that my use of emacs has just left me out of touch with the really tedious stuff other people sometimes have to deal with.
Any proper IDE/editor has auto-indentation nowadays, so there's really nothing special about Emacs anymore. Obviously even with auto-indentation you still have to agree on the right convention for a given project. As with most code style debates, it usually doesn't matter that much one way or another as long as you make a call and keep it consistent across the project.
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.
> I don't think I've ever seen someone describe a feature that vi/vim/emacs has that an IDE doesn't
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.
I find vims block highlighting (ctrl+v) very useful, never noticed it being part of an IDE.
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
> I find vims block highlighting (ctrl+v) very useful, never noticed it being part of an IDE.
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.
"Exaggerated" as he actually voices his extreme views. Many people look down on the people from the other camp but never actually say anything to not sound ridiculous.
Well, I'm Team Space for sure, but I just think the environment should take care of that. I mean, who sets up their IDE so it inserts tab characters. Alternatively who goes about indenting their code by hitting spacebar multiple times?
Seriously, this is the heart of it. The one thing about Emacs that I just can't forgive is its insistence over the decades on mixing tabs and spaces in its auto-indentation.
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.
this is my opinion, too. In an ideal world we would all use tabs so that we could all see the indentation level that suits us best. But it's not an ideal world. So we're forced to use spaces and agree on how many spaces to indent with.
Tabs for indentation, spaces for alignment. That's the only acceptable mixing.
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.
Like programming itself aligning code is not an art form, at least not in where productivity and consistency is required, it's just a means to an end.
In my opinion the art is in documenting your code and explaining what your code does (what you intend it to do not how it does it).
Art or whatever it is subjective to decide which code formatting is better. As long as a single "code format actor" can transform different styles automatically then why one should care. I think most communities are having an agreement on which one they would like to choose and most of the times they chose the best style but doesn't mean one has to limit themselves into those formats anyway. Something like git push --code-style somestyle would be a relaxing.
> I don't worry about indentation because emacs does it for me.
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.
Well...the team tends to learn pretty quickly which editors don't follow the project's coding standards by default, and comes up with configuration files for those editors. If that doesn't happen, then inconsistent indentation probably isn't the first thing that needs to be addressed.
To make long story short, somebody discovered that developers who take care of their code -- how it looks and how it is being processed in a code repository -- get higher salaries.
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.
Code with spaces looks always good. Code with tabs looks good if the other developer has the same tab length, but will not look correctly if it is wildly different, because of the right margin not lining up correctly.
As long as I can tell at a glance which lines are more or less indented than other lines, I don't care how big indentations are. Making the right margin line up is a waste of time; I'm not going to spend my entire life staring at a fixed-pitch font to indulge someone else's retro ASCII art hobby.
You only say that because you're MIXING indent styles.
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.
Not right-aligned, rather that using tabs means that 80 characters in one editor may not be at the same position in another editor with a different tab width.
> 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 would appreciate it if you would describe the stereotype that you think that the text of my comment somehow cast upon Perl programmers, other than the intended tautology.
I still couldn't like any .Net code... But yeah, I use the standard on it too (I don't even know what it is).
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.
I keep thinking that "employer" is the biggest confounding variable here. A quick survey of some of the big players, whom I would presume pay premium salaries, seem to favor spaces over tabs.
That was an early hypothesis I considered, but it doesn't fit the data. That would show up as a larger tabs/spaces salary gap for big companies, when in fact the gap is similar across all company sizes:
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.
I think that the original article made it clear that it was a correlation, not a causation.
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 work on collaborative projects, some use spaces or tabs and it makes no difference to the ease of collaboration. It's just a setting in the .editorconfig.
In all collaborative projects I've been that allowed tabs, all files that had been edited by tab users were a mishmash of spaces and tabs that made no single tab width configuration workable. If you chose tab width as 4, some parts of functions would look right, others would have messed up indentation. Ditto for any other tab size.
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.
That's not a fair comparison. You either disallow tabs, or you disallow spaces. A mismatch isn't either, so it doesn't evidence either being better than the other.
Disallowing spaces isn't an option, you can't align code using tabs. You have to both disallow spaces and enforce a no-alignment (leading-indent-only) formatting style.
Meticulously lining code up like ASCII art seems like an antipattern to me nowadays. It might make some regions of the code look a little bit nicer, but it's never really strictly necessary and it comes at the cost of higher maintenance - for example, add to that list of assignments with lined up equals signs and you have to make your addition line up too, and if your variable name is longer than the longest one in the list so far you have to move all the previous ones over.
The kernel has an official & mandatory rule to enforce tabs, at a length of exactly 8 spaces per tab. Anything that doesn't respect that will be rejected without mercy.
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.
This is how I feel about it too. Tab users seem to be saying that, with their configuration of vs-code, tabs work fine. I like a format that works fine with cat, sed, grep, and all of the other unix utilities in my githooks.
plus, I can run vim on a terminal on my phone. vs-code isn't there yet.
The default display for every tool is 8 spaces for a tabstop. If you don't want that, then each tool has to be configured separately, with a different method for each. Many require a command line option (which one differs by tool) that has to be typed in each time.
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.
I don't see the difference between that and having to preprocess every command you run to change the number of spaces used per indentation level (a much harder task).
Why would you need to change the number of spaces to read it? You probably have a different preference and what you get, but your preference is unlikely to be material to legibility.
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.
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.
Especially diff. The single thing that annoys me with tabs is the fill behavior. The tab stop is not affected by the leading ‘+’ or ‘-’ in the start of the line which can lead to some weird looking code like :
function foo() {
- if (baz) {
+ if (bar) {
baz();
}
}
If a tool is not set up to deal with this problem (for example `git config core.pager less -S -x1,5` for a 4 space tab stop, `less -S -x4` makes the first second line above indent with 3 not 4 spaces).
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.
The indentation style was like that before I got there in each case. One just uses the Visual Studio default settings, the other is default Visual Studio settings but with tabs. I've never run into an issue with diffs or anything like that.
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.
>don't always notice they are "wrong" when doing a quick change.
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.
Is this[1] what you're referring to? That sounds like grounds for summary execution to me.
My group had me write a git commit hook that demands all source files pass a dry-run of astyle before you can commit. It'll let you view the difference and either cancel the commit and fix it yourself or just take the auto-formatted by astyle version and commit that.
I'm glad you have a system that works for you and your collaborators. :)
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.
It's a single file placed at the root of the repository. The text editor/IDE will automatically see it and silently apply it as you edit the file (eg press tab and it inserts x spaces or a tab, uses whatever newline specified). There is no extra burden unless you need to download a plugin for it manually.
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.
There should be a third option "do not know". This was important maybe 10 years ago. Today IDE is handling formatting for me, and I no longer remember what the default settings are. The same about encoding or EOL chars.
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...)
In Germany as well. That's why I believe that the ~20 German users who answered with an annual salary < 3000 USD did answer the questionnaire wrongfully. The minimum wage in Germany is 8.50€/h. Assuming you work for the minimum wage, that would be 3000USD/8.5(€/h)/52 weeks = 6.41 h/week which does not seem plausible.
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.
Interesting. Months aren't all the same, especially if you get paid weekly/biweekly, which seems universal here in the US. I assume it's a weekly52/12 or biweekly26/12? That's what I use for my own personal budgeting, but I've never seen others refer to monthly pay before. I do find it convenient to think about pay this way, since so many expenses are on a monthly schedule (rent, utilities, credit cards, car loans, insurance).
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.")
They're saying that being paid either weekly or biweekly (i.e. roughly 2 or 4 times a month) is nearly universal in the U.S, and that being paid monthly sounds less sensible, since months are of different lengths.
...Unless you're talking about the difference between biweekly and semimonthly?
Considering the explicit distinction drawn between getting paid on a week basis, where "months aren't all the same", and getting paid on a month basis, where they are, of course that's what I'm talking about. If you get paid twice a month, your income is the same every month.
While they're technically different, they're "close enough for government work", and I don't know anyone who would make the distinction in casual conversation. IMO, there's no "of course" about it; a comparable situation would be interpreting "literally", "begs the question", "ironic", and such using their dictionary definitions, when it seems clear that the writing has a more colloquial tone.
In response to the comment "when you're paid biweekly, not all months are the same", then yes, it is blindingly obvious that the current context draws a distinction between being paid biweekly, such that not all months are the same, and being paid semimonthly, such that all months are in fact the same.
Ah, thanks! I should have specified that I was speaking anecdotally. I've just never been paid semi-monthly or monthly in the US or heard of it from others. I suppose I shouldn't be surprised if it is more common that I would have thought. Perhaps it's more common in other regions or fields.
Same in Sweden, regardless of how your wages are structured (monthly salary, hourly wages, performance based) everybody responds with what they make per month when asked how much they make.
(In the US) I actually found it weird when I was talking to a loan officer and he asked how much I made. I told him, and he about jumped out of his seat. "PER MONTH?! WHAT DO YOU NEED A LOAN FOR?!"
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.
In the parts of Europe that I know of, if you have a median job, your paycheck is per month. That is why everyone knows that number the best: it's the one you see most often, appearing every month on your bank account.
For me, and I suspect this is pretty status quo in the US, the number that shows up in my checking account biweekly is my annual salary divided by 24, minus taxes and automatic deductions for mortgage, 401k, stock purchase, health plan, etc., with the occasional bonus thrown in to mix things up. It's a very arbitrary number and it would be impossible to back-calculate my overall compensation from it.
> the number that shows up in my checking account biweekly is my annual salary divided by 24
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.
A lot of jobs in the US pay biweekly, which comes out to a nice, round 2.166 paychecks per average calendar month. Paperwork here generally either asks for annual income or asks both paycheck and length of pay period.
So its possible to have to wait more than a month for your first paycheck? i.e. start on the 1st and they pay on the 1st weekday of a new month for the past month?
I'd hate to be loaning the company money that long every month.
In Western Europe there doesn't seem to be a clear 'standard' of when ppl get paid. I know several people who are paid on the 10th each month, for example. (I happen to know this because they negotioted their rent payments to be on the 11th for properties they rent from me). Others are around 22-24; I used to get paid 28-30 in various jobs. There is probably a reason for this clustering, or maybe my sample size is too small and there is no clustering.
How often you're paid depends, often it's twice per month, but the agreed amount in the agreement (and everywhere else where you'd discuss it) would be listed as x eur/month.
In the Netherlands also the 25th. However, if you get paid per hour, it may also be that you are paid weekly or biweekly, but indeed usually a cycle later.
Yeah, my paystub is per paycheck. That's why I can say how much I make per paycheck off hand, but I'm going to need to do a little math to figure out how much that is per month.
Most billing cycles are by month (rent, water, internet, spotify, ect) so budgets tend to be by month. Obviously I don't know /exactly/ what I make per month, but I have a general idea. I expect this would be fairly similar throughout the US (though I have no evidence backing up that assertion).
UK, Ireland, Australia, New Zealand all think of yearly income. Continental Europe all speak exclusively of monthly salary.
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.
Depends on the employer and, obviously, country. In the Netherlands, everyone gets "vacation money" somewhere in May/June. For me, it usually works out to a bit less than a month's salary. In December, many people get a "13th month", but many others like me don't.
Wait, did people take Stackoverflow's post serious enough to merit a response?
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.
It patently obvious that liking spaces or tabs better won't change your salary.
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.
Spurious correlations normally aren't present on sub-populations (unless you try to segment your population on many different ways, what they did, but it was present on nearly all of the ways).
Given whitespace is immaterial to the end code (while it is used to indicate blocks in Python, you could theoretically use something else to indicate blocks) I have this idea of making each editor indent the code their preferred way and have the canonical source code in an specific fixed way with no alignments or needless spaces
Kudos to the author for doing a bunch of good data analysis and investigation. Pro or con against the result it gives a better context in which to read it rather than a simple headline that you can use in the next argument you have.
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.
When you have large amounts of data, even if it's for a large number of people eventually youre going to find odd 'correlations' between unconnected variables. People who play edition X of Dungeons and Dragons are 30% less likely to eat chicken sandwitches than people who play edition Y. If you know a thousand things about everybody, the data is going to be riddled with bogus 'connections' like this.
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 is not the reason for the correlation. The p-value of the tabs/spaces connection is about 10^-13 (one in 10 trillion), and it can be found separately within each (large) country.
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.
There are some good reason for using spaces instead of tabs and good reasons but I'm sure it's mostly just a uniform. It's now a cultural meme that spaces is better, and people who are exposed to this meme tend to be more connected to the higher end of the community than people who aren't. It's like the correlation of people who curse making lower salary and people who wear suits making higher salary.
Silicon Valley on HBO actually made the opposite conclusion, that tabs are better (Richard did not hire someone because they used spaces). The main point being pressing space bar 4, 8, 12 times etc is a waste of time
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
I think his argument was also that spaces would take up 4 characters, whereas a tab would take up 1. As a compression company, it "only made sense for him to choose the lower character count".
You still press tab on the keyboard and your IDE would render it as spaces. Whichever writer made such a strange statement is decidedly in the lower end of the community.
I personally prefer tabs, but as suggested in this article, I do a lot of open source work, and use git for that and my job and spaces seem to win for both. So I use spaces.
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.
I've never understood the tabs versus spaces argument. It's not really a question of a coder's individual taste, is it? Arent these things usually decided by the choice of IDE?
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.
I use vim (or vi on some antiquated machines). Others in the company use Emacs, Visual Studio, Qt Creator, Sublime, and so on. When the company was more startup-ish, it was a matter of individual taste, influenced by their IDE/editor. Giant checkins of mostly whitespace changes eventually became an issue, and were banned. Years later, and the code it mostly spaces, but I see places in the code with random tabs in between, every now and then.
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).
But does everyone you work with use the same editor/IDE? I think that's where problems begin (and are subsequently solved by the introduction of something like editorconfig).
I'm from Poland and I can confirm - literally no one even thinks about their salary in terms of a what it is annually - I suspect the author is correct in thinking that a lot of Polish respondents wrote in their monthly, not annual salary.
No sensible reader of the original SO article thought that correlation implied causation in this case. Using spaces for indentation is obviously a symptom of a better developer. That's all.
Exactly. I never understood the benefit of alignment. I actually find it harder to read - by making the starting point of the line less predictable it's harder to skim through and if, say, you rename the function you've now got a much longer diff than necessary.
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.
> Exactly. I never understood the benefit of 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).
I know some of my coworkers still use mono-spaced fonts and I just don't understand it. Proportional fonts are so much more legible and nicer to look at.
I can't stand code in a proportional font. I like aligning code and having the alignment be maintained, regardless of the specific font in use. Things tend to also be more smooshed-together and hard to read individual characters when using proportional fonts, since every character's width varies, instead of matching the widest character.
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.
Of course there are; I wasn't suggesting those as appropriate fonts. I was using them as extreme examples of stylistic mismatch.
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.
Character spacing, kerning, ligatures, and many other aspects of modern typography are all that you give up with type writer fonts. Yes, if you use a shit font like Times New Roman, it will look bad, but if you use a nice San Serif font, it doesn't look as you described (like cursive, comic sans, or another pseudo hand writing font).
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.
It's not so bad if you use a formatter (still prefer indenting though), but if you align everything by hand it's just more annoying than it is useful (in my opinion).
I also follow this approach. I also use these other rules:
var something =
[tab]someReallyLongCallThatWouldExceedMargin()
someObject
[tab].call()
[tab].otherCall(param)
[tab].yetAnother(
[tab][tab]withLong,
[tab][tab]parameters);
I use four literal spaces, but I think this approach would work well with literal tabs. The only problem is most IDEs do not have an expressive enough configuration to do this, nor do I think I could make it easily happen out of the box with tools like indent or gofmt.
I could be equally condescending and say "Why Grown-Ups Don't Use Column Alignment."
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()))
There's no good reason for these lines to be so long. If they were formatted with indentation as shown in hawski's example, they would be much shorter.
Another example from an earlier version of the code:
Wait, is this aligned or not? What happened? Most likely it was aligned at one time, and then some names were changed and it became misaligned.
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.
I'd argue that the real issue here is slavish adherence to the style guide without stopping to consider what's readable. Alignment, in my opinion, is a readability win in general. (We may have to agree to disagree here.) But when column alignment results in unreadable code like the examples you gave, you shouldn't use it. It's that simple. That doesn't mean that column alignment as a general principle is bad; you should optimize for the common case, and be willing to handle exceptional cases differently.
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.
ConstructionItem::TableColumnFragment is 37 characters[1]. A style that permits huge identifiers like that should allow more than 2.2 identifiers per line and should not allow alignment that requires the eye to jump over that much whitespace and land on the correct line.
[1] not columns. Bitmapped displays don't have columns, and it's objectively measurable that humans read fixed-pitch fonts more slowly.
At that point they're getting negative value out of tabs - people can't set different tab widths and also can't use editors that don't use a width of 8 (or need to reconfigure editors that have a different default). They'd be better off just using spaces.
I was going to say you're obviously incorrect because in what editor can't you change your tab width? But I realized you are probably talking about the kernel.org project. Is that what you mean? There is an agreement within the Linux kernel project?
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.
The "show whitespace" features of most IDEs will make the space vs. tab issue apparent. The only down side is then you start secretly hating every other dev who doesn't use this feature.
Ever since I started using spaces, my salary has increased dramatically!
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!
“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.