Developers Who Use Spaces Make More Money Than Those Who Use Tabs (2017)(stackoverflow.blog)
stackoverflow.blog
Developers Who Use Spaces Make More Money Than Those Who Use Tabs (2017)
https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
161 comments
This is one of the strongest cognitive dissonances that I have. And I have no idea why it exists. I know that rationally, tabs are really the better choice. Each user can choose how to display code in their editor.
But I just hate using them.
Maybe it was the 8 space default of vim (nano?) when I was sysadmining. Maybe it was that there was inertia, and tabs are always the thing that's causing problems. But I just can't get over it. I just don't like tabs.
But I just hate using them.
Maybe it was the 8 space default of vim (nano?) when I was sysadmining. Maybe it was that there was inertia, and tabs are always the thing that's causing problems. But I just can't get over it. I just don't like tabs.
I've never understood the dislike of tabs; when I was first presented with the concept of spaces-over-tabs I was new to the industry and went along with it, assuming there was some good reason. But I've never actually found one. Tabs are so much more semantic.
In my experience, tabs generally cause code that looks like:
How does that happen? Because people end up mixing tabs and spaces. Some lines are indented with spaces, some with tabs, too many with tabs intermixed with spaces (I mean things like <space><tab><space>). I'm not even sure how people end up doing the last one, but it's common:
gdb 8.3 include/libiberty.h line 543 has 15 spaces, then a tab, then 10 spaces, then 2 tabs, then 3 spaces.
binutils 2.32 gas/itbl-parse.c line 119 has 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces.
binutils 2.32 zlib/make_vms.com line 831 has 6 spaces, then a tab, then 2 spaces, then 3 tabs, then 5 spaces.
I'm sure they added tabs to give the convenience of being able to adjust the indentation to what I like, but in reality they just force me to change it to what others like to even read a file. Using hard-tabs seems like naive idealism. I haven't yet seen a project that uses hard-tabs consistently. It's either consistent spaces or tabs intermixed with spaces. At least, that's been my experience.
if (c == ESC)
{
*r++ = '\\';
c = 'e';
}
else if (c == '\\' || c == '"')
*r++ = '\\';
*r++ = (unsigned char)c;
}
*r = '\0';
How does that happen? Because people end up mixing tabs and spaces. Some lines are indented with spaces, some with tabs, too many with tabs intermixed with spaces (I mean things like <space><tab><space>). I'm not even sure how people end up doing the last one, but it's common:
gdb 8.3 include/libiberty.h line 543 has 15 spaces, then a tab, then 10 spaces, then 2 tabs, then 3 spaces.
binutils 2.32 gas/itbl-parse.c line 119 has 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces.
binutils 2.32 zlib/make_vms.com line 831 has 6 spaces, then a tab, then 2 spaces, then 3 tabs, then 5 spaces.
I'm sure they added tabs to give the convenience of being able to adjust the indentation to what I like, but in reality they just force me to change it to what others like to even read a file. Using hard-tabs seems like naive idealism. I haven't yet seen a project that uses hard-tabs consistently. It's either consistent spaces or tabs intermixed with spaces. At least, that's been my experience.
Your example demonstrates nothing against tabs.
A tabbist would say the problem was that someone used spaces.
One of Dante's lesser hells is surely reserved for anyone that mixes tabs and spaces.
The issue really is that someone is not following guidelines (C, project, or implicit) and is not using tools that highlight such mistakes.
There is another level of hell reserved for those that use their own personal styles and conventions without paying attention to the existing code (or who just don't care).
A tabbist would say the problem was that someone used spaces.
One of Dante's lesser hells is surely reserved for anyone that mixes tabs and spaces.
The issue really is that someone is not following guidelines (C, project, or implicit) and is not using tools that highlight such mistakes.
There is another level of hell reserved for those that use their own personal styles and conventions without paying attention to the existing code (or who just don't care).
> One of Dante's lesser hells is surely reserved for anyone that mixes tabs and spaces.
Mixing tabs and spaces for indentation is demonic, while mixing tabs for indentation and spaces for alignment is the only good choice without redefining what tabs are.
Mixing tabs and spaces for indentation is demonic, while mixing tabs for indentation and spaces for alignment is the only good choice without redefining what tabs are.
From a quick look, the mentioned projects appear to be using a 2-space indent, but with 8 consecutive spaces being replaced by a tab character (with varying consistency - readline seems to do so always, the other examples less so).
> I'm sure they added tabs to give the convenience of being able to adjust the indentation to what I like
I don't think this is the case. It looks like the authors of those projects decided that a tab character always is 8 chars wide, and that one tab vs eight spaces thus only is a question of encoding the same thing. So they're quite far removed from the idea that each indent level should be a tab (which is what most "tab-proponents" argue for).
> I'm sure they added tabs to give the convenience of being able to adjust the indentation to what I like
I don't think this is the case. It looks like the authors of those projects decided that a tab character always is 8 chars wide, and that one tab vs eight spaces thus only is a question of encoding the same thing. So they're quite far removed from the idea that each indent level should be a tab (which is what most "tab-proponents" argue for).
As I mentioned in another comment, any modern editor will let you at least detect, if not automatically fix, mixed tabs/spaces. And there's nothing about deciding on spaces-only that prevents people from mixing.
Here's one: when your code has no tabs, it's very obvious that whitespace is just a bunch of spaces. With tabs, it's harder to say, especially when mixed. It's one less thing to think about.
I'm 100% on board with not mixing them and making sure everyone on the team is on the same page. But that's a red herring; it can easily be remedied with linters/editor settings. The same is true for preventing tabs.
Eh, not really. A string with a tab is still hard to tell apart from a string with spaces. Linters don't help there (why would they?). And no way in hell am I going to change Vim to display them differently!
My linter (eslint) underlines any whitespace that mixes tabs and spaces.
My editor (VSCode) notifies me if I open a file that has any mixed tabs and spaces and offers to fix them all with one click.
> no way in hell am I going to change Vim to display them differently!
Sounds like we've found the problem.
My editor (VSCode) notifies me if I open a file that has any mixed tabs and spaces and offers to fix them all with one click.
> no way in hell am I going to change Vim to display them differently!
Sounds like we've found the problem.
Nearly all editors have some kind of "show whitespace" option now.
Not the main one I use!
I often manage thousands of servers. This is not a viable option for me.
I have the same dissonance.
For me, I think it's from my underlying interest in being good at something without having to make compromises or handicaps. As a benign example, I rarely/almost never change the keybinds in any of the code editors that i've used because I like the idea of being able to competently use all of them in their default settings to have a consistent experience everywhere. This allows me to use another instance of VSCode/PyCharm/Eclipse/etc. that's not my own and be able to reasonably be productive in that instance. It's a little silly, but it's something that I like.
Tabs runs counter to that underlying interest to a very small degree. They're there to be customized, and there's an expectation that you are supposed to customize their appearance for each view that you use to view them if you want a consistent appearance.
To an extent, I view the debate between the two as something similar to the debate between configuration vs convention. Convention is great when you're working within the 99% of the use cases that it supports, but it becomes difficult for the folks who need to do something not supported by the built in conventions and vice versa. Some people like one, some people like the other as a matter of preference. However, there's a small subset of the population that basically need configuration for one reason or another to operate. Whether it's because you're building a product that needs a feature that the framework doesn't support to stay afloat, or in this case, they need to be able to customize the appearance of code on the screen easily to be able to perform their duties in a reasonable time. I don't know if this comparison makes sense or is reasonable.
I will say that i've ran into enough errors due to people entering tabs into places that they shouldn't that my hate for tabs has grown more than it should. This ranges from people somehow (via copy+paste or whatever) entering a tab into a form field that doesn't allow for it to other engineers doing something similar for code and causing weird issues.
Edit: formatting
For me, I think it's from my underlying interest in being good at something without having to make compromises or handicaps. As a benign example, I rarely/almost never change the keybinds in any of the code editors that i've used because I like the idea of being able to competently use all of them in their default settings to have a consistent experience everywhere. This allows me to use another instance of VSCode/PyCharm/Eclipse/etc. that's not my own and be able to reasonably be productive in that instance. It's a little silly, but it's something that I like.
Tabs runs counter to that underlying interest to a very small degree. They're there to be customized, and there's an expectation that you are supposed to customize their appearance for each view that you use to view them if you want a consistent appearance.
To an extent, I view the debate between the two as something similar to the debate between configuration vs convention. Convention is great when you're working within the 99% of the use cases that it supports, but it becomes difficult for the folks who need to do something not supported by the built in conventions and vice versa. Some people like one, some people like the other as a matter of preference. However, there's a small subset of the population that basically need configuration for one reason or another to operate. Whether it's because you're building a product that needs a feature that the framework doesn't support to stay afloat, or in this case, they need to be able to customize the appearance of code on the screen easily to be able to perform their duties in a reasonable time. I don't know if this comparison makes sense or is reasonable.
I will say that i've ran into enough errors due to people entering tabs into places that they shouldn't that my hate for tabs has grown more than it should. This ranges from people somehow (via copy+paste or whatever) entering a tab into a form field that doesn't allow for it to other engineers doing something similar for code and causing weird issues.
Edit: formatting
I really think the split is almost purely a generational thing. If your first exposure to computers/coding was using a terminal, I think you will end up leaning towards spaces. If you grew up in the post GUI world on Windows or Mac, I think you end up leaning towards spaces.
Did you have a typo or was that intentional? You wrote "end up leaning towards spaces" for both. I'm not even sure which you meant to be tabs. I grew up post-GUI, but now use mostly the terminal. My preference is only spaces.
Purely a guess, but I think that spaces vs tabs is a proxy indicator of some psychological difference. Perhaps it is conscientiousness. On some editors, you have to go out of your way to change tabs to spaces. If you're very picky about how your code looks and want it to always look the same in every editor and to everyone, then maybe you use spaces. Personally, I do ascii diagrams and even arrows inside of comments to point to different variables and make comments on active code. I am very very picky about how my code looks. I know code aesthetics isn't a be all end all, but maybe it could be some psychological tendency like this. Also, I'm not a paragon of big bucks or awesome, revolutionary code. Over time, perhaps conscientiousness or fastidiousness keeps you employed or people give you more responsibility and money.
Should one of those "towards spaces" have been "towards tabs"?
If that's true it could explain the pay gap. By replacing pay gap with experience gap. Which makes sense that there would be a difference in pay.
Presumably the second one was supposed to say "leaning towards tabs".
I think you're onto something. In old-school editors there wasn't an abstraction layer between the characters and the way they were displayed. You were moving bytes themselves, so a character byte that took up multiple columns but which you couldn't edit the middle of must have seemed gross and unnecessary.
In today's world there's more abstraction, so people are more comfortable with abstraction. I use a font that merges "=>" into a single two-column-wide arrow, because it's more pleasant to read. I don't take offense at the fact that what's on my screen is slightly removed from what's literally on disc, because today you get more benefits from having that separation.
I think you're onto something. In old-school editors there wasn't an abstraction layer between the characters and the way they were displayed. You were moving bytes themselves, so a character byte that took up multiple columns but which you couldn't edit the middle of must have seemed gross and unnecessary.
In today's world there's more abstraction, so people are more comfortable with abstraction. I use a font that merges "=>" into a single two-column-wide arrow, because it's more pleasant to read. I don't take offense at the fact that what's on my screen is slightly removed from what's literally on disc, because today you get more benefits from having that separation.
It was at one time a holy war. Spaces won. I used to be strongly pro-space so I was happy. However, with time and much reflection I've soften my stance considerably.
In any case, improvements with code editors have helped a lot to paper over the differences.
In any case, improvements with code editors have helped a lot to paper over the differences.
That's still language dependent, and mainly (IMO) one of Python's Windows-isms.
Speaking of Python, my ideal variant would:
# be whitespace insensitive (add back the braces and an official linter to use ANY kind of standard convention for enforcing a 'look')
# (Mostly un-do the external changes of Python 3 back to 2, BUT align to UTF8 rather than some 16 format)
# and would also handle all forms of 'strings' like C (though not necessarily null terminated, it'd be the array length + array style)
# with some added pre-tags that MAY be used to track if it's known to be in a given encoding.
# Validation/translation to such an encoding would be done only if requested and by a sub-library. Such encodings might include: Validated-UTF8-NFC, Validated-UTF8-NFKD, Mixed-UTF8, Tainted-UTF8... The Mixed variant would be the result of combining two UTF8 strings normalized to different standards, while the tainted one would be applied if the string is combined with, modified / returned from a function not known to be Unicode safe.
# File handles and other external I/O could also be opened without an encoding or explicitly with a binary encoding to allow raw binary access, and with an encoding to cause a final coercion to the desired encoding on output (and validation on input).
# Ref: https://unicode.org/reports/tr15/#Norm_Forms
Speaking of Python, my ideal variant would:
# be whitespace insensitive (add back the braces and an official linter to use ANY kind of standard convention for enforcing a 'look')
# (Mostly un-do the external changes of Python 3 back to 2, BUT align to UTF8 rather than some 16 format)
# and would also handle all forms of 'strings' like C (though not necessarily null terminated, it'd be the array length + array style)
# with some added pre-tags that MAY be used to track if it's known to be in a given encoding.
# Validation/translation to such an encoding would be done only if requested and by a sub-library. Such encodings might include: Validated-UTF8-NFC, Validated-UTF8-NFKD, Mixed-UTF8, Tainted-UTF8... The Mixed variant would be the result of combining two UTF8 strings normalized to different standards, while the tainted one would be applied if the string is combined with, modified / returned from a function not known to be Unicode safe.
# File handles and other external I/O could also be opened without an encoding or explicitly with a binary encoding to allow raw binary access, and with an encoding to cause a final coercion to the desired encoding on output (and validation on input).
# Ref: https://unicode.org/reports/tr15/#Norm_Forms
A thousand times this. I could come up with a whole bunch of arguments in favor of either side, but they all pale in significance compared to this.
What I really wish is that we had better ways to express indentation or alignment than just these two. Or to associate inline commentary with code other than by using either spaces or tabs to fake a two-column layout. Separating content from presentation, including affordances for the visually impaired, is practically a solved problem for other kinds of text. Why not adopt some of those same techniques for the text we work with every day?
What I really wish is that we had better ways to express indentation or alignment than just these two. Or to associate inline commentary with code other than by using either spaces or tabs to fake a two-column layout. Separating content from presentation, including affordances for the visually impaired, is practically a solved problem for other kinds of text. Why not adopt some of those same techniques for the text we work with every day?
In that thread the OP decides that the needs of a few outweigh the needs of the many. He went from trying to achieve "consistency across environments," which is very convenient and efficient to purposely making his workflow less efficient and more time consuming to suit the needs of two co-workers in an environment where his code will probably be read hundreds of times.
Develop how you want to develop and commit how your codebase is written. How is that hard? I guarantee whatever IDE you use has a feature to convert/change the indendation model of a file. Why is this even a topic?
You're not going to guilt me into using spaces because two people who read my code didn't like it. If you're using tab-width 8 I'm probably not going to like reading your code very much either. Does that mean you should change your entire workflow to suit me?
Develop how you want to develop and commit how your codebase is written. How is that hard? I guarantee whatever IDE you use has a feature to convert/change the indendation model of a file. Why is this even a topic?
You're not going to guilt me into using spaces because two people who read my code didn't like it. If you're using tab-width 8 I'm probably not going to like reading your code very much either. Does that mean you should change your entire workflow to suit me?
One can see this as just deciding on spaces as a path of least resistance, and then taking the time saved arguing or pondering the question to make money instead.
All the tab advocates in this thread are like "Tabs are great, all you have to do is..."
That's why spaces are better. There's no "all you have to do." There's nothing. Just use spaces. Your code will look fine everywhere. Done.
Separation of content and presentation is a fine principle for many things, but as long as we're coding using text files, we are already far removed from that world. May as well stay simple and embrace the literal characters.
That's why spaces are better. There's no "all you have to do." There's nothing. Just use spaces. Your code will look fine everywhere. Done.
Separation of content and presentation is a fine principle for many things, but as long as we're coding using text files, we are already far removed from that world. May as well stay simple and embrace the literal characters.
> Your code will look fine everywhere.
...or nowhere, depending on who is reading.
...or nowhere, depending on who is reading.
I think the biggest and most obvious control is missing here -- the company they work for.
Much more likely is that companies that pay more, for whatever reason, insist on spaces rather than tabs as a required coding style.
A quick Google search reveals spaces are used rather than tabs by Google, Twitter, Mozilla, Facebook, Microsoft, Apple... so that already seems fairly suggestive as the cause to me.
Much more likely is that companies that pay more, for whatever reason, insist on spaces rather than tabs as a required coding style.
A quick Google search reveals spaces are used rather than tabs by Google, Twitter, Mozilla, Facebook, Microsoft, Apple... so that already seems fairly suggestive as the cause to me.
I suspect part of the reason is that using spaces makes it easier to collaborate with many other developers on a single codebase. There's no worrying "How will this look to others who override the default tab width?", "How to make this line up most consistently for everyone?", "Will it cause issues for me if I override the default tab width on this codebase?", etc.
Or the language they're working in. Python devs use spaces, go devs use tabs.
But I don't think the average Python dev makes more than the average go dev.
But I don't think the average Python dev makes more than the average go dev.
If you scroll down a little bit, they control for language and spaces are still higher across the board.
> Python devs use spaces
Speak for yourself- I use tabs with every language
Speak for yourself- I use tabs with every language
Yep, that's pretty much. It has nothing to do with which is better. Nothing whatsoever. It's just that a handful of companies that hire a ton of programmers and pay them a ton of money happen to share the same bias, and even that's probably because of copying each other. Even if you controlled for current company, alumni of those few have probably carried the gospel even further, again no matter if it's right or wrong. It's like observing that people who dress like Wall Street brokers make more money than people who don't, without considering what else it might mean that someone works (or had worked) on Wall Street.
I prefer spaces purely out of consistency reasons.
Some systems say a tab is 8 spaces, others say it's 4. Some editors can set a tab to any customizable N spaces. But a space is always a space so your code will look like you intended (or should I say indented) it no matter who's looking at it.
Some systems say a tab is 8 spaces, others say it's 4. Some editors can set a tab to any customizable N spaces. But a space is always a space so your code will look like you intended (or should I say indented) it no matter who's looking at it.
While I agree with you personally, I could see the counterargument of: A tab is always a tab, and I can tweak my IDE to render a tab as however many spaces I like (2, 4, 8, etc) without changing the code.
> I can tweak my IDE to render a tab as however many spaces I like
Sure, IDE's are easy (though many people use multiple IDE's and/or editors across multiple machines).
I've also got a couple diff tools, a few VCS's, also the online parts of VCS like web-based pull request review UI's.
Tabs also tend not to play as nice with vertically aligned elements, if you prefer that for things like say the '.' on multi-line chained method calls, or longer function parameter lists.
Sure, IDE's are easy (though many people use multiple IDE's and/or editors across multiple machines).
I've also got a couple diff tools, a few VCS's, also the online parts of VCS like web-based pull request review UI's.
Tabs also tend not to play as nice with vertically aligned elements, if you prefer that for things like say the '.' on multi-line chained method calls, or longer function parameter lists.
I'm a tabs for indentation, spaces for alignment person myself. A multi-line statement should have the same number of tabs on each line. Any line after the first should then have spaces as needed.
I'll work without complaint or changing it with any existing code whether spaces or tabs. Mix the two for indentation however and fixing it is the first commit I make before touching anything else.
I'll work without complaint or changing it with any existing code whether spaces or tabs. Mix the two for indentation however and fixing it is the first commit I make before touching anything else.
In a lot of cases though, you can't change what a tab is (consider looking at code on GitHub).
You can on Github but it requires using `?ts=4` in the url or committing an editorconfig file. Perhaps there are extensions that do it automatically.
This is a good point. Maybe at some distant point in the future we will softly decouple formatting from code by delegating it all to finely tuned autoformatters, or totally decouple it by storing code in a slightly more abstract form such that whitespace rendering becomes largely a presentation preference.
Reasons to prefer tabs:
https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
I don't understand this reasoning, I can set my editor to show x-spaces at the beginning of a line as however many I want. So I can make code indented with 2 spaces look like it was indented with 4.
That approach doesn't work if you use spaces both for indentation and alignment, you'd only want to multiply the indentation spaces. What editor has that setting?
Why would you "intend" for your indentation levels to be a certain pixel width on the reader's screen? Shouldn't that be the reader's choice?
In case anyone wonders why someone might answer "both" (other than an entirely undisciplined approach):
Tabs for line indentation, spaces for every other kind of alignment is one philosophy. It's the one that seems to hit the sweet spot for most of the issues that I care about (cross-editor consistent yet flexible management of line indentation depth as controlled by hits of the tab key + tabstop setting).
But if you're running the project and decide spaces are The One True Way™, I'll figure out a way to get the editor to do it for me and ask you for a raise for the trouble (and, of course, market standards). ;)
Tabs for line indentation, spaces for every other kind of alignment is one philosophy. It's the one that seems to hit the sweet spot for most of the issues that I care about (cross-editor consistent yet flexible management of line indentation depth as controlled by hits of the tab key + tabstop setting).
But if you're running the project and decide spaces are The One True Way™, I'll figure out a way to get the editor to do it for me and ask you for a raise for the trouble (and, of course, market standards). ;)
> I'll figure out a way to get the editor to do it for me and ask you for a raise for the trouble
You don't have to "figure out" anything. It's the default of every IDE I've ever used.
I press tab, VSCode inserts 4 spaces. I press shift+tab, it deletes 4 spaces.
Nobody actually presses spacebar 4 times to indent unless they are forced to use vim on some remote machine.
You don't have to "figure out" anything. It's the default of every IDE I've ever used.
I press tab, VSCode inserts 4 spaces. I press shift+tab, it deletes 4 spaces.
Nobody actually presses spacebar 4 times to indent unless they are forced to use vim on some remote machine.
> It's the default of every IDE I've ever used
Which is probably not every IDE or editor.
> I press shift+tab, it deletes 4 spaces.
How entirely intuitive and not-awkward compared to hitting delete.
> they are forced to use vim on some remote machine.
Vim is not exactly unpopular as an editor of choice.
But overarching all that -- the ;) at the end of my comment should have been a clue that I was not sincerely arguing that figuring out how to use spaces for tabs is an involved task. Even somebody using vim (whether forced or by choice) should know `:set expandtab`. Most editors worth investing in will provide a convenient way of doing this.
Rarer are the editors that will also let you change indentation width on the fly while expanding tabs to spaces, though, which is generally easy if you use tab characters for indentation. I'm not super familiar with VSCode, but having just fired it up and tried it out, maybe it can do this if you turn on Detect Indentation, though it doesn't seem to be the default, and I haven't put it through the paces for less trivial cases.
Which is probably not every IDE or editor.
> I press shift+tab, it deletes 4 spaces.
How entirely intuitive and not-awkward compared to hitting delete.
> they are forced to use vim on some remote machine.
Vim is not exactly unpopular as an editor of choice.
But overarching all that -- the ;) at the end of my comment should have been a clue that I was not sincerely arguing that figuring out how to use spaces for tabs is an involved task. Even somebody using vim (whether forced or by choice) should know `:set expandtab`. Most editors worth investing in will provide a convenient way of doing this.
Rarer are the editors that will also let you change indentation width on the fly while expanding tabs to spaces, though, which is generally easy if you use tab characters for indentation. I'm not super familiar with VSCode, but having just fired it up and tried it out, maybe it can do this if you turn on Detect Indentation, though it doesn't seem to be the default, and I haven't put it through the paces for less trivial cases.
> How entirely intuitive and not-awkward compared to hitting delete.
Try it, you'll like it. Especially when you want to untab an entire block of code instead of just one line.
- Highlight entire block of code
- shift+tab unindents entire block (whereas delete would delete entire block)
Plus, once you know a lot of shortcuts, `shift` seems to be sort of a negating key so it actually starts to be intuitive. (i.e. in vim, if you are searching for a string, "n" will move to next match, "shift+n" will move to previous match)
Try it, you'll like it. Especially when you want to untab an entire block of code instead of just one line.
- Highlight entire block of code
- shift+tab unindents entire block (whereas delete would delete entire block)
Plus, once you know a lot of shortcuts, `shift` seems to be sort of a negating key so it actually starts to be intuitive. (i.e. in vim, if you are searching for a string, "n" will move to next match, "shift+n" will move to previous match)
> > they are forced to use vim on some remote machine.
> Vim is not exactly unpopular as an editor of choice.
I think by "some remote machine" he's implying "default configuration", because vim can be configured to insert spaces; I would know, I have mine set up that way.
> Vim is not exactly unpopular as an editor of choice.
I think by "some remote machine" he's implying "default configuration", because vim can be configured to insert spaces; I would know, I have mine set up that way.
You can actually just press delete and it will delete a full tab-stop’s worth of spaces.
>Nobody actually presses spacebar 4 times to indent unless they are forced to use vim on some remote machine.
My PhD advisor does... His preferred editor is vi (not vim, but vi)
My PhD advisor does... His preferred editor is vi (not vim, but vi)
> Nobody actually presses spacebar 4 times to indent unless they are forced to use vim on some remote machine.
Totally, hazard pay factor. ;)
..but I do it because of habits learned in python shell and also because of that cowboy character on the Simpsons cartoon that called himself OCD about the number 4 and then counted 1,2,3,4 tapping his foot and shooting his gun into the air.
Totally, hazard pay factor. ;)
..but I do it because of habits learned in python shell and also because of that cowboy character on the Simpsons cartoon that called himself OCD about the number 4 and then counted 1,2,3,4 tapping his foot and shooting his gun into the air.
That was only necessary in Python shell briefly because of a bug. The bug was supposed to be a release blocker, but accidentally got marked incorrectly. It's fixed now, and has been for some time.
> Nobody actually presses spacebar 4 times to indent unless they are forced to use vim on some remote machine.
Even then, you can just use >> and << in vim; as long as it's set up correctly it'll insert spaces.
Works with whole sections in visual mode too ("v, down, down, down, >" will indent four lines).
Even then, you can just use >> and << in vim; as long as it's set up correctly it'll insert spaces.
Works with whole sections in visual mode too ("v, down, down, down, >" will indent four lines).
Are you sure you meant vim, not vi? 'Cause...
:set expandtab
:set expandtab
I answered "both" because I'm not running all of the projects I'm working on and some of them prefer tabs and others spaces - so I just go with the convention that that particular project uses.
This is why tools like gofmt is great. No more debates about spaces vs tabs.
The problem with “tabs for indentation, spaces for alignment” is that it voids the claimed tab-benefit of “anyone can configure tabs to be whatever width they want”.
Wouldn't this make sense?
https://medium.com/@hoffa/400-000-github-repositories-1-bill...
So the number of people that prefer spaces far outweighs the tabbers.
Now, take the pool of people that use spaces and tabs and let them compete for a 100k job. 9 times out of 10 even if randomly hired it will be a space person.
Also, as a by the way, on the medium post. The reason Java has so much tabs is specifically due to the default Eclipse formatting that prefers a mix Tab/Space approach. Which is absolutely horrifying in my personal opinion. I don't have any numbers but Eclipse probably holds 80%, followed by Netbeans and/or IntelliJ. (both of which default to spaces)
https://medium.com/@hoffa/400-000-github-repositories-1-bill...
So the number of people that prefer spaces far outweighs the tabbers.
Now, take the pool of people that use spaces and tabs and let them compete for a 100k job. 9 times out of 10 even if randomly hired it will be a space person.
Also, as a by the way, on the medium post. The reason Java has so much tabs is specifically due to the default Eclipse formatting that prefers a mix Tab/Space approach. Which is absolutely horrifying in my personal opinion. I don't have any numbers but Eclipse probably holds 80%, followed by Netbeans and/or IntelliJ. (both of which default to spaces)
> Take the pool of people that use spaces and tabs and let them compete for a 100k job. 9 times out of 10 even if randomly hired it will be a space person.
But you'll get the same result when they compete for a job that pays poorly. If all other factors were equal, the distribution of developers who prefer tabs should match that of developers who prefer spaces.
By your argument, people named Steve would make less money, because they're outnumbered by people not named Steve.
But you'll get the same result when they compete for a job that pays poorly. If all other factors were equal, the distribution of developers who prefer tabs should match that of developers who prefer spaces.
By your argument, people named Steve would make less money, because they're outnumbered by people not named Steve.
This could still be true though. There are more likely to be outliers in the large group than in the small group. However, there is a lower bound on the number (nobody makes below $0), but no upper bound. So the distribution is likely to be skewed.
So yes, people named Steve would make less money (though this argument might not work as well for people named Jeff, Warren or Bill I guess).
So yes, people named Steve would make less money (though this argument might not work as well for people named Jeff, Warren or Bill I guess).
I am not sure exactly what your argument is, but it doesn’t sound correct. The differences will be larger in the smaller group, but the expected value for the average pay in a group is independent of its size. That’s why you can use a sample to find out something about a population.
Very true, but something is still askew - the same will happen for women, minorities, etc.. Any time a large group and a small group, technically the small group tends to get less pay! What's going on? (I totally concede to your point, but now I'm left confused and wondering!)
Edit - ahh, hencq has a reasonable explanation for that.
Edit - ahh, hencq has a reasonable explanation for that.
Well, women and minorities are totally different case, not some general case of "the small group tends to get less pay".
For one, women are more than men (slightly, around 51%, but more. And if not more, equal). So it's not true that "the small group tends to get less pay" in this case. Women are less only in some jobs (like IT). There are more women than men in others (e.g. in education it's over 60% women). But even in those jobs women might be paid less than men.
Second, women and minorities being paid less can be explained by many factors, from discrimination, to women (either naturally, or by nurture) not pursuing promotions/raises aggressively enough, to exploitation (e.g. since some minorities are in bad condition socially, or might be afraid of deportation etc, one can exploit that to pay them less, "take it or leave it"). These practices of course can not be the case with tabs/spaces.
Third, there are countries where the majority gets less pay. E.g. in South Africa the whites are paid more than blacks, same for other countries with a smaller more privileged citizenry and a wider base of rural/indigenous/colored/etc population.
For one, women are more than men (slightly, around 51%, but more. And if not more, equal). So it's not true that "the small group tends to get less pay" in this case. Women are less only in some jobs (like IT). There are more women than men in others (e.g. in education it's over 60% women). But even in those jobs women might be paid less than men.
Second, women and minorities being paid less can be explained by many factors, from discrimination, to women (either naturally, or by nurture) not pursuing promotions/raises aggressively enough, to exploitation (e.g. since some minorities are in bad condition socially, or might be afraid of deportation etc, one can exploit that to pay them less, "take it or leave it"). These practices of course can not be the case with tabs/spaces.
Third, there are countries where the majority gets less pay. E.g. in South Africa the whites are paid more than blacks, same for other countries with a smaller more privileged citizenry and a wider base of rural/indigenous/colored/etc population.
>So the number of people that prefer spaces far outweighs the tabbers. Now, take the pool of people that use spaces and tabs and let them compete for a 100k job. 9 times out of 10 even if randomly hired it will be a space person.
Err, is the distribution is only affected by the number in each category (and not e.g. tab/space preference), then you'd be able to sample the same results for 30k jobs. 9 times out of ten it will be a space person there too.
Thus, if the 28,657 survey respondents are also randomly distributed, the ratio of poor vs good paid would be the same as real life, as would be the ratio of tabs vs spaces.
In other words, one wouldn't expect a skew in one category in favor of the other (if the choice wasn't a factor). Of course correlation != causation, but correlation can point to causation, or to a third, unknown factor that correlates with both attributes.
Err, is the distribution is only affected by the number in each category (and not e.g. tab/space preference), then you'd be able to sample the same results for 30k jobs. 9 times out of ten it will be a space person there too.
Thus, if the 28,657 survey respondents are also randomly distributed, the ratio of poor vs good paid would be the same as real life, as would be the ratio of tabs vs spaces.
In other words, one wouldn't expect a skew in one category in favor of the other (if the choice wasn't a factor). Of course correlation != causation, but correlation can point to causation, or to a third, unknown factor that correlates with both attributes.
This has come up before. My theory is this:
Tabs are great if you work by yourself. If you work with others, you need more complicated rules to be followed like "tabs for indentation, spaces for alignment."
So...
My theory is that coders using spaces have worked in more places and/or larger places, which tend to end up paying more.
Tabs are great if you work by yourself. If you work with others, you need more complicated rules to be followed like "tabs for indentation, spaces for alignment."
So...
My theory is that coders using spaces have worked in more places and/or larger places, which tend to end up paying more.
> Tabs are great if you work by yourself. If you work with others, you need more complicated rules to be followed like "tabs for indentation, spaces for alignment."
Except you don't, because you could just never align code, which completely eliminates the problem. I find that aligning code is way more trouble than it's worth.
Except you don't, because you could just never align code, which completely eliminates the problem. I find that aligning code is way more trouble than it's worth.
This is one of those correlation != causation articles. Probably something symptomatic as you describe.
I suspect it could be large, well-paying companies with prescriptive style guides skewing the results. eg, Google standardized on spaces for all their languages I've interacted with, maybe some others did too.
According to the blog post, the effect remains when company size is taken into account.
I strongly favor spaces, because using tabs adds one more thing to worry about when writing code to be read by others.
I suspect a lot of folks who work on large, multi-dev projects feel the same way. We prefer to lay out our code and indentations with the expectation of consistency for others. Spaces allow us to not worry "Will this be readable by colleagues who prefer 2-wide tabs vs. 4-wide tabs?" We just adopt a convention (2 or 4 spaces) for each codebase and run with it.
Similarly, when others have used spaces, it's one less thing to worry about when starting work on a new codebase. There's no evaluating "will this codebase look better with 2-wide or 4-wide tabs?" or "Can I override the default tab width with my preference, or will that make this codebase less readable?"
I suspect a lot of folks who work on large, multi-dev projects feel the same way. We prefer to lay out our code and indentations with the expectation of consistency for others. Spaces allow us to not worry "Will this be readable by colleagues who prefer 2-wide tabs vs. 4-wide tabs?" We just adopt a convention (2 or 4 spaces) for each codebase and run with it.
Similarly, when others have used spaces, it's one less thing to worry about when starting work on a new codebase. There's no evaluating "will this codebase look better with 2-wide or 4-wide tabs?" or "Can I override the default tab width with my preference, or will that make this codebase less readable?"
> Spaces allow us to not worry "Will this be readable by colleagues who prefer 2-wide tabs vs. 4-wide tabs?" We just adopt a convention (2 or 4 spaces) for each codebase and run with it.
I don't get it. It allows you to not worry about it by letting you just say "no, it won't be readable by you because we arbitrarily decided to make your life difficult".
Tabs are the one that let you not worry about whether people who prefer a different tab width will find the code readable because they can configure a different tab width.
I don't get it. It allows you to not worry about it by letting you just say "no, it won't be readable by you because we arbitrarily decided to make your life difficult".
Tabs are the one that let you not worry about whether people who prefer a different tab width will find the code readable because they can configure a different tab width.
That may be true for codebases that always use a single tab for each indentation level -- I get that. But to stay readable regardless of tab width, it requires a coding style that keeps indentation strictly consistent with syntactic context (not an issue in Python, since indentation is syntactically significant already).
It also limits what developers can do to align things in JavaScript, Lisp, Ruby, C#, etc. -- especially when using complex call chains/lambdas, large literal data objects, s-expressions, long parallel repetitions blocks of code, etc. In those cases, using spaces is a huge benefit, because it provides a way to scoot things left or right to make them more readable. With tabs, you can't do that unless you mix tabs and spaces -- which is not cool at all.
It also limits what developers can do to align things in JavaScript, Lisp, Ruby, C#, etc. -- especially when using complex call chains/lambdas, large literal data objects, s-expressions, long parallel repetitions blocks of code, etc. In those cases, using spaces is a huge benefit, because it provides a way to scoot things left or right to make them more readable. With tabs, you can't do that unless you mix tabs and spaces -- which is not cool at all.
>With tabs, you can't do that unless you mix tabs and spaces -- which is not cool at all.
There's no problem mixing tabs and spaces iff by 'mixing' you mean 'adding some spaces for alignment after the tabs for indentation. Though I think there are very, very few situations where that's actually meaningfully beneficial over adding another tab beyond those for the nominal indentation of the block.
There's no problem mixing tabs and spaces iff by 'mixing' you mean 'adding some spaces for alignment after the tabs for indentation. Though I think there are very, very few situations where that's actually meaningfully beneficial over adding another tab beyond those for the nominal indentation of the block.
> Spaces allow us to not worry "Will this be readable by colleagues who prefer 2-wide tabs vs. 4-wide tabs?"
My team uses two spaces as convention. It sucks. Nothing is readable. Whatever formatting issues would sneak in if different developers used different tab sizes would be minor compared to having to consistently read code with a quarter of your preferred indent size.
Most formatting tools should also be able to catch such errors.
My team uses two spaces as convention. It sucks. Nothing is readable. Whatever formatting issues would sneak in if different developers used different tab sizes would be minor compared to having to consistently read code with a quarter of your preferred indent size.
Most formatting tools should also be able to catch such errors.
It's just cause people using tabs are not using properly configured IDEs or text editors, which reflects a lack of experience or adaptability, which reflects the lower salary.
Edit: It's also kind of funny how people in this thread are making it seem like there's some kind of controversy. There isn't: the question was settled a long time ago.
Edit: It's also kind of funny how people in this thread are making it seem like there's some kind of controversy. There isn't: the question was settled a long time ago.
This can be summed up "developers with experience with others use spaces"
Tabs do not interact well with teams.
Spaces are a source of consistency for teams.
Basically, spaces have the same indentation for everyone sharing code while tabs do not.
To set up spaces only in your editor requires a mindful effort.
https://www.jwz.org/doc/tabs-vs-spaces.html
Tabs do not interact well with teams.
Spaces are a source of consistency for teams.
Basically, spaces have the same indentation for everyone sharing code while tabs do not.
To set up spaces only in your editor requires a mindful effort.
https://www.jwz.org/doc/tabs-vs-spaces.html
Or give up the fight over formatting in general and adopt a tool like [0] Black, which has no rules or options to configure and only one correct style. _You can have any any style you want, as long as it's black._
[0] https://black.readthedocs.io/en/stable/
[0] https://black.readthedocs.io/en/stable/
I was going to complain about it, but I like all the formatting decisions made by black.
I've always suspected that "go fmt" is a tool of income suppression...
My personal preference is tabs and the reason I never hear given is that I simply don't want to press a button two or four times when I can press it once. When I type a single tab: bam! code indented. When I type backspace, the indentation is removed. It's easy. When I'm using spaces -- even in an editor that expands tabs to spaces -- I have to press backspace four times to de-indent code. I end up de-indenting a lot of code because a pet peeve of mine is unnecessary conditionals. For example if you'll pardon the formatting:
I just feel like I'm stuck in molasses, having to go through several extra steps whenever I'm writing code that compels the use of spaces over tabs. That said: It's a personal preference and I'll use spaces where appropriate.
Most people's argument against tabs seems to have to do with vertically aligning code. This is a shit argument, because tabs should be used for indentation only. If your indentation is the proper number of levels then spaces can be used for any remaining vertical alignment. Tabs should be used for indentation, not vertical alignment.
Example:
if(cond) {
flag = true;
} else {
flag = false;
}
flag = false;
if(cond) {
flag = true;
}
I just feel like I'm stuck in molasses, having to go through several extra steps whenever I'm writing code that compels the use of spaces over tabs. That said: It's a personal preference and I'll use spaces where appropriate.
Most people's argument against tabs seems to have to do with vertically aligning code. This is a shit argument, because tabs should be used for indentation only. If your indentation is the proper number of levels then spaces can be used for any remaining vertical alignment. Tabs should be used for indentation, not vertical alignment.
Example:
tabtabtabtabType myArray[] = {
tabtabtabtabtab 123, 456, 789, 101112,
tabtabtabtabtab131415, 161718, 192021, 222324
tabtabtabtab};
> When I type a single tab: bam! code indented. When I type backspace, the indentation is removed. It's easy. When I'm using spaces -- even in an editor that expands tabs to spaces -- I have to press backspace four times to de-indent code
Newer editors like VSCode handle this correctly. Tab = add 4 spaces, delete = remove 4 spaces.
But really, you should get in the habit of using tab to indent, and shift+tab to deindent (not delete). shift+tab has the added advantage of being able to deintent an entire highlighted block of code in virtually all editors.
> can often be represented as just:
Well, in this case you could just do `flag = cond` but I see your point
> Most people's argument against tabs seems to have to do with vertically aligning code. This is a shit argument, because tabs should be used for indentation only. If your indentation is the proper number of levels then spaces can be used for any remaining vertical alignment.
Well, a lot of people haven't configured their editors to visually see whitespace, and since it is invisible by default, it means a lot of code with mixed whitespace is committed which is a hard problem to solve. So you just configure your auto-formatter to convert everything to spaces so there is no ambiguity.
Newer editors like VSCode handle this correctly. Tab = add 4 spaces, delete = remove 4 spaces.
But really, you should get in the habit of using tab to indent, and shift+tab to deindent (not delete). shift+tab has the added advantage of being able to deintent an entire highlighted block of code in virtually all editors.
> can often be represented as just:
Well, in this case you could just do `flag = cond` but I see your point
> Most people's argument against tabs seems to have to do with vertically aligning code. This is a shit argument, because tabs should be used for indentation only. If your indentation is the proper number of levels then spaces can be used for any remaining vertical alignment.
Well, a lot of people haven't configured their editors to visually see whitespace, and since it is invisible by default, it means a lot of code with mixed whitespace is committed which is a hard problem to solve. So you just configure your auto-formatter to convert everything to spaces so there is no ambiguity.
"I have to press backspace four times to de-indent code"
I used to only press backspace once to delete four spaces because I use a better editor. Now I press it zero times because I've integrated black, gofmt and prettier.js into my editor and it indents automatically.
I used to only press backspace once to delete four spaces because I use a better editor. Now I press it zero times because I've integrated black, gofmt and prettier.js into my editor and it indents automatically.
From the given data it appears that people that use stackoverflow are being paid really really low wages. Maybe people who answer online surveys are poorly paid?
My personal graphologist said that although tabbers earn more, they tend to be more focused on their work and less altruistic, so they answer less surveys.
Sampling bias is difficult to avoid in the best designed research.
My personal graphologist said that although tabbers earn more, they tend to be more focused on their work and less altruistic, so they answer less surveys.
Sampling bias is difficult to avoid in the best designed research.
Back when communications and printing devices were much slower, we often chose tab stops to reduce the number of characters sent. I have used this algorithm, but I doubt it impacted my career earnings.
James L. Peterson, James R. Bitner, and John H. Howard, ``On the Selection of Optimal Tab Settings'', Communications of the ACM, Volume 21, Number 12, (December 1978), pages 1004-1007.
http://jklp.org/profession/papers/tab/paper.html
James L. Peterson, James R. Bitner, and John H. Howard, ``On the Selection of Optimal Tab Settings'', Communications of the ACM, Volume 21, Number 12, (December 1978), pages 1004-1007.
http://jklp.org/profession/papers/tab/paper.html
[deleted]
That is an old post (June 2017). I thought it was now accepted that people should use tabs, until I read the comments here. From a recent post, Nobody talks about the real reason to use tabs over spaces, https://news.ycombinator.com/item?id=20341354; if you're visually impared, using spaces make for poor accessibility. Don't be a dick, use tabs!
Ok, but 2 or 4 spaces?!
Yes. :-) The right answer depends on the project. I really appreciate it when projects have .editorconfig files so that indentation just works.
https://editorconfig.org/
https://editorconfig.org/
4.
Also, max line width should be 120 characters. 80 is too limiting if you're using sensible variable names like you should.
Also, max line width should be 120 characters. 80 is too limiting if you're using sensible variable names like you should.
3 looks pretty nice in a lot of code...
Please don't do that. Just... please... don't.
I will have trouble controlling my frustration if I ever have to work on a codebase built with 3 spaces per indentation.
I will have trouble controlling my frustration if I ever have to work on a codebase built with 3 spaces per indentation.
There's zero logical reason to use a power of two, though.
If you use tabs, you can customize how it looks. ;)
heretic
If I'm reading the chart correctly, it seems that Go developers who use spaces rather than tabs actually earn more? That's quite surprising.
It is. I wonder if it's an artifact of the other languages used at the organization, i.e. Go developers who use spaces are likely to be working on utilities or support code for a product that's primarily written in C or C++ (and probably been generating revenue for a while), while Go developers who use spaces are more likely to be working in green-field pure Go codebases that are newer with less of an established market.
I wonder if this is related to acculturation. I would guess that people who are trained as computer scientists or work in tech are exposed to arguments over whitespace, and more self taught people are not. Not to say that spaces are a more sophisticated choice, but that the higher paying sectors are more polarized.
So where does using the "tabs to spaces" tool lie here?
I technically press the tab button but my edit inserts 4 spaces.
I technically press the tab button but my edit inserts 4 spaces.
It seems to me that the benefits of tabs tend to are reduced as storage becomes cheaper, as text editors get more powerful, and as various other tools becomes smarter.
So people sticking with tabs are more typically "old-school" and stubborn in all their approaches. And that can explain the pay difference.
So people sticking with tabs are more typically "old-school" and stubborn in all their approaches. And that can explain the pay difference.
Tabs clearly indicate a specific level of indent.
Spaces may or may not be rendered to a specific width in different editors, and in fixed width editors are equivalent to 'pixel perfect' rendering; the difference between a dead tree rendering that is static and an electronic metadata included document.
Spaces may or may not be rendered to a specific width in different editors, and in fixed width editors are equivalent to 'pixel perfect' rendering; the difference between a dead tree rendering that is static and an electronic metadata included document.
This is why the world will never make peace. If we can’t even agree on something silly as tabs vs spaces.
I don't think it's silly. I strongly dislike the ergonomics of contributing to a codebase that uses tabs.
I really don't understand the war behind this I always pressing tab button when I want to tabs(giving more than one space) things
Does the war is about pressing tab button vs space button?
Or is it about the underlying of it?
Afaik when We press the tab button the editor is sending a space right? Then what's with the fuss?
Does the war is about pressing tab button vs space button?
Or is it about the underlying of it?
Afaik when We press the tab button the editor is sending a space right? Then what's with the fuss?
[deleted]
I would bet this is due to some hidden variable. Maybe older or more experienced developers have a tendency to use spaces, so their compensation reflects age/level/experience, not their choice of indentation?
Never mind, reading the article sees him cover at least the experience, language, and location of the developers, and there is still a significant difference.
Maybe the team aspect made a difference, or devs worked at companies with strict style guidelines, which happened to be companies who pay well, or because that company is on their resume, they make more later on?
Maybe the team aspect made a difference, or devs worked at companies with strict style guidelines, which happened to be companies who pay well, or because that company is on their resume, they make more later on?
Tabs are adjustable, so more likely in larger teams. But devs on smaller teams probably make more as individuals. That’s my guess.
i am always amazed at how much time people sink into these discussions :D as if commonly formatted textfiles was the biggest concern people have in their day-to-day ;)
* based on one survey of self-reported data
Probably because they can read their code.
[deleted]
[deleted]
And what about developers that add spaces by using the TAB-key?
You mean ALL of them?
Question for all of you tabs people...do you guys think that spacers are hitting the space bar 2/4/8/X times?
Question for all of you tabs people...do you guys think that spacers are hitting the space bar 2/4/8/X times?
Yeah I watch that show (I have a Hooli t-shirt!) and have seen that scene, and honestly that's when I first started posing my original question.
4x or 8x ?
I like tabs because it allows developers to configure their editors with whatever width they desire.
tabs don't work when you visually align code. e.g.
If a default install of an IDE (including vIM) will screw up your code.... you might consider rethinking your strategy. :-)
some.method(param,
param2,
param3)
If a default install of an IDE (including vIM) will screw up your code.... you might consider rethinking your strategy. :-)
That code would be misaligned anyway when someone changes the name of `some` or `method`.
You should format it like this (regardless of whether you use tabs or spaces):
You should format it like this (regardless of whether you use tabs or spaces):
some.method(
param,
param2,
param3
)That would be how I would do it, because generally the coding I do is simple enough that I can trust Visual Studio Code to "Beautify" my finished work and insert all the tabs it needs to align things.
> The above doesn't work if the creator of the code uses a different tab width than I do.
Tab proponents suggest alignment to be done with spaces, and indentation to be done with tabs.
Tab proponents suggest alignment to be done with spaces, and indentation to be done with tabs.
[deleted]
Honestly the I've lost my appreciation for alignment. I've been writing it like this for a while now:
some.method(
param, param2, param3)
(2017)
[deleted]
For all my JavaScript developers - just gonna leave this here.
https://standardjs.com/
https://standardjs.com/
Can confirm
Those salaries are painfully low. I started at 75k. Who's making less than 50k and in such great numbers? This must be non US jobs? I question this data.
99% of the planet would disagree with you: http://www.globalrichlist.com/
We are talking about software engineers. I'm not talking about top company pay either. I don't think I've ever gotten an offer for 50k
The data is global, hence the heavily skewed median compared to US alone. Check out the 6 bar charts that group by country.
[deleted]
Am I the only one who doesn't give a fuck?
Is it really a subject?
And I'm not saying that code aesthetics doesn't matter, I tend to obsess over good typography and alignment, but I use both tabs and spaces, switching depending on the code-base/context, without even thinking about it.
Is it really a subject?
And I'm not saying that code aesthetics doesn't matter, I tend to obsess over good typography and alignment, but I use both tabs and spaces, switching depending on the code-base/context, without even thinking about it.
Who gives a fuck about an Oxford comma?
Thats racist
It's probably related to the editor choices one makes? As a tabs-only person, i am probably a little more autistic, a little less social (spaces are easier to share with others), a little less open to new technologies.
It's probably related to the editor choices one makes? As a tabs-only person, i am probably a little more autistic, a little less social (spaces are easier to share with others), a little less open to new technologies.
I would be fine with using spaces if it weren't for all the spaces-users. More specifically, how so many projects seem to go for the shortest common denominator, often just two spaces. I mostly write C++, and agree strongly with the rationale given in the Linux coding style for using 8-char tabs - it promotes better design practices:
> Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
> In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.
> Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
> In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.
Last month there was a reddit discussion that outlined some really compelling accessibility-related reasons to use tabs, worth a read: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...