Almost certainly a result of the spaces cabal and the (often unspoken of) prejudice against tab users. Don't think you make hiring decisions based on tabs vs spaces? Well you're part of the problem, then.
I'm building an app to help you easily email your congressperson and ask them to create legislation requiring space/tab equality. This has to stop. Please consider donating to my Patreon.
> Don't think you make hiring decisions based on tabs vs spaces?
I actually ask candidates "spaces or tabs?" in every single interview. I don't really care what the response is in regard to the holy war, and it doesn't mean anything on its own, but having SOME thought out response can be a GREAT indicator of how well versed someone is in general.
e.g. I'm going to think way more highly of someone that says "tabs, because then people can set the indentation render size to whatever they prefer in a way that doesn't affect other users" way more than someone who says "whatever my editor sets it to".
Does spending time considering the implications of spaces vs tabs really indicate competence? To me being over-obsessed with minor details might be either negative or at most neutral value. There are thousands of interesting programming subjects to initiate a conversation to evaluate competency.
At most it's a matter of what tools you use as well as accepted standards in the individual programming language's community.
> Does spending time considering the implications of spaces vs tabs really indicate competence?
No, it signifies that you have spent enough time programming in a wide variety of platforms and with enough other peers to run in to the issue and understand that it exists.
It doesn't signify anything. I think you might be giving a bad impression of your company by asking that question. In an interview, you have a limited amount of time to come to a judgment about a candidate. Using that time to ask pointless and borderline flamebait questions is going to be a red flag for a lot of candidates. You are also going to put candidates on edge by making them worry about whether or not they have given the "right" answer to a silly question.
It just signifies that someone has worked with enough pedantic developers that they had to form an opinion on something as insignificant as this, or that this person is pedantic enough to have a strong opinion on it.
I wouldn't consider the first to be a good indicator of someone's skill as a developer, and the second would be a good indicator that it was someone I didn't want to work with, but I'm guessing that's not how you're using it...
> it signifies that you have spent enough time programming in a wide variety of platforms and with enough other peers to run in to the issue and understand that it exists
Or maybe it signifies youthful inexperience?
Of the programmers that I know, the longer they have been programming, and the more varied projects they have worked on, the less they care about tabs v. spaces. Whatever standard the project they're working on uses, that's how they set up their editor for that project, because it's one less thing to have to worry about.
>Whatever standard the project they're working on uses, that's how they set up their editor for that project, because it's one less thing to have to worry about.
I think that the OP would consider that a fine answer.
My answer would be that any modern software development shop should be using a linter like Rubocop, eslint or gofmt that runs automatically on every commit. It doesn't actually matter what standard a group chooses, but there is real cognitive overhead to trying to understand inconsistently formatted code. And, people shouldn't be the ones criticizing incorrectly formatted code; a GitHub robot should be.
My answer would be: why are you asking me? Shouldn't I be asking you? Do you have coding standards here? Or is it going to be my job to decide on the coding standards?
It's not meant to be aggressive, but to make a point. It's important that everybody uses the same coding style, regardless of personal preference. Spaces are fine, tabs are fine, but mixing them would be absolutely terrible. A programmer's personal preference for one or the other is irrelevant. What matters is that he's willing to adapt to the coding style of the company.
> Spaces are fine, tabs are fine, but mixing them would be absolutely terrible. A programmer's personal preference for one or the other is irrelevant. What matters is that he's willing to adapt to the coding style of the company.
That sounds like a better answer to the question right there. It's the "some though out response" that the interviewer was looking for, willingness to put the team's decisions ahead of your own, and so on.
Tabs for indent, spaces for formatting within. No need to push your tab size standards on the next person to edit your code, and no need to force their editor to retab it to their preference, and back again when it's saved.
"It's the editor's default", or worse, "I never really thought about it" are horrible reasons for doing anything, and hearing something else might be a sign of a pulse.
I also prefer tabs, but always make sure to write spaces to disk. The better you are with your editor, the less you have to worry about whether the original file was using spaces or tabs.
Therefore, writing 100% spaces to disk is the best way to insulate yourself from possible issues of people who _don't_ know what they're doing with spaces, tabs, or their editor.
Plus, when most people are using an editor that doesn't have a per-project settings for the language/format to use, it's really hard. Getting everyone else on a VS solution to change their JS editor to 2 spaces, and disable the auto-format is an exercise in frustration.
That said, the convention for most languages seems to be towards spaces at this point, and I don't care enough to argue anymore as my choice of editor(s) allows me to set it per project at least.
Since space indenters can't have keys matching what's produced by them I wonder what else they remap beyond the tab key, to something else completely unrelated
To me it makes as much sense as replacing dots with commas, but space indenters have gone beyond their delusion now
Since tab indenters have characters indistinguishable from spaces that are a different width from any other character on the screen I wonder what other bizarre escape codes are in their source
To me it makes as much sense as having invisible characters scattered throughout your code, but tab indenters have gone beyond their delusion now
> having SOME thought out response can be a GREAT indicator of how well versed someone is in general.
Did you cross-check this against any other measure? I can see it going both ways - maybe someone who saves their attention for more important matters would be better at producing value than someone who cares about such minutiae.
an indicator is just that, an indicator. It doesn't mean anything on its own, but in the presence of additional information (interview question responses and discussions in this case) it can help paint a better picture.
If someone answered this question with "what? I don't know/care", and then knocked more important questions out of the park, then it was obviously a bad indicator and isn't relevant.
Yeah, it can start some interesting conversations too - I don't care personally and tend to go with whatever autoformat in the editor uses. My view is that formatting code shouldn't be a human's job, adding linebreaks on long lines, spacing things out to exactly line up, etc is just a waste of my time.
That's the computer's job - it should do it based on human readability rules though, clang-format is probably the best example of these rules applied, it uses a TeX-style formatting engine for code.
completely agree with you. and i religiously autoformat my code before i read the code and just before i save the file.
However it still amazes me how the majority of developers i work with either have no opinion on the topic or worse think this is a bad idea. some the reasons I've heard was it makes alot of changes to a file causing alot of diffs with previous version making it harder to figure was was actually changed, or they don't like they way its formatted .
Yep if you're going to convert from tabs to spaces or vice versa, please do a check-in/commit consisting only of that change before making any substantive code changes.
Was going to say the same... nothing wrong with a commit including only format changes... for that matter, add it as a task to the project, commit, run it, commit, then proceed to edit. If you have commit hooks setup, add it as a precommit hook/task.
As long as it's relatively transparent for everyone to be able to use.
In it, they mention an autoformatter as one of the best tools they gave their developers in terms of productivity gain and it really got me thinking about how this should be versus how it is in practice. There are some really bad autoformatters and some really good ones - find one that works and is configurable to match your standard and I think it really does result in a good productivity improvement.
completely agree, I'm also the (original) author of https://github.com/jdc0589/JsFormat though, so I'm probably just more sensitive to formatting stuff in general.
Doesn't that mean you make tools like git blame a whole lot less useful? I'm all for formatting my own code correctly, but I'm not going to nuke git history for a few spaces.
Blame is for me at least a fairly infrequently used operation and there's really not much else it breaks unless there are other active branches at the time. I don't find blame information that valuable and would argue that most uses are in fact counterproductive (it's in the name - blame).
You'd only have to do it once, all changes past that point would be good assuming you set it up in your IDE automatically or in your precommit. So if for some reason you needed to go back a long ways and blame something you could always check out back past that initial styling fix and see it.
Wow, I am a spaces guy but honestly, didn't care this much. Clearly, I should! I mean, I would have failed that interview question totally. Except, I would have said whatever the team consensus was.
I don't use it as a question to really be scored as a critical pass/fail. It's intended to potentially start a conversation and maybe give me an idea of someone's experiences.
I personally prefer tabs for the reason mentioned above... also, before JS minimizers, it meant less characters in the output. Now, I'll set my editor to whatever is the convention in the team, and/or the greater community (JS is 2 spaces, mostly, C#/VB 4, etc.).
As others have mentioned, having a required auto-linting step helps a lot. But it really depends on your specific needs.
If my dreams come true I will work with Elixir next. https://github.com/christopheradams/elixir_style_guide#space... "Use two spaces per indentation level. No hard tabs." See, this is why I like Elixir, I do not need to change my spacing habits from Drupal! :D
Whats wrong with this? I just accept the defaults. Whether that is what the current project demands or what the editor defaults to. Why waste my time over these things?
> Whats wrong with this? I just accept the defaults. Whether that is what the current project demands or what the editor defaults to.
There's your answer: if letting your editor do whatever and not caring to 'waste time over these things' means you've committed a bunch of code ignorant of the convention respected by the rest of the project, that's not that great.
I did say "what the current project demands". I did not say "I just push whatever I feel like". Again, I don't see the problem with not caring and just going with what others have picked.
Frankly, if over 90% of your peers are using a given editor/ide, odds are they're using the defaults... as trying to get everyone to change the defaults is painful. Having spent years fighting this in some environments, it's far easier to accept.
If your editor supports a common config format (.editorconfig), then use that... if you're all using the same IDE, then best to adapt to the defaults (mostly).
I assume from this response that you have never worked with someone who created semi-constant issues because they didn't realize that .vimrc they copied from GitHub was silently turning spaced into tabs whenever they saved a file.
"whatever my editor sets it to" is what I would answer, precisely because I've heard the arguments for both sides to death, and I acknowledge that this holy war exists because both sides' arguments have merits. For me, I expect that my team as a group has a rationale for whatever choice is made in the interest of avoiding pointless bikeshedding, but I expect each individual to be adaptable enough that the choice doesn't actually negatively impact their productivity.
What about "whatever you're using"? It probably doesn't seem well thought out, but is there any other answer? Personally I don't care. I use spaces in Python because of pep8 and tabs in PHP or JS depending on whether or not the file is using tabs or spaces already. Sometimes I realize I checked in a file to git with tabs instead of spaces so I go back and run a find and replace to match indentation. Is that so wrong? Shitty question IMO
If I were the candidate I will be giving mean looks while tapping the space bar as fast as possible!
Spaces FtW!
Ps. On a more serious note, the editor (actually the vim plugin) takes care of this.. default is 2 spaces for ruby and 4 for python (PEP8). I like ruby more, the identation too.
rant: a default unconfigured vim instance is a perfect example of my main issue with all this whitespace crap. Personally, I like tabs, but ultimately, like you mentioned, it doesn't matter with a well set up editor.
HOWEVER, a default unconfigured instance of vim is not capable of editing, for example, a YAML file in a valid manner without the user knowing that they have to manually set the tab character to spaces or mash the spacebar 1000000 times instead of using the tab key. Thats some REALLY horribly UX. It's not VIMs fault, and its not the YAML spec's fault, but it adds up to some bullshit.
Does anyone actually use an unconfigured instance of vim for actual development?
I can see for people sshing in, editing a file and getting back out without bothering, but you'd have to be a quite a purist to do all your development in an unconfigured Vim.
You can yank and modify existing lines which will keep your YAML spaces.
For years I never used Vim to develop full time so never invested the time to setup my vimrc file. But now that I use it for development and spent the time to set up my vimrc, it's brilliant to be able to just take the goodness with you.
> I can see for people sshing in, editing a file and getting back out without bothering, but you'd have to be a quite a purist to do all your development in an unconfigured Vim.
Thats really the only instance. It's more of a "hey, look at this bullshit I'm pointing out from my fundamentalist high horse" argument than a legitimate one.
I wish I could say I'm surprised. Hacker News has a known spacial prejudice problem. It's exacerbated by the fact that few people of those who experience spacial preference (please use the proper terminology) feel comfortable here, so many just leave.
It happens with the best of us. Even Thomas Jefferson used spaces when drafting the Declaration of Independence, despite being an outspoken tabs supporter.
The reason I use tabs is pretty simple. It's faster to move around only using the keyboard. It's also faster if I'm changing code that requires reformatting. Finally, when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc. In other words, it adds flexibility.
Brace yourself: I use two spaces after the end of sentences too. [1] I am quite the rebel.
Modern IDE's (Sublime Text) let you easily convert spaces to tabs (or vice versa) and intention length of existing code.
[2]
> Finally, when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc. In other words, it adds flexibility.
This is exactly why I use tabs and the reason which appears to never get cited in the holy wars.
People who use spaces want to line up their '=' signs, that's fine, but I don't believe it's my position to enforce the amount of whitespace another developer has to use in their editor. It's an accessibility thing, they might have their font size really large because of eyesight problems in which case 8 spaces is going to make reading the code a lot harder.
The fact that Python's rule used to be 8 spaces, then got changed to 4 thereby invalidating old code really showed me how shortsighted it is to use a set number of spaces in a whitespace sensitive language.
> This is exactly why I use tabs and the reason which appears to never get cited in the holy wars.
I see this cited every time. Unfortunately, it's bogus in practice. Consider:
print('some long thing',
further, arguments)
If this is an indented block, you'd have to indent the second line to the correct depth with tabs, then add exactly six spaces for alignment. You have to mix spaces and tabs, which is never good news. Additionally, if you try to actually type in the six spaces, editors might take, say, four of them and group them into a tab. (I have vague memories from a long time ago of Emacs doing this. I might be wrong.)
If you get this wrong in program parts that are by definition invisible, it might look good for you and look really bad for others (i.e., the opposite of the stated goal). In code I see mixing spaces and tabs, the latter tends to be the case.
I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs.
That being said, this problem and problems like it can be solved simply by not aligning things visually:
print(
'some long thing',
further,
arguments
)
Strictly adhering to indentation and never alignment can make the code a bit less readable, but conforming to a canonical indentation like this also makes it easier to reindent, move code around, etc.
I think that's what the argument really comes down to – alignment flexibility vs display flexibility. It's interesting to see which people generally prefer.
Yes, and I'd say that that's a big problem. I'm not a religious opponent of tabs, but making code less readable just so you can keep using them wouldn't fly if I were Malevolent Whitespace Dictator For Life.
> I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs.
Could you please clarify why do you consider "tabs for indentation, spaces for alignment" such a bad practice? I have never read any argument against it.
Alignment itself can be done automatically by any editor that supports smart tabs.
- tabs allow for custom settings
- tabs need spaces to allow for alignment, because previous
- automatically deciding what constitutes alignment vs
indent is a non-trivial problem, highly dependent on the
language†
- using spaces throughout is worse theoretically because
it flattens the theoretical problem but solves impedance
mismatch
- therefore I use spaces and am all the merrier in every practical
use case
- except for languages who make dash 3 easy (such as Go thanks
to gofmt)
- except for projects I have no say in, where I respect the will
of the maintainers, because conventions among well-behaved
people matter more than my highly individual opinion.
† to which the usual answer is "but your editor sucks with lang X", well too bad, I'd rather have pragmatic editor portability than have perfect language parsing in every editor being a pipe dream I hinge upon.
It's not that "tabs for indentation, spaces for alignment" is a bad practice, it's that alignment itself is a bad practice. It doesn't help readability, it directly causes overly long lines of code (which pushes people to try to use narrow indentation to compensate), it's something you have to fiddle with every time you refactor a name, and it gives you spurious changes in your VCS diffs. (Yes, you can set any diff program to ignore whitespace changes, but I want to know when whitespace has changed.)
Gross, You purt 3 parameters are on two lines. Either indent none of them and keep it on one line or indent all of them. What are you doing, trying to hide "arguments"?
> I see this cited every time. Unfortunately, it's bogus in practice. Consider:
>
> print('some long thing',
> further, arguments)
>
> If this is an indented block, you'd have to indent the second line to the correct depth with tabs, then add exactly six spaces for alignment. You have to mix spaces and tabs, which is never good news.
One way to avoid this would be use a hanging indent. For example:
This is an example of where it's absolutely okay to mix tabs and spaces. If it's Python, that's not going to work, but depending on one's preferences and opinions that can be seen as a defect of the language, not the formatting. In C, C++, Java, Javascript, and nearly every other language, this is a great practice.
I agree in theory. Having seen terrible mixes of tabs and spaces, I don't agree in practice.
I've worked with several projects that painfully switched from tabs to spaces because tabs didn't work for them in practice, in a setting where several people work on one thing. I haven't seen projects go the other way. (Yes, automated formatting would solve part of thise.)
I feel it's a matter of style. I've resisted a long time, but then I've come to appreciate:
some_function_name('some long thing',
further, arguments)
Assuming a tab width of four, there is no problem with starting the second line with a tab. And the whole thing can be indented by tabs, as well (in which case the first line has N tabs and the second line has N+1 tabs).
The longer the function name, the better the advantage of indenting like this.
Spaces are only beneficial if you use styles with alignment. I dislike them: they sometimes look pretty, but they waste a ton of space on the left and don't work well in all situations.
Almost certainly none at all. Those of us who use proportional fonts simply don't try to do column alignment, because it would be a fool's errand.
In most situations, I consider column alignment to be detrimental to code maintainability. I actually stopped using it long before I switched to a proportional font.
When I later got curious about trying different fonts, I discovered to my surprise that the code looked just the same in a proportional font as it did in a monospaced font.
Regarding margins, if you mean indentation, that works the same in a proportional or monospaced font. The only thing that doesn't work well is the popular two-space indents. That ends up with very little visible indentation in a proportional font.
But to my eyes, two spaces isn't enough in a monospaced font either. It's just not enough spacing for me to see the code structure clearly. Four-space indents solve this problem; tabs solve it even better. When you use tabs, you don't have to argue about how many spaces to use.
I think these are related. Why do people want to use two-space indents? I believe it is often because their lines of code are getting too long. Why are the lines getting too long? Often that is because of the use of column alignment, especially with function arguments and the like.
If you stop using column alignment, your lines will naturally be shorter, and there is less reason to try to save horizontal space with narrow indents.
> The fact that Python's rule used to be 8 spaces, then got changed to 4 thereby invalidating old code really showed me how shortsighted it is to use a set number of spaces in a whitespace sensitive language.
Not sure what you're talking about here. In Python, as long as the indentation is consistent you could (e.g.) use 2-space indentation to make a code block. It's considered bad practice, and most linters will complain about it since 4-space indentation is the "golden rule."
If you're talking about the Python interpreter's interpretation of the tab character in indentation, that's different[1]. In any case, old code that has 8-space indentation using spaces rather than tabs is still good. The only issue would be old code that mixed tabs and spaces for indentation, which might not match up anymore to make correct code blocks. But, in general, it's just a bad idea to mix tabs and spaces for indentation.
[1] To the uninitiated, the Python interpreter treats a tab as X number of spaces when parsing the source code. This means that technically you could mix a block's indentation between tabs and a corresponding number of spaces. For example, if X = 4, then this code block would work:
The right solution here would be to treat a tab as exactly pi spaces. This, while not forbidding the use of tabs, would guarantee that any inconsistent mixture of tabs and spaces would be considered misaligned.
"I don't believe it's my position to enforce the amount of whitespace another developer has to use in their editor."
I suspect this might not be my most popular comment, but I honestly think that this is why tab users might actually make less than space users on average. On average, it's more productive to enforce things than leave everything configurable, thus different everywhere, thus harder to make sense of and debug. I knew brilliant people who don't want to "enforce" and decide and dim people who happily enforced and decided and it's always amazing how badly the former do career-wise relatively to their talent and effort, and how well the latter do relatively to theirs.
(Of course there might be another explanation for the data and I don't claim that my just so story is in any way scientific; though I think it should pass as a scientific theory in the social sciences.)
"""The fact that Python's rule used to be 8 spaces, then got changed to 4 thereby invalidating old code really showed me how shortsighted it is to use a set number of spaces in a whitespace sensitive language."""
When exactly did it use 8 spaces? I have been using Python since 1996 and I don't recall this 8-spaces thing. Almost all code I've seen uses 4 spaces.
In any case, it doesn't matter because, as another commenter pointed out, as long as your indentation is consistent, your code will work just fine, no matter how many spaces you use for indentation. Even if some code does use 8 spaces, it should work without problems. (Tabs as well, by the way... it's mixing tabs and spaces that is a problem.)
I may be misremembering since it has been a long time since I've used it, but I thought at one point Python treated one tab as equivalent to eight spaces.
First, my golden rule is "do whatever the other devs using the repo do" but
> People who use spaces want to line up their '=' signs, that's fine
To me this feels like it's a good use of spaces as well as tabs. Tabs for indentation, to get your nesting right. Spaces to align things. That way setting your tabs to X spaces works just fine and everything remains nicely aligned.
Though I'm not sure how common this is, so I just use spaces.
Mixing tabs and spaces is a nightmare, unless it is your personal non-open project. If a project is open or shared with anyone you need a simple rule to follow. There shouldn't be another leaf in the decision tree for when to use tabs or spaces. We have enough decisions to make the way it is.
> when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc.
This is an argument I hear often from tab proponents. What it misses out is the downside: my IDE has a certain arrangement on my screen, and I'll either have to invoke horizontal scrolling or I'll have a bunch of wasted space if you are using different size tabs from me. This is far from flexible.
There's also the (more minor) issue that you then can't line things up on a line below at an arbitrary place if the indentation of the two lines is to be different. This is admittedly less of an issue, but it does arise on the occasion one wants to structure text, for example in a table in a comment block.
I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere. But I'm not writing this to get into a holy war; only to point out that the "it adds flexibility" in your argument is a fallacy.
> Further, the only sensible screen width is 80 characters, since that also works everywhere.
I'm curious. Where does 80 characters not work now? How many people / industries are still using green-screen terminals with a fixed-width of 80 characters?
I'm generally in favour of enforcing line-wrapping requirements, because I've worked with people that would have a tendency to write code that trails off the end of the earth if you let them. But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done."
I realize that the 80-character limit is "everywhere"[1], but other than "it's everywhere" is there a more solid reason?
[1] When editing text emails in Vim the default textwidth value is 72, so that there is still some flex for quoting explicitly wrapped text (i.e. prepending "> " to the lines) and staying within the 80-character limit. The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters. etc...
80 character line wrapping is IMO more important on larger and wider-aspect ratio screens. Even the smallest 16:9 aspect ratio screen can be split into two columns, one being an 80 character column for code and the other left wide for a web browser or document viewer (this is now my setup when working on 16:9 aspect ratio laptops).
I see a lot of people work on large displays and with multi-monitor setups. Those who do not have their screens split into an 80-character or similar terminal and text editor width columns spend a lot of time switching between screens or applications. Couple this with the fact that you have to move your eyes around a lot on larger displays (and even head, in the case of multi-monitor set ups) and their setups actually make them navigate slower than they would on a smaller display.
> But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done."
Having shorter lines makes reading diffs easier (whether it's unified, context, or split diffs).
> The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters.
It's actually 72 characters for the commit message body for a similar reason that you mentioned for emails. Specifically, it's because the git log output indents the commit message relative to the diff (when using the -p option).
> Having shorter lines makes reading diffs easier (whether it's unified, context, or split diffs).
But is the difference that significant between 80-, 100- and (say) 120-characters wide? I personally wrap at 100 characters, I don't find that I'm fatigued by looking at diffs of the code.
It is subjective to some extent, but I do find that those who don't wrap their code at 80 characters aren't really particular in terms of wrapping their code at all. So most lines may be between 70 to 130 characters, but there may be the occasional line that's a bit longer.
Plus, it also depends on the tools one uses to review code. Github, for instance, will present a horizontal scroll bar for the unified diff view if there are lines that are too long. Using that scroll bar is not something I appreciate having to do when reviewing code.
Further, given that you're dealing with a language that uses significant indentation, you end up having to use stupid tricks that make your code less readable to stay under the bar.
Indented two levels (an 'if' block in a function in a class) and a couple of interpolated variables in an error message isn't unreasonable to have on a single line.
I know that it has to do with the width of older terminals, perhaps even back to the teletypes. But those hard restrictions don't exist anymore, yet some people treat "80 characters" as some golden law passed down from heaven that cannot be broken lest you incites the wrath of the gods. That kind of fervour (without some sort of concrete, logical reasoning) is nothing but cargo-cultism so far as I'm concerned. E.g. "we do it this way because it's always been done this way."
Just because it originates from teletypes that are no longer used doesn't mean that there's a problem with that width today. We need some standard, because otherwise you end up in formatting hell. There's nothing wrong with 80, so it might as well continue to be 80.
But the point of tabs is that you tell your editor how many spaces wide you want them to be, so unless I'm misunderstanding you, this is not an issue.
As for lining things up, tabs are used for the indentation level of the current line, but if you need to further nudge things within that line then you'd of course use spaces (after the initial tab indent).
Assume you want to eliminate horizontal scrolling. This is a valuable enough goal that a lot of coding style guides have a width guideline. That keeps everybody from having to make their editor windows as wide as the last person who worked on the code.
If this arrangement is working, nobody has to scroll horizontally, and there is no arms race of ever-wider editor windows.
Now introduce tabs into this situation. In theory I can set tabs to be whatever size I like. But in practice, I can't make them wider than the last person who worked on the code, because then I'm back to horizontal scrolling. Moreover, if I make them narrower, then they have to narrow their tabs to keep pace. So you get an arms race of tab- narrowing instead of window widening.
I just want to code. I don't want to scroll horizontally, or constantly mess with my window width and/or tab settings to avoid that. It's extra work that doesn't accomplish anything.
I am genuinely baffled (but I don't think I'm right and you're wrong... I trust HN people to be smart and capable). Can you please explain to me how using tabs vs spaces would encourage people to indent their code differently? I mean, if I have an "if" statement, then I indent my code -- but why would people indent their code for reasons other than what the flow of the code suggests? And if these hypothetical "indenting just because I can and not because I should" people exist, how would their inconsiderate behavior be any different whether they are using tabs or spaces?
I'm not talking about using a different style. I'm saying that different tab widths lead to different requirements for how many columns wide my window must be.
You misunderstand me. I can set my tab size different from yours, but doing that will change the horizontal window width required to view your code. This is the problem I'm describing.
> I'll either have to invoke horizontal scrolling or I'll have a bunch of wasted space if you are using different size tabs from me.
So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs.
>I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less).
Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running.
Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...
> So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs.
I think that the point was that if your IDE displays tabs as 8 spaces, and you read code written by someone that sets their IDE to display tabs as 2 spaces, then the line lengths will display longer in your IDE.
It "just works" when the writer has configured longer tabs than the reader, but not necessarily in the opposite direction.
> Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...
One example: enforced line-length limits. If you are wrapping at 80 characters with tabs set to 2-spaces, you will display a longer than 80 characters when viewing with tabs set to 8-spaces.
Then open another file, change the tab size again. Or start setting up macros/extensions/whatever to remember or auto-detect settings. This flexibility to have different developers view the same code with different tab widths comes at a cost. Many of those same developers would rather not keep paying the cost, and would prefer that code written by many people fit in their editor/IDE windows and look consistent without any special settings.
> Also, what do you mean "works"? The world doesn't
explode if
> you view a file with a different tab size than it
was created
> with. Again, kind of the point...
It does, as I demonstrate in my quote of you above. Try reading source code like that.
The only sensible way of reading source code is by viewing it with at the same overall window width in which the author wrote it. Viewing at a different tab size destroys this.
> Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running.
Except that I need to figure out the most appropriate tab size to use on a per-file-author basis if "variable tabs" were used, so this doesn't work because I get the problem as described above.
> I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere.
Ah, the old argumentum ad ubiquitam, which has saddled us with the x86 ISA, Unix kernels, and other brokenness we can never shake.
> The reason I use tabs is pretty simple. It's faster to move around only using the keyboard.
Well, yes, if you use the arrow keys (unmodded) and nothing else. But who does that? Even Notepad lets you jump from word to word with CTRL-left/CTRL-right. Sublime Text must have something similar, surely?
Beyond that, this tends to work across all input fields in your OS. If you're missing this you're missing out on being more efficient in any typing based activity.
- Ctrl, under some circumstances, lets you operate on parts of a camelCased or snake_cased word (with backspace and with shift + arrow keys, but not with arrow keys all by themselves)
It's the best setup for moving around code that I've encountered.
You are among friends, in your use of tabs and two-spacing at the end of sentences. There aren't many of us, and seemingly fewer every day, but we are a force.
Problem is that moving from and to the arrow keys to navigate is an anti-pattern that is not present in at least vim where you can stay on home row at all times, which is why I dread having to write in editors that don't support a vim mode.
Don Knuth seems to agree with you a bit; TeX automatically inserts some extra spacing between the end of a sentence and the beginning of the next one. You don't have to type it yourself though!
> It's faster to move around only using the keyboard.
There are faster ways, at least with JetBrains products, to navigate code that doesn't involve arrowing through spaces/tabs
The only reason I use spaces is the formatting is the same everywhere without messing with settings.
> Brace yourself: I use two spaces after the end of sentences too.
Me too! I was brought up this way. If you want to get into really sick and demented old habbits, my wife indents the first sentence of each paragrah... in emails lol
To me, moving around faster using only the keyboard is an editor feature.
My experience is with emacs but to go from the left margin to the first non-whitespace character across a vast swath of spaces in auto indent mode, I just press <tab> once. I'm sure other editors have something similar.
If you're iterating over the whitespace manually you are doing it the slow way :).
Don Knuth seems to agree with you a bit; TeX automatically inserts some extra spacing between the end of a sentence and the beginning of the next one. (But the extra space is less than one full inter-word space.) You don't have to type it yourself though!
You think you are doing others a favor by using tabs, but in fact you are creating a hassle instead. When I open your tabbed code the first thing I have to do is run it through some script that replaces all tabs with spaces, so that the files will be formatted the same way as the rest of the code base.
that would be the most logical explanation, but the article mentions that "The effect is smaller in Europe and especially large in India, but it does appear within each country, suggesting this isn’t the sole confounding factor." Which makes me think that there are other factors at play that add up.
Could well be. I know that Google for sure requires spaces, and some cursory Googling leads me to the believe that Facebook does as well. Does anyone have information on Amazon, Microsoft, Apple, etc.?
Of course, if all of the top companies are requiring spaces, then there's probably a reason for that, and its impact on salary data is thus meaningful, not just a spurious correlation.
It's sounding like all the top tech companies use space-based indentation. Our style guide makes some pretty convincing arguments as to why it's better. It sounds like good developers are either more likely to (a) work at top companies or (b) search out information on best practices for handling indentation. Mediocre developers probably just use whatever, which ends up being tabs a lot of the time.
Well, of course. Only companies with fuck-you money can afford the extra bytes spaces take up versus tabs, so it follows logically that they'd pay their developers more.
While your comment is obviously meant as a joke, it somehow rings true from my anecdotal experience.
I'd also like to see an analysis of space-vs-tabs as it relates to operating systems. Again, from anecdotal experience, it seems spaces are more common for folks with *nix background who tend to work in product-oriented companies (i.e. where code is an asset) and tabs are more common with windows folks, who tend to work on IT (i.e. where code is liability)
I've mostly only ever worked in Windows environments with the odd linux machine here and there, but mostly Windows, I've worked in both I.T. and product-oriented shops. I've mostly favored spaces. I've never been questioned it or asked to do differently. Generally speaking, those that care about the money, don't give a fuck about whether I use tabs or spaces. I've worked in tight-ass shops that have nickeled and dimed for every cent savings and I've worked for shops flush with cash to pay developers to do it right.
In my actual experience, I've never seen any relation to tabs vs. spaces with regards to being paid more. Nobody that has ever paid me for what I do has cared about which I use, nor have they questioned it.
One thing I have noticed in programmers are an asset vs. programmers are a liability is that companies who understand that automation is going to extend their profitability by more of a margin than it costs them will pay you what you're worth. Those that view programming as a sunk cost, that just makes their lives easier or cuts costs will pay you what they can get away with.
Don't work for a company that views you as a cost centre. Work for a company that views you as a profit centre. The work will be more meaningful. You will be more fulfilled. You will most likely be less stressed and you will most certainly be appreciated and respected more.
I'd like to add my own anecdote: Windows development primarily happens on one vendor's IDE - Microsoft Visual Studio, and where MS leads, Windows-based developer follow.
Case in point - I use the default Visual Studio settings which are spaces, BUT they weren't always. I remember as recently as 2008 tabs were the default.
Most of the time I've seen people refer to code as a liability, they aren't referring to the 'cost-center' mentality, but rather recognizing code is the liability you incur in order to get the business value [1], and thus you should minimize the code you write per solved business problem.
If you're a software developer and you're part of the "IT" department, then you're a liability. Your code is a necessary evil.
If you're not part of the "IT" department, then you're working in a product-oriented environment where the company is selling your code (either as a good or as a service) or otherwise making money from the code. In that case, your code is an asset.
I've always understood it as functionality is an asset and code is a liability. The company wants and uses the functionality to make money. Code has to be maintained, has bugs, etc. Your goal should be to provide the required functionality while reducing the costs incurred by your code.
You probably mean companies that are loaded or well-funded or stupidly rich. This isn't the same as fuck-you money, which refers to the amount of savings a person would need in order to retire early and thereby bid their employer goodbye. See for example: http://time.com/money/4187538/f-u-money-defined-how-much-cal...
I think that a rational sounding inerpretation can be found: all spaces means python programmer (mixing spaces and tabs messes up the indentation), python rulez, therefore high salary
Spaces over tabs is the default for IntelliJ. Given there are over ten million Java developers who are in very high demand, Python is practically a rounding error.
The article is serious. But I'm guessing there is either something subtle wrong in the analysis (they even find Go programmers who use spaces earn more, which makes no sense given that 99% of Go programmers use tabs), or it's some kind of weird selection bias, given that it the sample is self-selected.
It's pretty much an unwritten rule that a sarcastic joke on the internet with sufficient exposure will get a response by someone who didn't get it. Using /s really kills the fun (and whole point) of using sarcasm so it's a trade off to accept these comments will happen.
I'm impartial to downvoting as to reply literally doesn't usually add to the conversation, which is generally the point of downvoting. Losing karma shouldn't hurt your feelings.
If we called everything that was first described on Usenet as "Usenet's Law" then everything would be Usenet's law, probably even a couple of things in physics.
Do you mean partial to? As in, you favor downvoting over commenting to point out their mistake? Don't mean to be nitpicky, just genuinely confused if that was a mistake or I'm misunderstanding.
Yeah but we are human. Most people's feeling probably are hurt when their [non-malicious] comments are downvoted. But besides that I mostly agree with what you wrote.
I'm confused. Do you mean that we're allowed to create posts on Hacker News that are not sarcastic? I thought there was a rule, with a powerful AI enforcing it, stating that all posts had to be sarcastic. (Warning, this post is sarcastic and not meant to be taken literally.)
I've grown so tired of sarcasm. Online and in real life people are often saying the exact opposite of what they mean. We have to pick up the sarcasam to truly understand.
The real issue with sarcasm is that it actually places the burden of subtleness on the speaker, whereas people will usually blame the listener for not understanding. If the tone and wording isn't just about perfect, then it's obviously easy to miss sarcasm, let alone the humorous intent. And that is sometimes very hard in writing, hence the "/s" which ruins the fun for everybody. Likewise if the listener isn't educated about the object of sarcasm, little can s/he get the irony of the statement... I think missed sarcasm has more to do with failed cultural fit than fault of anyone involved. Which is probably why it's much more common and accepted within social circles than in general discussion. HN clearly fits the former, though; sarcasm is just about yet another norm here!
> HN clearly fits the former, though; sarcasm is just about yet another norm here!
Agreed, this is why I didn't want to take a hard position on downvoting someone for missing the sarcasm. We're in a public forum which crosses cultural boundaries. I see the argument for both sides.
Although I lean more towards downvoting as the majority of people on HN will get the joke and it's an opportunity to learn for those unfamiliar with the mainstream culture.
[tab]void some nice method(int param a,
[tab] int param b
So long as you only use tabs for indentation, not alignment, tabs look correct on _everyone's_ machine. The real problem with tabs is that (some) people are lazy and do stuff like this:
[tab]void some nice method(int param a,
[tab][tab][tab][space][space]int param b
Personally, I think if you work like that you need to learn to be professional and write code that follows whatever coding standard your organization uses. If they use tabs, the second example is _not_ following the coding standard.
So whether to prefer tabs or spaces, to me, depends entirely on how much you can/want to trust your coworkers to follow the coding standards.
Edit:
Or as pointed out below, change your coding style to this:
[tab]void some nice method(
[tab][tab]int param a,
[tab][tab]int param b
No I think grand parent comment means that some developers sometimes add spaces instead of tabs, even if it is by mistake.
That will mix everything up.
"Could" happen the other way too, but I think:
If you use spaces you typically dont repeatedly hit space to produce a single indent. You use tab which gets translated to spaces. Once the editor is set up for this, you don't accidently insert tabs for indentation.
The Linux codebase uses tabs, and presumably they have this rule about using spaces for alignment. I've seen tons of committed code that doesn't follow this rule, though, and hence Linux source looks like shit on anything besides 8 tab-width.
While this is true they will look correct on everyone's machine, they'll be annoyingly wide in tools that display tabs as 8 spaces (such as less, most online diff displays, etc). But spaces will look the same regardless of tool, editor, anything.
I don't know what online diff do you use, but less let you configure the tab stop with the -x option, which is the point of using tabs: being able to chose what's more readable for you.
The point of using spaces is to not worry about any of this. You need a specific fix for less, another specific fix for other diff tools, etc etc. With spaces, everything just works.
I don't see it as a "fix" but as a configuration. And tabs also just works, if you accept the defaults that are given to you :) but if you don't, then you can change your settings (which is trivial). With spaces you have no option but accept whatever is given to you.
The only reason 2, 4 or 8 is less "readable" to anyone is because they have a mental breakdown when they see a style they don't prefer and can't get past it. Tab is a variable width character, it has no place in text laid out with fixed-width fonts.
Those options are unambiguous and never require changes to a plain text file to work. I'm pretty sure it was Ayn Rand who said "A is A, but God only knows what Tab is." It's not always used for indentation, it might be for alignment, even if it's at the beginning of a line. There's no way to make any sane programmatic decisions base on it's presence. It does not belong in the digital world!
This is like an "eternal September" - when tabs vs spaces comes up each year, most commenters have never seen one of the rather simple ways of using tabs correctly.
I have visual whitespace turned on in all of my text editors. The massive amount of mixed tabs/spaces and trailing whitespace I find in virtually every document with multiple authors leads me to believe that I'm the only person on the planet who actually cares about whitespace at all.
If a system requires thought and care to be used properly then people will inevitably use it improperly. Even skilled, thoughtful people make mistakes or get fatigued and take shortcuts.
It seems to me that using tabs for indentation and spaces for alignment is a fragile technique. It's easy to make a mistake and not even notice. If you don't fix that mistake fast, people start to assume that maybe it's OK to ignore whitespace formatting issues. And so the problem compounds.
I would prefer to use a system that creates a "pit of success" so that even careless people have a hard time doing it wrong. I think sticking to just one whitespace character is better than mixed tabs and spaces, but best of all is using an editor that can automatically format your code.
What I didn't say in my original comment is that I don't actually do this for exactly the reason you describe, and that I think spaces-only is the most robust solution.
That said, all you would need is editors to enforce "any line with spaces before a non-whitespace character must have exactly the same number of tabs as the previous line." Which would not be all that difficult, but currently (afaik) does not exist.
Well, as long as everyone always use tabs, that should work out okay. But in practice, of course, it doesn't ever happen that way. Nice thing about a space is that it is always a space, a tab is however many spaces you personally want it to be.
> At first glance, this presentation style will seem ‘‘unnatural’’ to programmers accustomed to seeing
code in constant-width fonts. However, proportional-width fonts are generally regarded as better
than constant-width fonts for presentation of text. Using a proportional-width font also allows me
to present code with fewer illogical line breaks. Furthermore, my experiments show that most people
find the new style more readable after a short while
Great book, and I have used proportional fonts occasionally. It's much much better than you might imagine (as long as you are sane and use tabs for indentation). Obviously you can't get "perfect" alignment like you can with fixed-width fonts, but it is certainly nicer to read, so there is a trade-off.
People's opinions on that matter are always very strong and rarely... align (ba dum bump).
All-spaces lets the code look as-intended for everyone, and then their IDEs can let them hit the tab-key and get the look-and-feel they're after. It is the best option that gives the most freedom to everyone whilst also making us all play well together.
When I first started programming I had to share a single terminal with the rest of the school, so I wrote my programs on paper first. I used graph paper so that my handwriting would be monospaced.
see, i just think that's why grownups don't do that shit. you've got something that would normally be on one line but it's too long? indent once extra and don't be weird. there's no value in lining it up with the parenthesis.
I see a few arguments here which suggest people think tab-users might care less about their code and/or their fellow coder. As someone who slightly prefers tabs and abhors mixing of tabs/spaces, I find this frustrating.
I generally prefer tabs because I feel that they're more egalitarian: I like 4-space indentation, but don't want to force that on everyone encountering my code. Similarly, I find 2-space indentation very hard to parse in most languages, so I don't want that affecting me if I can get away with it. While this is possible with spaces and maybe a series of Git hooks, it's trivial with tabs.
On the other hand, I always use spaces in languages like Python or Ruby where there are well-codified style standards. I also always show invisible characters on any editor which allows it, and have cleanup scripts to ensure that whitespace is standardized across any non-vendor code in the project.
Maybe most tab users don't feel this way? Maybe most aren't as careful/picky as I am? Maybe tabs are more popular with younger devs? But I feel like tabs can offer more interoperability than spaces when many coders are working on the same project when the language/community doesn't strongly specify whitespace.
Using tabs has the opposite of your intended effect: If there is any text which is vertically aligned beyond the first indent, then this alignment will break for anyone who doesn't have your tab width preference. They're then forced to change their editor settings to view your file in a non-broken way. I get way more pissed about someone else "forcing their preferences on me" when this happens than when I run into a tidy, 2-space-indented file.
If you configure your editor to drop spaces when you hit 'tab', then the file is guaranteed to look the same for everyone, and stops being context-dependent-- a bad thing for plain text, IMO.
Your issue is why you see people say "tabs for indentation, spaces for alignment." If you're trying to vertically align text, use tabs to keep it at the same indentation as the thing you're aligning to, and use spaces to adjust to vertical alignment.
This will keep the vertical alignment regardless of the preferred width of the tab.
So for long lines to move an argument over to align with its predecessor on the previous line, like
int f() {
int someVariableName = myFunctionCall(expr(5), // <--- line A
somethingElse(9), // <--- line B
a_long * expression + involving(multiple.subExprs));
int d = somethingElse; // <-- line C
}
...you're saying line A is indented with tabs, and line B with spaces? Because that will misalign if your tab setting isn't the same.
Or are you saying that both A and B are indented with spaces? Then what about line C, which will misalign with A and B if your tab stop is a different width?
Or do we indent the entire body of f() with spaces, and then in that case you're basically using spaces everywhere, which the good idea that sparked this whole thing?
I think he's saying use tabs on lines A, B, and C up until the indentation level (the "int"). Then on line B use spaces for all the whitespace from there until the text is aligned.
/*t*/int f() {
/*tabs*/int someVariableName = myFunctionCall(expr(5), // <--- line A
/*tabs*//*--------------spaces--------------*/somethingElse(9), // <--- line B
/*tabs*//*--------------spaces--------------*/a_long * expression + involving(multiple.subExprs));
/*tabs*/int d = somethingElse; // <-- line C
/*t*/}
You indent line A with tabs. You use tabs to line the start of line B up with the start of line A (indentation) and then use spaces to move it the rest of the way to where you want it (alignment).
And as an aside, it's worth pointing out that most editors will handle the initial tab part automatically, so it's not like you have to do mental math to think "okay, this many tabs, and now switch to spaces". Just at the end of line A, you hit enter and start hammering the space bar.
I always see this brought and wonder, what are people vertically alogning, and why? I generally see vertical alignment as an anti-pattern that makes it harder to change code.
Indent with the tab key, let the editor replace it with spaces.
Soft tabs FTW.
(F#, where indentation matters, and Clojure using Parinfer where indentation matters to get the form placement correct both make tab characters horrible to use.)
This is another style thing, I think. When writing Objective-C I always use spaces because lining things up is idiomatic to the way the language is written. Same with Python which has well-codified style rules for many multi-line argument lists and the like. However, beyond that, I don't tend to line up assignments or anything else that has me doing indenting with spaces AND tabs, so (at least with my code) this doesn't end up being an issue.
If I was working on a project where there was a strong preference for indenting assignments, or any other case like this, I would use spaces throughout.
Indentation is literally a form of vertical alignment. And unless white space is significant in your chosen PL, all forms indentation/spacing serves no purpose. What does you code look like?
I think tab users are naive, misguided idealists rather than people who made a deliberate choice to screw over their fellow devs, sure. Tabs do indeed seem like they ought to be "more egalitarian" as you describe. It just doesn't work out that way in practice; it ends up more exclusionary because you wind up with a codebase that you can only work on if you have particular tabstops set up, rather than one that you can at least edit in any editor.
This is another style thing, I think. When writing Objective-C I always use spaces because lining things up is idiomatic to the language. Same with Python which has well-codified rules for many multi-line argument lists and the like. However, beyond that, I don't tend to line up assignments or anything else that has me doing "special indenting", so (at least with my code) this doesn't end up being an issue.
If I was working on a project where there was a strong preference for indenting assignments, or any other case like this, I would use spaces throughout.
You are clearly being thoughtful, but the problem with tabs and mixing them into code is that when multiple people write the code, some spaces are going to slip into that tab heaven, and then indentation will break for someone.
So by choosing tabs, either the file must be consistently formatted with tabs by everyone always, or everyone must look at the code in the same editor configured in the same way always.
I remember reading jwz's rant on this long time ago and not getting it until I had the first what-is-going-on-here moment due to wrong indentation from mixed tabs and spaces. jwz is right. Stop using tabs.
I'm honestly not that worked up about tabs/spaces, I just get frustrated when I see people assuming those indenting with tabs are careless or anti-social. I only indent with tabs on projects where I have control over the style standard.
About your argument, though:
Isn't is also possible for someone to copy/paste something with tabs into space-indented code? Isn't is also possible for someone's editor to start off with tab-based indentation by default instead of space-based and mistakenly add the wrong whitespace to the project?
My main reason for preferring spaces is that I have yet to work in any context where tabs occurred where it did not end up with mangled formatting sooner or later. Yes, often because it ended up being mixed with spaces, accidentally or intentionally, but nevertheless it seems to me to end with someone making a mess of it.
If everyone used tabs perfectly, I'd be fine with them...
Isn't is also possible for someone to copy/paste something with tabs into space-indented code? Isn't is also possible for someone's editor to start off with tab-based indentation by default instead of space-based and mistakenly add the wrong whitespace to the project?
As I've said in other parts of this thread, I'm not that worked up about tabs vs. spaces, and I use spaces most of the time. I just don't find this argument for space superiority very convincing.
PS: If everyone showed invisible characters in their editors, I think the world would be a better place.
A decent editor can be configured to convert those tabs to spaces on paste.
And if you stick to only spaces it is trivial to reject tab containing code in commit hooks. It's harder to reject code that uses spaces wrong in tab-indented code, unless you outlaw spaces for alignment too.
They mean like this, where `-` is tab and `.` is space:
--def myfunc(
---foobar = 1,
---...baz = 2
--)
(silly example, idk, you get what i mean)
No matter what size tab stops you use, the `=` will always line up vertically, because the tabs are only used for the indentation (nesting level), not the visual alignment.
It would be ironic to use tab characters as some kind of magnanimous concession to other developers' preferences while at the same time requiring them to drop their editor of choice.
I generally prefer tabs, but I don't use them when writing Python (which is most of my job these days). I'm also not all that hung up about it, so I started with "slightly".
Honestly, I'm not even that much of an idealist. I think using the same indentation style as the general community is important, so I use spaces most of the time day-to-day. My biggest point was: maybe we don't need to berate/assume things about others for having different preferences than us?
This does not mean that changing from tabs to spaces will increase ones income.
I would expect there simply is a confounding factor that the author did not look at. Maybe the info is not in the data.
I can imagine that the space/tab choice is related to the "upbringing" of the developer. Maybe which language or editor they used first in their life.
Or maybe it's related to culture. For example when using IRC, tabs are usually not used to communicate. Maybe that impacts the general choice of tabs/spaces.
Or maybe more sophisticated users tend to exchange the tab key for something else:
If you hit Tab in Notepad and hit save you get a file with tabs.
If you hit Tab in IntelliJ or a related IDE you get a file with spaces.
If you hit Tab in an older version of VS (the kind you'd expect in certain types of settings where high pay is not usually expected) you get tabs, but in newer versions you get spaces (with defaults)
I set tab to call auto-indent or the language formatter on the code. I literally hit tab once to insert whatever is the defined standard for the file. So my single tab key press inserts or removes exactly the right amount of white space.
It's a holdover from my emacs days; the one thing I could not give up from emacs...
But that just contributes to the gap, the kind of place that devotes time to things like shared editor configs is the kind of place with enough money (and interest) to contribute to development quality, and places like that probably pay more.
The average "sweatshop/devshop" developer probably doesn't even know/care about tabs vs spaces.
The first place I would look is size of dataset and correlation effects from multiple self-reporters working for the same company.
Big companies tend to pay more in the software industry. Big companies also tend to have standardized on tabs or spaces internally to simplify the problem of merging code across developer teams. So if you find out that, hypothetically, Amazon, Microsoft, Google, and Facebook have all standardized internally on spaces, that alone could account for the data.
Yes, but since it's a human situation, you can reverse the causality link. Imagine people use spaces for an underlying reason that gives them naturally a higher salary, like Harvard Legacy applicants are taught to use spaces, they don't become wealthy because they use spaces, but because their parents were wealthy. And wealthy people hire the kids of other wealthy people with big salaries. Clearly there is no space => big salary.
If you are not born in the nobility that uses spaces, but if at first contact the people in power see you using spaces they might assume you are born a noble, and lower their anti-commoner guard for you and you have a greater chance of entering the nobility without a proper title (don't forget to slam the door after you, nobility only works on exclusivity).
So there is a path for taking the implication completely backwards and still reaching the expected outcome.
It could work if the confounding factor is the one you described. But it would probably backfire if the confounding factor is which language you learned first.
Then forcing yourself to use spaces might reduce your productivity, your self-esteem and your mood.
Tab is usually three spaces, right? So if I hit the tab key, I'm getting three button presses for the price of one. So extrapolating from that, if I hit tab I can get my work done three times faster and get out of the office quicker. If I'm using space, it takes me three times longer, which makes the boss think I'm working three times harder and I get a pay raise. I'm always at the office before she is (to fill in all the spaces) and I'm at the office after she leaves (still jamming that space bar). Sure the guy who uses tab ships code faster, but it must be worse code because he obviously rushed through it.
It looks good that I'm such a hard worker. So I get paid more.
A quality analysis, but you're neglecting the wear on your space key. Managers tend to look askance at wasting capex, so I'd recommend taking that in to account.
If I had to guess, developers who pay more attention to corner cases and/or carefully consider the secondary and tertiary effects of a design choice will tend to choose spaces.
- "TABS WORK GREAT FOR ME" -> First-order effect
- "If someone else views this file with a different tab width preference, the indenting will match their preference" -> Secondary effect
- "If users' preferences can change the indenting of a file, then vertically aligned elements will align or misalign depending on who's viewing it and who wrote it." -> Tertiary effect.
- "Randomly broken formatting and/or forcing users to constantly change their personal tab preferences is a bad way to work with code" -> Quaternery effect, etc.
In other words, a whole-system view that accounts for interactions with other decisions might lead you toward using spaces, while an immediate "local" view might lead you to choose the thing that seems most convenient right now.
It may also hint at the years & depth of experience & skillset.
Those who grew up in a shell often ended up building a much more diverse set of skills, the commonality of which is a lot of text based files with a favourite editor.
This extended to using tools like IntelliJ, Eclipse, etc.
Hope a follow up of this study can include the IDE's and if that has some say in this.
This is already accounted for in the article, the data seems to indicate this even in the same language, and consistently does so across all languages.
The effect in the data (unless it isn't random fluctuation. At the moment I'd go with the assumtion that it is a genuine correlation, as the effect is present over all subgroups), might (1) not be monocausal, i.e. a combination of contributing factors like development experience, age of IDEs/tooling, etc. might play a role as well as other aspects. (2) a cause might not be "explained away" because the control variable was considered. Let me elaborate
The years of experience variable might be taken to explain away the effect of experience, and then conclude that tabs vs. spaces must be due to another effect than years of experience. But chances are, that "years of experience" and "tabs vs. spaces" are just correlated to a common, causal property (like "programming proficiency" or however you want to call it). Both "years of experience" and "tabs vs. spaces" are then just incomplete reflections of the underlying cause, both rendering the effect of the underlying cause incompletely.
What I am trying to say is: Its complicated, probably you won't be able to find the one true cause for the effect in the data. If this were physics, one could come up with a predictive theory to put this to the test. In social studies, we just cannot control the parameters well enough.
If you are interested in reading more on this, "Causality" by Judea Pearl is a good (but exhausting read).
Pretty simple: you use spaces because you're aware that there is more than one IDE/editor in this world and who knows what your code will get opened with tomorrow.
This means you consider consequences beyond "but it works on my machine" so you're a better programmer. Ergo, higher salary.
Almost everyone I know who uses spaces or tabs does so because that's either the default on their IDE, or for their language. So this holier-than-thou argument holds less water than the sun.
On the other hand, I find 2-space-indented code unreadable; in fact, 4-space wide indentation is the only size I find to be readable. I know plenty of people for whom that isn't the case. Using tabs lets the reader set the indentation level.
¯\_(ツ)_/¯
Edit: All the anti-tab arguments I'm reading below boil down to alignment. Don't align folks; there's good reasons not to align regardless of your indent style.
Any coding standard that relies on humans to do something right is going to fail. Tabs might work if there was a way to automatically enforce no alignment and no use of spaces. But I've never seen any organization actually do that.
> But I've never seen any organization actually do that.
You haven't looked very far! Most open source projects these days enforce code style through some forms of tooling.
But saying that "Any coding standard that relies on humans to do something right is going to fail" is basically giving up and saying "do whatever". I mean, why even ask people to indent consistently if it's doomed to fail? It's a mixed indent party for everybody!
With the spread of autoformatters which automatically format or reformat your code, I don't even know or care what kind of indentation I use anymore. In all the languages I use, it's out of my hands.
Actually they all boil down to 'someone else, or another IDE that you haven't configured just right, will mess your tabs and make the code hard to read' :)
They're fine for solo projects i guess, if you only ever use one editor.
Edit: Also, in the long run the best thing you can do to your code is to make it easily readable. You will forget what you did. Not to mention your colleagues that have never seen it. So time spent aligning parameters to make code more readable is well spent, if you ask me.
Let the lines get long enough and the latter is actually quite a bit harder to read; try to follow the variable all the way to its value and you might actually jump and be one line off.
I deeply care about readability and code style, that's why I'm replying here :) And in all the codebases I have read and written, alignment has consistently been harmful to readability and maintenance.
I've always found the second much easier to read, especially when there are multiple levels of nested expressions, and it's a style that has been encouraged on every project I've worked on.
I agree that aligning '=' is actively harmful in the example you give, and that it's harmful in most situations where it's used. I've encountered very rare instances where it's helpful, though. Sometimes you have a sequence of values defined by expressions that follow a pattern:
enum someEnum {
FIRST = BASE + MASK & (1 << 0),
SECOND_VALUE = BASE + MASK & (1 << 1),
TH = BASE + MASK & (1 << 2)
}
Aligning the expressions can make it more clear what the pattern is and how it differs from value to value:
enum someEnum {
FIRST = BASE + MASK & (1 << 0),
SECOND_VALUE = BASE + MASK & (1 << 1),
TH = BASE + MASK & (1 << 2)
}
Often there are other ways to handle the issue, such as hiding the expression behind a macro or a function call; when that's more readable, that's the way to go. But in cases where writing the expression explicitly ends up being more readable, I find alignment to generally be a win in this case.
In fact, tabs are better for compatibility: other people might like other indentation sizes. If you keep your stuff consistently with tabs, and use spaces for alignment instead of having your IDE auto-replace tabs there as well, your code will look great with whatever tab size someone chooses. And extra pro: in dumb editors, you automatically get the right thing.
I have never seen this work correctly in practice, where a code base with tabs looks "OK" when opened on an editor with a different tab width. E.g. some coding styles will have subsequent lines line up (like multiline method params), and everything looks horrible with a different tab width.
If anyone can post a sizable production code base that uses tabs that DOESN'T look like shit with a different tab width, I'm certainly open to being proven wrong.
Here and there's the problem. Too many people with editors that go round replacing N spaces with tabs everywhere to have sane alignment in a code base with >1 developer...
I do it myself but it requires a bit of maintenance and I wouldn't trust teammates with it. There will always be some guys who don't understand the idea and mess everything up.
In a team environment, now, I wouldn't chose anything but 4 spaces. Speaking from experience.
- with anything but 2, 4 or 8 spaces, some guys with incorrectly set up editors will mess everything up.
- tabs don't work well for alignment, and as long as you allow the tab character, someone will make a mess.
- 2 spaces is not enough to properly distinguish between blocks.
- 8 spaces can look very nice if your code is very clean. It won't be the case of your project.
This feels like a partial proxy question for Unix versus non-Unix development. Unix developers are, in my experience, consistently more interested in configuring their IDEs, which underlies many of the arguments for tabs over spaces.
unless you have anything aligned in columns then all bets are off (something which many code formatters can do automatically for you e.g. lists of bindings)
Tabs for indentation; spaces for alignment; I don't know why you'd want to insert tabs in the middle of a line.
Also, most people who do have several years of experience under their belt will tell you: don't align. Mid-line alignment is a waste of a maintainer's time to have to update alignment blocks every time you add/remove variables... and statement-alignment is unreadable[1].
I do find properly aligned code easier to read in general, I'm not willing to give that up.
The crux of the issue is poor tooling. Aligning correctly is a pain because most editors suck terribly at it. For instance neither emacs nor vim align correctly when using tabs by default (they use as many tabs as they can and then pad using spaces, instead of indenting only with tabs and aligning only with spaces). If they did it would be painless to indent and re-indent.
When some of the most venerable code editors out there can't even seem to get it right I think there's no point in fighting it. Learn to stop worrying and love the space, I know I did. Or alternatively use a language like go which provides a standard tool to indent everything, make it mandatory pre-commit and never look back.
Yeah; the correct answer to a good codestyle is good tooling; high quality automated tooling. Things like gofmt and prettier are excellent. yapf and clang-format are also pretty good, but need a lot of set up.
But I never found a single editor that handles spaces correctly. I currently use vscode with vim bindings and whenever I deal with a space-indented codebase I want to tear my hair out: I inconsistently have to hit backspace sometimes once, sometimes multiple times to get rid of an indent level in insert mode. And don't get me started with yaml, a really painful experience to edit it.
Can't vscode automatically remove an entire indentation level with a single backspace? Many editors can do that, maybe with a non-default setting, but regardless.
On a large code base with multiple committers, I've never seen this rule followed consistently. In fact, I think this shows a poor engineering decision: "Let's make a rule where everything looks OK 95% of the time, except when you change tab widths (which is, presumably, why we made the rule in the first place.)"
I often run into trouble with IDEs that think they are smart, but aren't. "I see you have a space following a tab, so I will replace all your spaces with a tab, whenever you save the file"
Forcing people to remember relatively minor things is a poor use of headspace. Enforce a code formatter/linter, make the test suite success dependent on it, and never argue again.
The alignment in that link is laughable. Please use newlines and an extra indentation level.
I believe older versions of Xcode did that by default with objc (maybe still; didn't check lately) if you press enter in the middle of a function argument list. Really annoying.
If it fails, then you have not understood and you are not using your tools correctly. If your alignment depends on tab width, then you are not using tabs for indentation and spaces for alignment, you are using tabs for indentation and alignment and spaces for alignment, which of course breaks when you change your tab width.
Ah, I see what you mean. I've never seen an editor work this way, normally they just swap spaces with tabs, leaving however many spaces can't be swapped. Which is probably why I've never seen tabbed code in the real world that doesn't look like utter garbage.
This was definitely a problem back in the day, but I think most popular editors do the right thing now. And like you say, alignment is usually a waste of time anyways.
Myself, working on an old open source project, I just don't care. Match the nearby style best you can, use your own style on new code, who cares, get on with your work.
What kind of a dick opens up a tabbed project and starts inserting spaces? Even if you have a preference the other way you play nice with others and stick with the project conventions.
The other thing you need to do is stop people from checking in code that doesn't follow project conventions.
Secondly, I've got hard coded tab width on my desktop with a huge screen vs my laptop with a smaller screen, and this works for all editors, including my primary editors Atom and vim.
Finally, I've played around with using responsive CSS within Atom, but due to recent changes in the text rendering my current CSS doesn't appear to be working.
It's courteous except to those that don't like tabs, so you really can't win.
Many languages have a coding style preference. Go is super opinionated, Python in the middle, with C being as conflicted as it gets. Whatever you use, follow the style the language or team is a proponent of.
^^^ Exactly. Using tabs is a decent (albeit not perfect) indicator that you've never worked under source control on a large dev team with diverse working habits.
I think there's probably some truth to considering existing norms and thinking ahead, but find it unlikely to be the main confounder. How do tabs fail to work in other editors/IDEs?
They might be configured differently, and you usually can't align stuff properly using just tabs, you have to use a space or three somewhere. Also, you never know if it's spaces, tabs or a combination of them in existing code - which you may have not written yourself.
So in the long run, the indentation WILL get fucked up and you WILL miss something when fixing a bug in code that you or someone else wrote 6 months ago. And your 10 minute bug fix will take 3 hours. Multiply both values by a constant factor as necessary.
>you usually can't align stuff properly using just tabs
Huh? Things indented to 1 tab will align with everything else on 1 tab. Things aligned to 2 will align with everything else at 2 tabs.
>you have to use a space or three somewhere
Why? Tabs will indent with other tabs.
>you never know if it's spaces, tabs or a combination of them in existing code
Well they should never be combined for indentation. Unless you mean using tabs for indentation and spaces for alignment, but this wouldn't create any issues. Using tabs for spacing is objectively poor form.
I open space- and tab-indented files in my IDE, they are all converted to tabs. It is always consistent.
I don't think the answers here really make a clear case that tabs are the cause of the IDE/editor problems. People intentionally introducing incompatibilities (mixing tabs & spaces, setting their editor to convert) seem to tbe cause. And that would apply regardless of the initial choice.
Additionnaly diff/merge tool tend to be inconsistent. So it looks good on your editor, but when I am doing your code review, alignement is totally broken. In theory, it should be easy enough to ask people to have consistent settings across all tools, but it is a bit like herding cats. Sadly most people do not even realize it could look differently without their settings. (I could ignore whitespaces when doing reviews but this is an open invitation to break everything)
Seriously? When you start on a project you configure your IDE to match the project's conventions. If you are in a mentoring role you instruct your jr developers to do the same, first thing, before writing any code. This has never been an issue at any place I ever worked. If a PM can't get their developers to do something as simple as that then you have larger organization problems than code formatted weirdly. As well as totally incompetent developers.
On a very large codebase, developed over decades, not months or years, by thousands of individual teams, using multiple versions of multiple IDE's, some of which didn't exist when the project started, across different languages, also some of which didn't exist when the project started, this is not so simple.
I've worked on projects that have been developed over decades and there has never been an issue. We have conventions, developers are expected to follow conventions, and if they don't they are instructed go back and fix their code.
That's exactly my experience, too. Developers who use default settings and tools are less interested in computers. Knowing the details of a system makes a developer infinitely more valuable.
Anything less than 16 is literally blasphemy, in the modern world everyone is using 4k 32:9 monitors and for the best level of readability heavy indentation may as well be mandatory.
Yea, I'm honestly surprised this is a thing still. I've not thought about the tab vs spaces "war" in years; because of Vim. I just hit Tab and whatever the pre-defined standard is, be it tabs or spaces and space count, is used.
Visually I can have it display in my editor of choice (Kakoune at the moment) however I want.
I guess I'm just saying, I would have thought the most common answer to this question would be: Whatever my employer / language standards dictate.
I blame whoever decided to make 8 spaces the default tab width on older systems. Yes, the beauty of tabs is that you can change the defaults and make one tab show up as whatever you want, but most people don't change the defaults. And 8 spaces is just too much more often than not.
> A common horizontal tab size of eight characters evolved, despite five characters being half an inch and the typical paragraph indentation of the time, because as a power of two it was easier to calculate in binary for the limited digital electronics available.
Why someone decided to round up to 8 instead of down to a much more sensible 4 spaces is beyond me.
A possibility I haven't seen mentioned is that the style guide of their employer, together with a few employers who pay out-sized salaries (Google, Amazon, Facebook...) could account for the difference.
Yes, the only reason to use spaces is because you are forced to because you work in an organisation that had to force this rule because it employs too many morons who cannot make the difference between indentation and alignment.
* Large organisation -> pays more.
* Organisation that has power to enforce coding style rules -> pays more.
The most confusing thing about this result is that go shows a high level of space-preferential salary difference. Go programmers who use spaces make ~20k more (at the median) than developers who don't.
Only, in Go, you don't have a choice -- gofmt enforces tabs only (with spaces for alignment). So something seems odd there.
I'm pretty sure the spaces-vs-tabs question was not language-specific, which means that the interpretation was more like "in languages that do not enforce a specific style, which do you prefer, tabs or spaces".
This! It makes me really suspicious about the data.
Are there any highly-paid Go programmers who refuse to use gofmt? That's a serious amount of effort to go to in order to make your code non-standard. Your projects will be criticised and you'll get PR's to correct them for just that reason alone.
If there are no highly-paid Go programmers who use spaces, and it seems utterly reasonable to assume that there are not since the language itself enforces tabs, then who exactly are they talking about in the data?
Without doing too much investigation: That would be resolved if (1) participants were allowed to select more than one language and (2) Google is over-represented as an employer of participants who selected Go.
Might also be that the space people, being irritatingly pedantic also include bonuses and/or stock compensation , while the tab people, always lazy and all over the place, just barfed the first number that came to mind.
The answer, as always, is: lisp with parinfer - makes the whole debate irrelevant.
If you're in the JS world check out https://github.com/prettier/prettier if you haven't. It's used by some big projects like React, Babel, webpack etc.
Unlike "traditional" formatters, it parses your code into a syntax tree completely disregarding any original formatting, meaning the output is entirely consistent. It's pretty liberating to devote zero time to manually formatting and can make code reviews more constructive and less superficial. It is what is is, and it's pretty opinionated based on Facebook's code style. Works great for us, enforced with a git hook.
I needed a good laugh this morning. But of course this is pretty bogus relationship. People who drive Teslas make more money than those who drive Gremlins.
But there's an actual causation here (you need more money to buy a Tesla). Use of tabs and salary don't seem to have any relation one way or an other.
My personal guess would be that using spaces is a practical decision and might be more popular towards older, more experienced devs (who are therefore better paid).
On paper tabs sounds better, they're "configurable", you should indent with tabs and align with spaces, yada yada and everything is good in the world.
In practice however it becomes a big mess real quick unless you only work on projects with very good and perfectionist developers who understand when they should indent and when they should align and how they should configure their editors to do the right thing. See for instance the linux kernel codebase, it looks like arse if you don't use 8-space tabs and the coding style even tells you to use that value (it shouldn't really matter if tabs were used "right", except maybe for 80-column limits). So why even bother with tabs in this situation? Do we really care that much about wasting a few bytes?
Therefore I gave up on tabs a long time ago and tell everybody to just use spaces in all the projects I maintain.
> My personal guess would be that using spaces is a practical decision and might be more popular towards older, more experienced devs (who are therefore better paid).
They explicitly rejected this explanation after controlling for years of experience.
That being said I'd be curious to see "years of experience working in a team", because that's really when using tabs starts becoming tricky. If you're well disciplined and are the only person messing with your codebase the issues I mentioned in my previous post don't really apply.
There could be a third factor of conscientiousness that causes both high salary and use of spaces (to align your code just right). At least I will be using that excuse now when I spend time aligning function parameters in table columns.
I believe the correct answer to that interview question would be "Follow the code style as established by the company, or keep it consistent within existing projects."
If you use tabs, you work for a small team (or by yourself),. If you use spaces, it's because you're in a "big enough to stop trusting everyone" environment.
I use spaces because literally every single time I've tried to propose tabs I get yelled at by someone... I generally prefer tabs, but I prefer having coworkers that don't complain more.
Heh, you kids with your spaces and tabs. Real old-schoolers think in terms of columns 1-5 for the label, 6 for the continuation marker, 7-72 for the code, and 73-80 for the change number.
I've been using prettier.js in my JS projects for a few months and honestly I can't imagine going back to formatting my own code. It would be like making all of my own clothes or something. Who has time for that?
The Go community was on to something with gofmt (even if they did decide on tabs).
No, whitespace-sensitive languages are still generally the exception (except newlines). In fact I can't think of a new language that is vaguely popular and whitespace sensitive since Python. I guess there is YAML but that isn't a programming language and is also a bit mental.
Ok, here's a question I've been wanting to ask someone steeped in syntactic-whitespace languages. Do you find that two developers typing the same code will format it the same way? How much would an auto-formatter change in your team's code?
There has been a bit of friction on that very point...Now we just agree on "four spaces all over the place".
I know for a fact that an auto-formatter like `gofmt` or something would have avoided at least one argument, so it would probably would make the code better in some respects.
That said, I like the whitespace. I like that it forces you to think about how the code is formatted and it tends to make the code a lot less verbose.
"Indent with tabs, align with spaces" (e.g. [1]) would be my strong preference in a perfect world. In addition to its "ethereal" benefits, some languages which support HEREDOCs have nice "tab ignoring" versions (e.g. <<-).
That said, in the imperfect world we live in, I always use spaces. "Indent with tabs, align with spaces" is obviously not rocket science, but its just too opaque unless you have a strong code review process.
I think people got it backwards. Brace yourselves. You don't earn less money because you use tabs, but instead you use spaces because you earn more money.
When I was working on my own small projects I was using tabs, or tabs combined with spaces, which yielded me not a lot of money.
Once I started working for a big corporation, the coding standards mandated by the company meant I could only use spaces, because people couldn't be trusted to use a nice space/tab combination.
Somehow it doesn't surprise me that much. Software development is ridden with fads that fastidious, obsessive developers make a point of adopting enthusiastically (they used to call them "best practices" until somebody even more fussy came and suggested to call them just "good practices", because "no practice can be universally best").
These people have a particular gusto in constantly one-upping each other with the latest good practice; the one that adopts the highest number of good practices wins. Their constant talk of the latest fad and push for the "right ways" of doing things usually puts them in positions where they end up evaluating and hiring new developers (I got interviewed just the other day by somebody that didn't ask me to design or structure any code, but rather if I use == or ===).
Some of these are actually excellent developers nonetheless; others will drive entire teams into rewriting a perfectly working application into a completely useless mess of a thousand microservices. Endeavour that will end up in their CV anyway, helping them to find another excellently paid job once it's time to migrate.
We are suffering from space exhaustion. Experienced older programmers known earning more were able to gobble up spaces way back while they were still cheap and are now enjoying spreading them around. Younger coders on a budget have to be stingy with spaces and are forced to use the poor tab substitute. This leaves the less experience professionals at the mercy of tab expansion by greybeard hackers. Sad.
When you're working in a large company with many developers spaces make more sense. Large companies generally pay more.
In a perfect world you'd use tabs for semantic indentation and spaces for stylistic indentation but this is too hard to implement in 100+ person teams and also can't be automated via an IDE style sheet.
So are we really saying software developers who follow style guides earn more? That doesn't surprise me. Adhering to guidelines is a good way to work well on teams and thus become a more valuable team member.
What I learned from the last chart is that Clojure devs earn the most money regardless of whether they use spaces or tabs.
Being an Elixir programmer also pays off nicely but for heaven's sake don't use tabs unless you want to earn only half as much as you could if you used spaces.
This may or may not be true, but just FYI the salaries were an optional part of the survey so those people may have chosen not to give their salary for some reason or another.
I think the implementation is that those who are high earner don't have time/desire to participate in SO surveys, not that they are unlikely to state their income in SO surveys.
Not the be the voice of reason in a sea of crazy; but this is just stupid. correlation != causation - making an assumption on pay rate vs who uses tabs and who uses spaces makes my brain hurt thinking about what moron approved this article.
Set the tab stop to what ever your project/team style guides requires. Tabs to spaces is just plain stupid. Why on earth would you ignore the x09 character, a single character that exists for this exact reason, and replace it with multiple x20 in the file. Just set your tab stop to what you like to look at, be it 2, 4, or 42 characters. By the way the default is 4 characters for most editors/IDE's.
vim - :set tabstop=4
vscode - to your settings add the following. "editor.tabSize": 4
The difference between the salaries of tab-users vs. space-users in David's report are too close to call, so I added bootstrapped 95% confidence intervals for the aggregate median salaries (which was easy to do since the code was open source): https://twitter.com/minimaxir/status/875386185350168577
If the 95% confidence intervals for tabs and the 95% confidence intervals for spaces intersect at a point, there is a possibility for failing to reject the hypothesis that the difference between the two is nonzero at the alpha = 0.05 level. Since there is little overlap in most cases, the original hypothesis holds.
Amen, brother! Unfortunately, like fair taxes, truly representative democracy, and peace in the middle east, this is probably an idea that's doomed to be forever ahead of its time.
I'm Dutch. We say "gif" with the hard Dutch "g" (yea I'm sure I'm speaking for all of us, shut up).
The point is that, unlike the English "dzj" (jif) or "gh" sounds, you can pronounce a Dutch hard "g" for as long as you want to. And therefore make it louder. And therefore we will win this argument:
Come on, we've known this for years. Do we really need a study to tell us that? Hell, the only interview question I've asked new hirees since around 2003 is: "do you indent with spaces or tabs". Really cuts through the BS. It's foolproof!
With this, I instantly conform to how the file is formatted. Is it 3 space indentation, made with a mixture of 8-tabs and spaces? Autotab will figure it out, spit out the Vim params, and you're modifying away without causing spurious diffs in version control.
You have to learn to use Ctrl-T for indent and Ctrl-D for deindent in Vim; those obey the shiftwidth and generate indentation according to the shiftwidth, tabsize and expandtab setting.
On IBM mainframe terminals (327X) tabs were used for moving between entry fields. So it is/was basically impossible to use tabs in text for formatting. I'm not even sure if EBCDIC has tabs?
I don't really care that much, Go says tabs so whatever. But spaces have the benefit (or drawback to some) of rendering exactly the same way for everyone (assuming fixed width fonts, does anyone code with proportional fonts?). Also I've always got two thumbs on the space bar. And it's much bigger than the tab key.
Well, in a team with a bunch of programmers each with their own preferences is kind of tedious to talk and enforce a single formatting standard...
So, I just make sure a small script runs
#astyle -A2SKnjfUHpk1cn -R .h .cpp
before their commits .. and it made my diff look much nicer.. I don't really discuss tabs or spaces anymore..
I never thought that such styling would really matter much ... I wonder how much a developer using a beautifier earns in average..
Anyhow, statistics sometimes brings up some weird conclusions.
Doesnt using spaces to indent code waste a lot of time? I mean sure if you're only indenting once, it takes a few extra key presses to make 1 tab worth of space bar clicks but if your code gets really deep, then you're talking about wasting a lot of time hitting the space bar key per indent PER line...each subsequent line of indented code doubles the amount of space bar clicks...
Am i missing something here? this sounds really dumb, as tabs make the most sense, and it appears use less memory as well.
They can bill for that extra keypress time. Makes sense. Tab developers deliver projects on-time and under-budget. Space Developers over-charge, deliver late, but make more money. ;-)
As someone who switched preferences: i used to hate tabs
Then somebody asked me why. The answer was that Sun Solaris was a crappy operating system which would fail to boot if you used tabs in files like /etc/vfstab.
For some odd reason, I carried around a weird bias about tabs rather than regarding Sun as being shitty.
I worked somewhere where a bunch of folks preferred four spaces (because they came from Python), others two (because they came from JS). Use tabs, set your preferred tab size, boom, everyone gets along.
I wish editors handled indentation preferences intelligently. I prefer my indentations to appear 2-columns wide. I want to be able to open my editor, have everything appear as if it is 2-column-tab-indented while I work on it, but have it automatically written back to use the original indentation scheme of the file. Obviously there would be some ambiguous cases, which is acceptable.
I use vim with vim-sleuth now. If anybody knows how I can achieve what I described above in vim, please tell me how.
In the past ten years I have had 7 different development positions (and a few IT positions), I have never been at a place that used tabs. Ruby, C, C++, php, C#, SQL were the languages used and there positions were scattered across medical, Retail/Wholesale, Government/DoD.
That someone with this many different types of experience can have accidentally avoided encountering whole class of people and their code, really puts into perspective how small the experience of any 1 person is.
Why didn't he test by age? Age is likely the variable most linked to salary. Older developers didn't use fancy IDEs- just a simple text editor is all you really need.
I don't understand how people can work with spaces. I had to reformat a colleague's query the other day and it was infuriating because all the tabs had somehow been converted to spaces. I had to edit it line by line instead of being able to easily shift entire blocks in either direction.
Do Visual Studio and SSMS support the space equivalent of "Select X rows and tab them all at once"? I just tried now and all the code is wiped out, replaced by a single space.
Visual Studio supports column-based selection using Alt+Shift with up/down arrows or the mouse to select a column, so you can add any number of spaces or any other text on all of the rows at once. I'd assume SSMS is the same, since it's based on VS.
But that's still not a good reason to use spaces (especially 2 spaces) and say "FU" to programmers suffering from diplopia.
In terms of potential explanatory covariates, I think preferred editor/IDE would be one of the most likely to explain the trend, since different editors will have different defaults. The survey has this information, so someone could test this. It would probably help to group the editors by their default setting. I think you might need a mixed model with editor as a random effect to include both default setting and preferred editor in the same model.
In case people aren't aware of it (I only found it recently), check out EditorConfig: http://editorconfig.org
It lets you check in an .editorconfig file that specifies whether your project uses spaces or tabs. And a bunch of editors and IDEs already have built-in support for it!
Doesn't solve the holy wars, but it can sure help reduce the friction.
"There were 28,657 survey respondents who provided an answer to tabs versus spaces and who considered themselves a professional developer (as opposed to a student or former programmer). Within this group, 40.7% use tabs and 41.8% use spaces"
Without filtering to the 'professional developers', meaning overall, there are more tab users (32% vs. 28%).
It looks like they didn't correct for multiple comparisons. Given the number of questions on the survey, there was bound to be at least one surprising correlation that looks significant without correction.
(Am I wrong? I would hope a Data Scientist would know a basic thing like this, but I don't know R so I can't tell for sure from their code.)
That doesn't seem like a mystery to me. The argument in favor of tabs boils down to "tab damage won't happen". The argument in favor of spaces boils down to "tab damage will happen". I know which of those two philosophies I would prefer to have in charge of important things.
As a spaces user, I have to acknowledge that I get irritated when I open a document with tabs and the formatting is messed up thanks to tab setting mismatches.
Is it possible that tab-aversive people making hiring decisions act on their aversions (consciously or unconsciously), while tab-friendly hiring managers do not?
Can you explain that? I can't see how different tab settings would mess up formatting. Unless you use tabs to match the position of things over two different lines (which is abusing tabs), or mix spaces and tabs, tabs should work fine.
I strictly use spaces for indentation (and alignment never) but I don't hate on tabs, they have a right to live in my code. So I like to sometimes place a sprinkle of 2 or 3 tabs at the end of lines where no one will notice them probably anyway.
If you have rules about formatting that should be part of automated formatting for the code which should be part of the standard (hopefully automated) check-in process.
A tab and a space have different semantics. Don't dumb things down, please! In Bash, for example, you need tabs for indented heredocs to avoid redundant leading spaces, which could be problematic in some cases - that's why I always use tabs with Bash.
I believe the tool 'indent' was created in part to end this "holy war". I just checked my system (a relatively new LinuxMint install) and found that 'indent' is not installed by default, but it is in the repo.
This sounds like self selection bias. Only 12k of 28k respondents included their income. If you decrease a sample artificially then the resulting statistics are all suspect. (I stopped reading once I saw the attrition rate)
I know nobody wants to hear this, but developers in the U.S. are overpaid compared to their peers in the rest of the world. We should count our blessings.
In UK best developers work as contractors and make on par with US peers. This is not accounted for in most data as they look at permanent job salaries in UK which are very low.
The number of respondents who included salary is almost half of the overall sample size. So it could just be that developers who use tabs make more and are less likely to hand out their salary.
The tab character, ASCII code 9, should not appear in source code. What happens when you press the tab key to make the proper number of spaces appear is between you and your editor.
I'm guessing developers with more relatives on the Autism spectrum prefer spaces to get exactly the look they like, and are better (more picayune) programmers.
Correlation is not equal Causation. How in the hell are people taking this seriously? Also there is no reason given in the article to explain why it is so.
This is because people who use spaces have to use Stack Overflow more often, so there were more developers who use spaces when SO did their 2017 survey.
Many of those who answered tabs are actually using an IDE which inserts spaces when they push tab. They believe they are using tabs, because they've never realized that this is going on. People under that misapprehrension are likely to be less skilled.
Additionally, if a coder, is in fact, deliberately choosing the use tabs, they are going against the majority opion of coders and almost all style guides. That attitude might be correlated with lesser income.
We need laws to settle this issue once and for all. Even disregarding how boring these Internet disputes are, we can no longer ignore the fact that all these coding style guides, whitespace normalization patches and python bugs caused by mixing tabs with spaces are costing our economy real money in lost engineer productivity and decreased reliability of software products. Programmers of all countries, unite!
The discussion was never about what keys you personally press to edit your code (nobody cares enough to wage a holy war over), but what other people have to deal with when reading your code.
Makefiles are the reason I use tabs everywhere. No need to switch mentally - or switch editor settings. But I'm rather poor ... maybe Makefile are the reasons for that? I need that correlation betweenn Makefile writers and income!
I suspect it's geographic. That happened to Ruby in the past, these languages get traction first in Silicon Valley (highest paid area for software) and then spread out.
It's also not very mainstream. Stuff like Java or C# has millions of developers in lower-paying countries that bring their averages down (I'm one of them :) ).
I thought that too, but further down the article it seemed that wasn't the case.
I'd like to see the split of age vs tabs and spaces. I'm with a few other people that may say experienced programmers prefer spaces as it causes them less formatting issues over time when working in larger teams or on differing IDEs - and experience pays more.
Interesting how multiple people presumed that older devs prefer spaces, which seems like the opposite to me. Tabs are a thing of the past, people used to use them a lot, and now they are relatively rarely used.
> The model estimated that using spaces instead of tabs leads to a 8.6% higher salary (confidence interval (6%, 10.4%), p-value < 10^-10). (By predicting the logarithm of the salary, we were able to estimate the % change each factor contributed to a salary rather than the dollar amount). Put another way, using spaces instead of tabs was worth as much as an extra 2.4 years of experience.
Maybe I'm not up on my statistics lingo, but saying "using spaces instead of tabs leads to a higher salary" sounds much more causal than "using spaces instead of tabs is correlated with a higher salary."
If they're going to say something leads to something else, I don't see how that one's justified over the reverse: "having a higher salary leads to using spaces." Isn't that's just as valid a conclusion from the data?
I used to work at a place where a huge argument occurred between staff, fighting over tabs vs spaces. It wasn't mentioned in the company code style.
Eventually leadership got annoyed at the amount of time developers were wasting punting code reviews back and forth over this silly nonsense, let alone the loud altercations around the office. Who ever could have guessed that developers would be such an opinionated bunch?
So they mandated spaces, and all was peaceful in the office.
For about a day.
Naively they put something along the lines of "spaces are to be used for indentation" in the code style document, but failed to specify howmany spaces.
So the new arguments started up amongst the office. 3 spaces or 4? Whoever could have guessed that a number of developers were actually belligerent types who would go out of their way to find something to argue about, and also stubborn? Such a rare trait in developers.
So the arguments raged again, and eventually management decided they'd had enough. After all the fuss and grumbling over making an arbitrary decision on the tabs vs spaces debate, they decided this time to be democratic.
They scheduled a big all-hands meeting for the developers, and tolerating no interruptions, outlined that a binding vote was going to be taken. The code style document would be updated to reflect the democratic consensus, and also warning that future arguments on any other points would result in verbal warnings, and potentially dismissal.
With the software development managers standing at the front each to independently do the count, they asked all developers in favour of 3 spaces to raise their right hand, and all developers in favour of 4 spaces to raise their left.
The count started, but soon the managers realised that with all the raised hands, they couldn't see the fours for the threes.
Tabs were the default for a long time, so it can be argued that developers who use spaces make a conscious decision and care about clean code more than tab users who just go along with the default. I'm not arguing tabs vs spaces here, but exploring systems and caring about good organization.
If you care about clean code, being orderly and organized probably extends to other areas, too, and that helps you make more money.
In my experience, developers who mostly use default settings are often unorganized and easily confused. They also know very little about the systems they are working with, because everything outside their IDE doesn't interest them.
I'd also bet that many tab users had to check what they use, because they didn't know or care.
tl;dr: Developers who change the settings are more dedicated to their job.
On a somewhat related note, if I had to ask a Genie for a wish, I'd ask him to magically convert all tabs in all codebases to spaces and make git forget the commit.
Apart from the fact that you are doing it the wrong way around, that would actually be a really useful git command.
I.e. you fix the whitespace in your files, then rewrite history as if it was always that way. Then you don't get git blame showing you whitespace-only commits.
(Yes I know there is an option to ignore whitespace in git blame, but it isn't on by default so it is useless everywhere except the command line.)
"The model estimated that using spaces instead of tabs leads to a 8.6% higher salary".
So the model actually predicts causality, instead of correlation? That's amazing. I'll start using spaces instead of tabs today and I will ask for a 8.6% raise.
Boring corporations like boring spaces, and have to pay big, boring salaries to get any talent at all.
On the other hand, cool code slingers may or may not prefer tabs out of personal idiosyncracies, but as long as all of them get shortchanged by the VCs and/or startup founders...
Ugh, could it be because those who use tabs are from a younger/less experienced/less paid generation that have learned to program with tabs, as opposed to programming veterans who were used to spaces?
I don't think the fact that you use spaces automatically makes you a richer programmer.
the only right answer for "tabs vs space" question is "i put a modeline comment with the project accepted style on all files I touch. And that style guide better say tabs" :)
Of course they do because they are pig headed ignoramuses who are insist on getting their way in spite of all evidence that they're wrong. So of course they are good at getting raises. ;)
First thought: perhaps languages that officially recommend spaces (e.g. Python) predict higher salaries compared to those that recommend tabs (e.g. Go)?
Older people use spaces. Older people make more money because they are further along in their career. Thus it only appears spaces make more than tabs, when it's really about age.
This is the third time I've noticed that people didn’t read the article closely enough to note that this explanation was explicitly rejected after the author controlled for years of experience and the effect was still present.
I'm building an app to help you easily email your congressperson and ask them to create legislation requiring space/tab equality. This has to stop. Please consider donating to my Patreon.