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.
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.
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.
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.
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.
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.
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.
(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.
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 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.
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.
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.
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.
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).
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.
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.
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 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.
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.
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?
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.
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.
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).
> 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.
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.
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.
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.
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.
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 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...)
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.
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.
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).
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.
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?
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.
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.
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.
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 ).
> 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.
> 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.
> 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.
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.
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.
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.
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 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).
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.
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.
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.
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
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.
228 comments
[ 3.0 ms ] story [ 255 ms ] thread> 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.
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.
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.
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.
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.
I'd hate to be loaning the company money that long every month.
An if you get paid per hour, your payment is usually for the previous month, so 56 days late.
Yes, it's pretty typical.
> I'd hate to be loaning the company money that long every month
That doesn't make any sense.
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.
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)
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.
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?
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.
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.
* 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:
(What you should do--if you're going to visually align at all--of course, is ... but humans are humans and IDEs aren't created equal, so this doesn't happen consistently.)* 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).
Problem solved and it works for them
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.
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
(╯°□°）╯︵ ┻━┻
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:
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.
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.
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 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!
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...)
“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.
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.
I.e., you can also use a single `tab` on an over-indented line to correct indentation.
Your point stands, of course.
Emacs still has a quirk that stands out :)
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.
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.
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.
Not that it's hard, it's just that other editors haven't done it (that I've seen).
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.
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.
[0]: https://clang.llvm.org/docs/ClangFormat.html
[1]: https://github.com/google/google-java-format
[2]: https://github.com/google/yapf
[3]: https://github.com/rust-lang-nursery/rustfmt
The go language has /a/ (single) correct formatting syntax.
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 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.
http://editorconfig.org/
[0] https://stackoverflow.com/a/2318063
It's already a must-have editor plugin for myself and any underlings. It's real nice.
[1]: https://github.com/prettier/prettier
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.
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 did never notice it.
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've yet too see a modern IDE or code editor that wouldn't allow to chose what you want to used for indentation.
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.
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
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)
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.