This is a huge effect. Implausibly huge? I'm reminded of Gelman et al's piranhas: http://www.stat.columbia.edu/~gelman/research/unpublished/pi.... The "folk theorem" version is that you can't have very many independent variables that all have large effects on salary. Saying that spaces vs tabs has a 10% effect is tantamount to saying that its one of the ten (or fewer) most important things about a developer.
So there must be a confounder. What could it be?
- Do the top schools all instruct students to always use spaces? This should have been partly taken care of when the author controlled for level of education though, right?
- Choice of editor? This seems like a weird one, but editor defaults are definitely linked to tabs vs spaces, and the survey didn't even collect data on this.
- Starting language?
- Total number of languages used? Spaces are tolerable in more languages than tabs are. Of course, I'd expect "both" to beat "spaces" if this was the case.
None of these strikes me as particularly plausible, except maybe the last one. This result is kind of bothersome, because it's big, obviously not a statistical fluke, and hard to understand.
Only thing I can say is that I started my career with tabs as it made more sense on the surface, but then over time migrated to spaces which did not have a lot of issues that I was encountering with tabs, while interoperating with other projects,etc. Spaces are much more frictionless than tabs, so maybe the attitude of trying to reduce friction would be such a variable ?
> I started my career with tabs as it made more sense on the surface, but then over time migrated to spaces which did not have a lot of issues
I think this is a common phenomenon, not just for individuals but for entire organizations. Over my career I have entered various large existing software projects. I've only seen two classes: (1) "we use spaces only", and (2) "we used to allow tabs but new code must use spaces only". Whatever the perceived theoretical benefits of tabs may be, in practice they seem to cause headaches for teams.
> I started my career with tabs ... but then over time migrated to spaces
Perhaps this anecdote resonates with many developers? If so, then perhaps tabs vs spaces is correlated with years of experience, which is correlated with salary.
If you read the article closely, you'll see that they made some effort to control for programming language, and in particular they note that this effect occurs within each subpopulation. So, among PHP developers only, it's still the case that spacers make substantially more than tabbers.
Very common in the Bay Area that spaces are mandated. Personally, I don’t like it but it’s what I see here. If you included what I normally do and at the comp I get, just one Bay Area participator could fuck up the stats real fast.
It was already discussed in the past, one major source of the difference was that in Europe tabs are more common and it is also more common to talk about monthly salary,
I settled on spaces long ago for the following reasons:
- Tabs move the cursor to the next "tab position" but are invisible, which means that whenever someone hits tab in the middle of something (accidentally or otherwise for alignment), you end up with messed up looking text and alignment as soon as you view it with a different tab size.
- Trying to enforce "tabs only for indentation" rarely works without headaches because humans.
- Using monospaced characters everywhere means that you'll never encounter positional issues ever.
I've worked in 2-space, 3-space, 4-space, and 8-space indentation houses and honestly, I don't see the point of viewing indentation in your preferred size. It's easy to adapt to the house rules, and the benefits outweigh the headaches.
I'm a space person, but I disagree with the premise of the first two points.
Exotic alignment such as trying to align equal signs on different lines together doesn't make sense... All the different cases are too difficult to describe in simple words. So it's better to simply not do it. IMO, the only whitespace in code should be to separate different tokens/words and for indentation. Adding whitespace to create any other kinds of visual effects should be discouraged.
I ended up using spaces, entirely because of the last point and because there are many products out there which render tabs really poorly. I literally can't trust people to be sensible about how wide an indent should look.
> Exotic alignment such as trying to align equal signs on different lines together doesn't make sense
It makes a lot of sense in some situations and makes the code much more readable. A long list of declarations, configuration options, or a pattern matching block with many short cases can look a lot less chaotic when you align them. Of course it should be done in moderation. And as someone already mentioned, for things like block selection and editing it makes quite a difference.
If the GP's "multiline editing" means what is also called "block selection" (e.g. using Alt + arrow keys in Notepad++), then multiline editing won't work -- logically, just simply cannot work -- unless the text is aligned. Which is one reason why I think that was what was meant.
The other reason is, this is pretty much the only reasonable interpretation of "multiline editing" I can see here. Which makes me intensely curious: What did you mean by, or think was meant by, "multiline editing"?
There's more than block selection which is actually quite limiting in comparison with the other possibilities. What I do often (SublimeText, VSCode for instance) is select a token, select a bunch of occurrences of that over multiple lines, then start editing from there. So in the case of e.g. unaligned equal signs select the first one, Ctrl-D to select the equals sign on the next lines, then move cursor around word by word and edit. Or indeed start by creating multiple cursors at the front of a line and start from there. Etc.
Ended up making my VSCode show white spaces instead and setting the default clicking tab to make a single space, but I appreciate the advice to make it more visually explicit, it has definitely thrown me off before when the code i'm looking at is so deeply nested.
Do you have any other code editor visual customization tips you'd recommend for a better experience?
I have never accidentally hit tab when I was meaning to hit the space key.
I constantly have problems with positional issues with spaces because every one uses a different number of spaces and its too easy to miss click three spaces in a block of 8 instead of 4 spaces.
I don't understand how every one else has issues hitting the tab key but no problem clicking on space 6 out of 10 spaces.
> I don't understand how every one else has issues hitting the tab key but no problem clicking on space 6 out of 10 spaces
I use spaces all the time and didn't even know this issue is a thing. Especially when using monospaced fonts and text editors which just treat tabs and spaces almost the same from the user's viewpoint. I mainly prefer spaces because the cursor movement is more consistent and predictable, especially when I align things in code which otherwise leads to a mix of tabs and spaces.
Yeah I'm confused here. I think the "clicking" in previous posts refers to using the mouse to position the cursor within a group of spaces/tabs. I don't use a mouse in my text editor so it took me a while to grasp.
> Using monospaced characters everywhere means that you'll never encounter positional issues ever.
I have seen many people, including myself, fat-fingered (or when their cats ran across the keyboards) 3 or 5 spaces in 4-space indentation Python code, because it isn't always that easy to spot when eyeballing a dozen lines of code.
I have never made the same mistake when writing Go, where I use tabs for indentation. Because there's a huge visual difference between one tab and two tabs.
One can argue that IDEs and CIs should catch errors like this, but sometimes I write throwaway scripts on remote servers that don't even have syntax highlighting. It is just one fewer thing to worry about when I don't want to bother to configure a text editor on an ephemeral server.
In theory, tabs for indention and spaces for alignment would be the best way to handle whitespace.
Unfortunately in practice, two factors are in the way:
1) Most developers are confused by this type of whitespace usage. Simply because it is the less popular practice. So when you have a codebase that uses tabs for indention, you get more broken commits from developers who stumble in keeping the system intact.
2) Out of the box, VIM has no easy way to colorize tabs. So when you look at your code, tabs and spaces look the same. You cannot say from just if the whitespace is ok or messed up. You can show all non printing chars with "show list" but that is not very nice on the eyes. Or you can configure "show list" to only highlight tabs but then you lose the ability to show all non printing chars.
Vertical space is at a premium, and 'wasting' five lines when three will do strikes me as uglier than the opposite. Adjusting spaces when things get refactored doesn't strike me as especially tedious, but YMMV.
I don't go so far as to support "lisp style" closing braces for brace-block languages, though. It's just too weird.
Agree that ugly is subjective. But adjusting spaces when things get refactored is bad, not because it's tedious but because it pollutes history. Changing whitespace on surrounding lines to my change makes eg `git blame` less informative. It's the same reason I believe in trailing commas.
I acknowledge this problem while throwing up my hands at the incredible laziness of the entire profession in not employing syntactically-aware diffing.
It's our own fault, we have no excuse, and it galls me to serve a dumb line-based algorithm over the writers and readers of my code.
Ideally, what is stored in version control is just the AST, and how you or I display it is up to our own preference. Then I won't have to care about your weird indentation preferences and other style choices and you won't have to care about mine!
I don't think even emacs has good support otb for mixed tabs like that. The typical behavior is to convert all spaces at beginning of line that are multiples of tab-width to tabs.
Actually, in theory the best solution would be an IDE that handles whitespace sufficiently flexibly that the actual encoding of the whitesapce doesn't matter anymore. It has to reliably distinguish indentation whitespace from alignment whitespace. Then everyone could separately adjust the indentation to be N spaces in a codebase without needing to decide centrally on tabs/2spaces/4spaces etc.
Mixed is the worst. It doesn't make sense logically.
Isn't indentation just another kind of 'alignment'?
After all, we use indentation to align text on the page... The differences between between all the supposedly distinct kinds of alignment are too subtle and difficult to describe in words to be used as a rule.
It's better to stick to simple rules that are easy to follow and enforce - Leave no room for ambiguous interpretations.
Also, I hate it when developers try to break up code in weird ways to align all the equal signs together for example. I would prefer that they never do this. Maybe if our eyeballs were stuck inside our heads in such a way we had to move our necks to read each letter, then it would be a good idea... Then it would be worth the complexity it adds. In the real world, however, moving one's eyeballs a few millimetres sideways isn't very difficult.
There is no need to litter your pristine code with extra spaces just to save people from having to shift their eyeballs a bit when reading your code. You save the reader like 10 eyeball shifts out of 1000...
> I hate it when developers try to break up code in weird ways to align all the equal signs together for example.
I do this in cases where I have many similar lines, for instance calling the same function many times with different arguments, and I want to make the differences between them more obvious. I find it to be much more maintainable and easier to read / identify bugs.
This is a good example. I think the ideal way to support this would be an editor/IDE using tables for alignment. The compiler doesn't need to know about tables, whatever information the editor needs could be encoded entirely in a comment line preceding the table contents (which the editor would hide/replace with the table header unless the user chooses to reveal it).
Anyone using another editor would simply see a somewhat cryptic comment line followed by aligned code. And table-supporting editors could use a content hash to detect changes in the table contents and inform the user.
Similar, and I like the idea of Elastic Tabstops. A significant difference is that Elastic Tabstops won't look right in an editor that doesn't support them. What I'm suggesting would use spaces in the file and put metadata in a comment (though it could be stored elsewhere, too).
I find that the skill of reading code correctly without relying on visual aids can be trained and is a valuable skill. Visual aids won't help you to train this skill.
I'm confident that my ability to identify potential bugs quickly is correlated to my ability to visually spot tiny differences in the code. In both cases, you need to develop an extreme attention to detail.
It's one of those tradeoffs we make to save time. I get practice tracing program logic by reading poorly organized code written by others, but for my own purposes, I have a standard, consistent way of organizing/formatting things that saves a lot of mental overhead.
People make the same argument about static vs dynamic types -- "if you were a better programmer you wouldn't NEED to rely on type information!". Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier.
What is language syntax but a visual aid that we all use to avoid writing assembly?
>> Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier.
That is an extremely interesting argument. Personally, I find that overhead to be useful; the difficulty of keeping track of all the different types encourages me to design simpler interfaces between components. When I'm struggling with remembering what type some variable is, I know I've made the method interface too complicated (e.g. maybe the component should just keep the instance state internally and only accept an ID instead of a whole instance as argument). I guess that's why I prefer dynamic typing; it forces me to keep my interfaces simple and to think more carefully about state and logic co-location (to get high cohesion, loose coupling).
I like the Alan Kay quote about OOP "The Big Idea is Messaging". To understand this quote properly, we need to understand what "Messaging" means; it's about communication. Effective communication is about conveying intent; components should tell each other what needs to be done, not how to do it. Having complex interfaces which accept complex instances as arguments is akin to micro-managing the component. Typed languages are only particularly useful if you have complex interfaces. If you have simple method interfaces, you don't need a typed language because remembering what the parameters are for each method is trivial.
My pet theory is that the preference for spaces comes from people who want their codebase to be equivalently readable in any editor right off the bat. With tabs, depending on editor configuration, the same codebase could look fine on one machine and be a mess on another.
Furthermore, I believe that with certain indentation styles (e.g., when arguments in a function call align with the opening paren) tabs require that one extra preliminary step of configuring one’s editor in order to view the code properly, while with spaces that extra step has more optionality and is only needed in order to edit the code with auto-indent.
IMO since one has to adapt their coding style to the dominant style of the codebase (single/double quotes, etc.) either way, one might as well adapt to the indentation as well, so I’m not against spaces.
And of course, due to people who don’t take care to set up their tooling and end up mixing tabs and spaces for indentation, a particularly hot mess can arise—and what’s worse, that mess can accidentally look fine in editors that happen to be configured in a particular way. Because of that, I keep whitespace visibility turned on across my editors.
Your first point is closely linked to a theory raised in a past thread (https://news.ycombinator.com/item?id=20719010). Large, well paying companies tend to require everyone to use spaces, for pretty much exactly the reason you mentioned.
I think there's a general trend where C programmers generally are near the bottom in terms of salary, and I think a disproportionate amount of C programmers probably use tabs (due to the popularity of the Linux kernel style).
Or in other words: I know who's pulling down the average because it's me.
I suspect that this is partially caused by the fact that 'spaces' is the non-default choice in many standard IDEs such as Eclipse and the rest of its enterprise friends.
Software engineers who make active choices in their setup rather than just accept default configurations and tools tend to be better at other aspects of their job too?
There are plenty of reasons for preferring spaces:
* There will always be that one diff tool/website which doesn't support configuring the tab width and renders your code with 8-space tabs. Even if every tool you use supports configuring this, it's going to be a nightmare to configure every single tool when the default of 8 is not sane for the majority of people.
* If you enforce a maximum line length for your code, people who use a different tab width than you are bound to mess this up. I mean, you can somewhat avoid it with an automated linters, but then again, which tab width do you set it for? If you set it too low, it will look bad people with bigger tab widths working on a split screen. If you set it too high, code will be unnecessarily wrapped everywhere and it will look bad.
* Mixing tabs and spaces to ensure proper alignment of function arguments with any tab width can be a nightmare. Someone on your team is definitely going to mess it up eventually, and you'll have to clean up after them. With spaces enforced, indentation and alignment will look the same everywhere and mistakes will be immediately obvious regardless of the tool used for code review. (Editors may support differentiating tabs visually, but I don't think GitHub or GitLab does.)
On a team project, you don't get to choose other things like brace style either. You just have to learn to deal with it. There are too many variables to account for, such as the ones I mentioned above. Using spaces ensures consistency everywhere.
In an ideal world, you wouldn't have to worry about all this, you would just store a minified version of the code and your editor could format it with your preferred tab width, line length, brace style, etc. But in reality, it's not that simple. Auto-formatters are far from perfect.
It might have to do with the fact that people who use tabs have stronger principles (indentation should be one char!) and people with strong principles will generally have more conflicts with their colleagues and bosses. Usually conflict isn't good for salary negotiations or keeping a job.
That's my 100% unscientific, non-evidence based guess.
How about all whitespace should be represented by one character to reduce ambiguity. I shouldn't have to figure out if 'l' is 'ell' or 'eye'. Same way I should not have see visually whitespace and wonder if it's tab or space. One visualization, one ascii representation.
Because whitespace is not a space includes margins the spacing between letters etc, we all ready have a word for the white space character you are talking about its called space and its not used for indentation.
I think this is where a lot of the trouble comes from: Tabs are misunderstood as "whitespace", as if code was some sort of DTP by a graphic designer. Code actually is a functional instruction to a machine - semantics matter, and this is where tabs shine: they are unambigious (did the developer decide to indent this this far, or not?)
If tabs-as-whitespace trouble you, editors since the 1990s have allowed you to choose/configure other representations of tabs.
I could literally not use any indentation and the machine would still understand me. Not sure how they matter for machines?
They do matter for humans though. The reason we write code and structure it the way we do is for human convenience. One of those conveniences is thinking of the layout of code as a visual help to scan and read it. As such I am very much organizing my code like a graphic designer would organize information.
Edit: Indentations do matter in some languages and used to signify information. But not in a lot of them. The point still stands that most of the time we are using them for visual purposes not information to the compiler/interpreter.
Only in the sense that all characters are "for visual purposes". Tabs have a distinct meaning from spaces, and can be rendered however you want (arrows or chevrons, for instance); "whitespace" is a poor term for them.
If I ever have to program in python, I'm absolutely going to pull out some of my obsolete translation programming and write a preprocessor that translates brackets to the semantically equivalent indentation, yes this will make python sort of an intermediate language LOL
I thought they were for aligning columns in a table (hence “tab”), rather than indentation? This goes back to typewriters. Sure you could abuse it for indentation and perhaps that became common practice at one point but it doesn’t mean that’s what it’s “for” any more than spaces.
> This goes back to typewriters. Sure you could abuse it for indentation and perhaps that became common practice at one point [...]
Indentation (specifically the first line of each paragraph) was arguably the first widespread use of the tab key. The annoyance with using it for actual tables was that generally you'd want numeric data to be right-justified (so that digits of equal significance align vertically). So I wouldn't really call it an abuse, especially on modern keyboards.
Arguably yes. And arguably spaces are better for indentation as a matter of convenience and accessiblity and you can’t make any strong argument that it’s what tab is “for” based on original purpose.
Name a few please. I can only think of garbled alignment when reading a diff of a file which used tabs to indent. And that is not really speaking for tabs.
Well, the most basic one is that if I prefer that my code blocks indent on 4 visual "spaces", but you prefer that it does on 2, there's no way of representing that with spaces. Tab means, 1 indentation level. How you choose to display that is then a matter of personal preference. So you can have your cake and eat it too.
Then if I or someone else needs to de-ident a line you remove 1 char. Plus, if your IDE&mode is worth its salt, hitting tab on an already indented line doesn't do anything, and because it has a simple meaning, hitting tab on a non indented line simply indents it.
Of course, if people mix tabs and spaces without understanding them it will be garbled. Or if people just want the cake for themselves, greedy spacers!
If the "that, callback);" line was indented with tabs, then any other tab length would make it go at any random place. Thus if you just use tabs your code is only readable with the tab length used for writing it. So instead you can introduce spaces for alignment ; now that you have spaces needed for alignment, why not just use spaces for everything instead of two characters ??
So that anyone viewing the code can choose the indentation width according to their own preference? It really can't be that hard to grasp...
It can still be argued that it's not worth the trouble, especially with the poor tooling available, but what I can't really understand is how supposedly smart people turn off their inner logic when it comes to such a simple concept.
Why are you writing this to me? You already commented on (another) comment of mine which explained what is meant by indentation with tabs and alignment with spaces.
A function call has an indentation level (depending on where it resides in the code); if for whatever reason you split the call on multiple lines, all the lines should have an equal amount of leading tabs to signal that level of indentation – different arguments in a function call do not have different indentation levels. If you choose to align the contents on the lines, for example to the opening parenthesis, you do so by using spaces.
In your own words, this is "all those shenanigans" but you can't possibly try to convince me it is that hard to understand or would not work. Of course it does.
> what is meant by indentation with tabs and alignment with spaces.
but I said at the beginning that this was not good:
> So instead you can introduce spaces for alignment ; now that you have spaces needed for alignment, why not just use spaces for everything instead of two characters ??
In my experience, allowing both tabs and spaces just leads to that kind of mess, consistently: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-... and for zero good reason as alignment is a semantic thing, and tools cannot understand the semantics of your code (at a human level, not a "pl semantic" level)
Feels like the vi vs emacs fight. For some people, it seems easy to only see their side and consider the others "smart but dumb" or similar. The reality is probably somewhere else. Tastes differ, and just because someone is not sharing your view on things doesnt necessarily mean they are doing something wrong.
eMSF says "what I can't really understand is how supposedly smart people turn off their inner logic when it comes to such a simple concept."
It's part of our human nature, which sometimes gets out of control. Imagine the following as a programming languages discussion rather than a religious one, and ending (rather abruptly) instead with "Spaces vs Tabs":
As a tabs user I generally prefer this for multiline function calls, using a tab for alignment. I only use spaces for alignment for whitespace that isn't at the start of a line.
I answer your question with another: If your editor is configured to create four spaces when you press the TAB button, why not insert a TAB instead? :-)
> If your editor is configured to create four spaces when you press the TAB button, why not insert a TAB instead? :-)
But I never press the tab button. It just aligns correctly when I press enter depending on the context.
I however really want my code to not break whatever the editor anyone is using, and that means using spaces.
Well, this would be something that the IDE/mode you're using reflects. The indentation isn't "fixed", if you're inside a block it will be something, if it has an open parens, then it might indent on the open parens, or two spaces after the parent line declaration start?
I know what you mean because some modes (ie. in emacs, but I guess every other editor as well) sometimes will not be indenting how I think is correct, but this is not a problem with the "concept".
I'm sure if we can cram artificial intelligence to give you the full word you're typing we ought to be able to make indentation by tabs work correctly across editors/machines/modes/plugins - and each "plugin" for whatever language can have its own idea of what is the right way (that would still be customisable - at least that's how it works with emacs). It's also a problem that only needs to be solved once per editor and then can be reutilised by whatever plugins using their own definition of what is the visual size of the tab and how it behaves on other semantic blocks of the language in use.
I've moved to use formatters in languages that have a strict one so to not worry about this, I can even understand saying that just using spaces solves it, as it's the same everywhere - but essentially it mixes things - one is a question of visual representation that should be represented by a unit that a user can define (tab), the other is significant whitespace.
In your example, with whitespaces, it's basically arbitrary - here it's 12spaces, next function where you multiline the arguments, it's `connect_more_14_chars(` so it will be 26 whitespace chars...
> one is a question of visual representation that should be represented by a unit that a user can define (tab),
where does this assumption come from ?
> In your example, with whitespaces, it's basically arbitrary - here it's 12spaces, next function where you multiline the arguments, it's `connect_more_14_chars(` so it will be 26 whitespace chars...
in practice it'll just be one key press as tools do the alignment. why would the number of whitespace chars matter at all ? what matters is that things are aligned.
Perhaps I would prefer that my editor in this language, did this formatting. It doesn't change the meaning of the program.
> in practice it'll just be one key press as tools do the alignment. why would the number of whitespace chars matter at all ? what matters is that things are aligned.
This would be the same with tabs. But we go back to the same presentational aspect. If you prefer that it indents on the open parenthesis, and I that it indents on parent line start + 2 "visual" spaces we can't make an editor that covers both our preferences. With tabs, at least theoretically, we can, since the tab has no other meaning than an "indentation level" (which then translates into whatever it means "whitespace wise" for a given situation).
The second and third lines have a single tab to do a lexical indent. Then the third line uses spaces to align the "that" with "this".
Not that I see any reason to format code this way; IME it makes code much less predictable when reading and thus more cognitive load to read and understand.
This is a good example of a pointless alignment footguns tabs prevented.
Why do you want to recalculate the number of spaces before 'that' based on any change to the length of the function name 'connect', and why do you realize you don't want to when it comes to aligning connect with 'foo' to be consistent with this styling instead of indenting priority?
Much easier to hit tab twice on the 3rd line because that is the correct nesting depth and not try to adapt lines based on insignificant aspects of previous lines and not make someone refactoring try to hop around any more than necessary.
> Why do you want to recalculate the number of spaces before 'that' based on any change to the length of the function name 'connect'
from experience ? connect is a Qt function that dates back to 1995, it's been here for the last 30 years, it'll be there when I retire. Optimizing my experience for "what if connect was renamed" is a big YAGNI.
> , and why do you realize you don't want to when it comes to aligning connect with 'foo' to be consistent with this styling instead of indenting priority?
I don't understand what you mean there, what would "aligning connect with foo" mean ?
So I don't agree with GP poster that there's no reason to use spaces for indentation, but Rome recently switched to using tabs for accessibility reasons:
The only case I can think of is when the patch has lines above or below indented with spaces and a modified line with tabs. It looks OK in an editor, but the extra +/-/space from the diff doesn't move the tabbed code, which still is indented to the tab-stop boundary (the tab "absorbs" the diff marker). The space-indented lines are moved 1 to the right by the diff marker, but the code on the tab line now looks to be 1 character too far to the left in the diff.
The problem is not the tabs, instead it stems from trying to mix lines indented with tabs and lines indented with spaces.
- semantic coherency: use only one character to signify an indentation level
- user preference of UI representation of code: decide for yourself how far a tab indents a codeblock.
- less reformatting necessary during refactoring and rewriting
- separation of keyboard keys for different functionality
Got it thanks. I suspected as much but I thought it would be insanity to actually use the Space key.
My opinion is that it is split based on role/platform. The first half a decade of my career I used tabs, the past half a decade of my career I have used spaces. The difference? First half I was an Android app developer (Java). Now I'm a backend developer (Golang).
I also lead the time so I get to make the decision on what the team uses. Hopefully spaces is the right one :D
Indeed it does. Well there you go, I'm full of sh*t because having just checked a few of our Go projects, they're all Tab indented. My editors use tabs when editing Go files, and spaces for others. YAML for example uses spaces.
I guess it's so well handled, and transparently so that I hadn't even realised.
Also the spaces thing was a joke, I don't tell my team to uses spaces or tabs, I just tell them to follow the Go programming standards/guidelines when writing Go.
or may be they just like to follow rules, including rules they impose on themselves, and apparently it pays off to not limit oneself with artificial constraints
ME. My editor is set for "tab chars" because that's what I work with (I did not choose this). When I use that editor to make a quick PR to a project using spaces, I have to press space a couple of times to indent. I'm not going to change my settings just to make a couple of line in a PR.
Personally, I'm a tab user in a language that does mostly spaces (Rust). My own projects use tabs but most projects I interact with use spaces. I had tabs in my editor for a long time and I would always either press the space button or change the editor's setting. Then I got sick of it and changed the editor's default. My own projects have an editorconfig file that my editor can read, setting it to tabs in the project's scope. The projects I contribute to usually don't have such a file, that's where the spaces-per-default setting comes in.
I'm using vim with the detectindent script (with ugly hacks and enhancements)[1] for that, it gets this right most of the time if the source file isn't too short, including the number of spaces in case it's space-indented.
Since some very popular languages (Python) actively discourage using tabs, this is most likely related to a difference in language choices, rather than in a genuine indentation preferences.
Then you get someone who uses a tab size of 2 spaces and this allows them for a longer line than you with your 4 or 8 spaces-sized tab. And all alignments are wrong (you know, "indent with tabs, but align with spaces" but then people are not perfect and things end up mix-and-matched) because everything is calculated to fit _their_ tab size and nothing else.
Besides, everything looks horribly indented when looking at the code in Github, which renders huge and ugly 8 spaced-tabs, so lines with just a couple tabs already tend to travel to the right and disappear when using a two-column display :-(
This kind of things are what drove me from using tabs, to preferring and LOVING an already strongly opinionated tool like Prettier.js. Just apply the defaults, no more bikeshedding discussions.
We use tabs at work. I haven't ever had any alignment issues or nasty diffs. Some people work with "two spaces" and some people with "four spaces". The rules of alignment have to make sense, you don't just align wherever you want. There's a style guide of when to align and when not to align (but the IDE and tooling does it all for you) and it all comes out quite beautiful no matter how you have your tab chars to display.
> And all alignments are wrong (you know, "indent with tabs, but align with spaces" but then people are not perfect and things end up mix-and-matched) because everything is calculated to fit _their_ tab size and nothing else
With testing and code auto formatting pipelines already in place, this isnt a problem
In theory I agree, but having recently worked in a code base that used tabs, it was painfully obviously that some devs displayed them as 4 spaces and some as 2 because they would visually align things for their editor’s configuration. It was very ugly.
Nah that’s exactly how the alignment did occur. Spaces would be mixed with tabs to align things with 4 spaces aligning to each tab. Since I don’t like to view 3 virtuously splits I don’t like all the wasted indentation space and I view tabs as 2 spaces. It was obvious when someone didn’t consider how it would like if a tab wasn’t 4 spaces.
The moment you begin talking about "should", everything goes out the window because humans will thwart you. The only way to be 100% sure is to avoid multi-space characters like tab in the first place.
Just like with C and static analysers, there is the "one should" and what the large majority actually ends up doing, as usually no one enforces anything on large code bases in most development shops.
Just like the ethos "If the backup process is not automatic, it won't happen", I'd like to propose "If the formatting style is not already enforced by default, there is no formatting style".
My personal preference to solving this problem is a simple rule. "No alignment allowed.", Then you only need to worry about indentation, and the character used does not matter.
> everyone can use indentation they prefer without causing conflicts.
To be honest, I never thought of this, I use spaces and my editor converts to 2-space indentation. But I can imagine that some people prefer 4 "space" indentation. With spaces this is impossible, whereas I now realise, an editor can render them any way it wants, so at 2 'spaces'.
So I agree somewhat, that tabs sound good on paper. But then again, I don't want to start earning less all of a sudden...
Nope... This is the big misunderstanding that, for some reason, people just don't get and causes tabs to be maligned.
Tabs are for indentation, not for alignment. If you want to align things within the same indentation level, use spaces. This will never break on any platform or in any editor.
When I was about 5 years old I ate a parsnip thinking it was a potato. My taste buds were all of a sudden overwhelmed and I spat it out in disgust. It took more than 20 years for me to try a parsnip again.
My theory is the same with tabs. Everyone developer, during their early career, learns what tabs are the hard way, that is when they open a document in another editor and, because they've made a mistake, it looks wrong. But instead of learning how to use tabs properly, they spit them out.
Tabs only work in a perfect world where 100% of source files are always edited with tab aware editors and absolutely no one ever uses a space instead of tab.
I rather keep using spaces, like I have been doing since 1992, plus apparently it reflects on salary.
I don't see why it defeats the purpose at all. You get to have your one-character-width indentation, while other devs will being able view it with more indentation width and spend less time dispairing at issues of readability for them. This seems like exactly what tabs are good for.
I’ve noticed this before too! I think it’s because spaces are just lazier. Tabs might be more flexible but they do take a bit more effort. Someone who puts more effort than needed into one thing won’t stop at tabs.
I don't know which editor you use but in my experience using tabs or spaces is just changing a single setting and then forgetting about it. The most likely explanation is that a lot of languages recommend spaces for indentation, so probably big companies just follow those guidelines and they also pay bigger salaries. Trying to find some causation of "people who use spaces are better" is not going to go anywhere.
My theory is that people using spaces are more concerned about their code being readable outside one particular IDE on their machine and that could extend to them generally doing better quality work because they view the big picture better overall.
You’re right. I meant lazy in the Larry Wall sense (more efficient) but was also trying to pick a word that wouldn’t paint tabs in a bad light, because it’s more efficient in a different way.
Don't get lured by the Dark Side! Accessibility is the real reason you must use tabs instead of spaces for indentation [1]. Yes, it's evident that Accessibility is not valued and that it's easier/cheaper to not care. We should start to care. Maybe it doesn't even cost that much. Just by flagging it on formatting commit hooks or in some plugin in static analysis tools like Sonar, would go a long way in raising awareness and improving this.
Developers with visual impairment have different needs regarding indentation. One could need a tab-width of 1 due to the use of gigantic font size and the other a tab-with of 8 because of a wide monitor.
Meh. I find "accessibility is the trump card" arguments as blase as "security is the trump card" arguments - such arguments reflect badly on their speakers - all is tradeoffs.
In the linked case, I'd argue that specialized fonts or editors are a better choice. After all, even if you make all the code in your repository "accessible" by using tabs, your accessibility-limited colleagues might have to interact with code outside your repository (e.g. Stack overflow, or dependencies) that uses spaces. Something in the presentation layer (e.g. fonts or a screen reader) is far more likely to work consistently and correctly. Solve problems at the right layer.
That stated, I can see why such an objection might win the day. Nobody wants to take on the accessibi problem when solving a small problem like spacing consistency.
I use 2 spaces for indentation, but I agree that tabs are more logical.
The reason why I switched to using spaces (years ago) is because tabs look terrible when copy-pasting code in a text area in the browser; they look way too big.
If everyone chose tab spacing sensibly, then tabs would be ideal but there always seems to be some people somewhere who will exploit any flexibility provided by any technology to do something retarded.
At least with 2 spaces, I have full control over how my code looks everywhere.
Instead of saying international athletes are more likely to use Nike shoes you end up saying Nike wearers are more likely to be international athletes.
Actually, I like tab. It gives people more choice on how their code looks like based on their editor's preference.
But no, I cannot —even sneakily, manually— enforce tab in my company(es) code bases. Reasonable person uses formatter which opinionated config set from the first commit.
And I like the formatter decision better. If it is automated and reduce unnecessary debate between devs, why not?
If I recall, someone mentioned this was probably because the majority of IDEs come pre-configured to use spaces for indentation over tabs. Therefore, the study is skewed as most people don't update their IDE settings unless they're particular about them (IME this sounds like it's true).
Why do people try to put accessibility arguments on people rather than doing this intelligently per language in the IDE? The functions to convert tabs and spaces (not mention how to represent them) is entirely configurable already. Is there something I'm missing?
Using hanging indents works regardless of whether one uses spaces or tabs. But trying to align text based on the indentation of the opening parenthesis (of it's on the same line as the method name) pretty much only works well with just spaces.
[Edit: Personal Usage] I use space within text, and TAB/Shift-TAB to move between data entry fields. You never know when a TAB key is going to do something weird outside of your home IDE.
[/EDIT]
They missed an axis.... sure you can compare Space vs Horizontal Tabs, but what about Line feed vs Vertical tabs? Form feeds are similarly overlooked.
Also missing is the lf / cr-lf debate 8)
PS: Does anyone use Group, Record, or Unit Separators?
Did anyone seen actual "broken" indentation on any system in the last 10 years? (specifically indentation, not mid line breaks filled with tabs) Because that is the only argument for spaces.
Personally, I sometimes log onto very old boxes running some old OS and s/w, and I've never seen broken indentation display for tabs.
I think replacing tabs with multiple spaces was a valid solution in 20th century, but not anymore for last decade at least. Instead it transformed into a cargo cult like obsession, with zero valid reasons today.
If you use tabs, GitHub renders it as 8 spaces, which is... a bit excessive and legacy IMO.
I think until this is changed, using tabs for content that you want to be viewable in GitHub UI and has multiple levels of indentation just does not make sense.
The code wasn't written inte last ten years, but oh yes.
I've also seen code from a senior dev which consistently used two tabs, eight spaces, tab for some reason. I replaced it with spaces to fit the rest of the 50k lines (COBOL) when I was in the area making a change.
We are also saving 5-10% storage by removing whitespace at end of line, so.
I was asking not about the badly written code. I was asking about when you have lets say "good" code with tabs, when they are used for indentations and there is a single tab per line start, but that file is for some reason displayed garbled because text viewer/editor on the host can't work with tabs properly.
Because that was the reason always given for spaces usage - "what if I want to open code with tabs on some super duper legacy system from decades back, and some weird editor will mess up my indents. Spaces are safe everywhere."
And my point was that I haven't seen a system which can't handle displaying tabs in very long time (or ever).
I get you. I think the reason for the horrible tab spaces mix was that our system doesn't display tabs well and me seeing them in sublime/code/np++ where the older devs prefer to edit on the system itself.
The reason I want to use tabs is accessibility for visually impaired. Know some great devs who have to zoom lines until they become mega-sized and with four spaces the next line is a far scroll away for them, whereas with tabs they can set very slim tab widths.
That's right, four levels of delimiters, built in to ASCII! No unicode required. Instead of that we get CSV, with in-band delimiters and the resulting god awful quoting rules that go with that.
The question here is what space vs tab use is actually an proxy, which is a question you generally need to ask when you get weird but valid statistical results.
If there for instance was an correlation between having lived though the bad old days with primitive build/formatting tool chains and a preference for spaces that would easily explain a difference in salary that have nothing to do with the argument for/against tabs/spaces as it relates to modern tooling.
Is it that surprising that researchers coming from more developed countries consuming a most common sweet in europe (thus, likely of mainly western culture) would fare better on an evaluation by a Swedish committee ?
I use spaces because long ago I had two editors, one of which showed a tab as 4 spaces, and the other - as 8. So spaces provided consistency, that's all. Maybe older developers prefer spaces for that reason, hence the salary gap?
Yes. Ruby, for example, is entirely space-based, because it encourages line breaks after the first of a list of arguments, where the second needs to be aligned with the first, but depending on the number of characters in the method being called, the first argument could be anywhere in the line.
Ok, so first of all, I'd strongly advise you not to use tabs for Ruby, just because it's a community very heavily based on stylistic consistency, and the community is very much on the side of spaces (see https://ukupat.github.io/tabs-or-spaces/).
> I'd strongly advise you not to use tabs for Ruby, just because it's a community very heavily based on stylistic consistency
I've published plenty of gems and open source Ruby work and I choose how I write my code, thanks, and I couldn't care less what the "community" thinks about tabs vs spaces. The "community" believes all sorts of nonsense and if they don't like my code they can fork it and "fix" the tabs. That may sound a bit combative but I don't take well to being told I'm the nail that stands up too much.
My views on tabs changed based on something I read of Samuel Williams (it could be this[1] or this[2]) that was entirely reasonable (note his far more gentle rebuttal than mine with the key phrase being evidence based), and I'd consider him one of the top ruby devs.
As to the keywords example, I use tabs all the time with that style - what problem am I supposed to encounter?
To the other example with the array constructor sugar, I tried it with tabs, I didn't see a problem:
I read that and thought to myself "So what? " They're all perfectly readable and consider that an excellent example of bikeshedding.
Further up it suggests "Don’t use several empty lines in a row." I put two lines between every method and it makes a language where every block ends with `end` far more easy to grok just from the shape.
It seems I won't be using all of their suggestions.
Er... that's a simple, widely accepted and understood standard, with a broad set of tooling that can detect and auto-correct it. Crucially, it's something that doesn't really matter. Therefore, because it's, in Ruby world, the norm, the great thing is that we can, by default, just accept that norm, never think about it again, and get on with our day.
Bikeshedding, on the other hand, is taking a contrarian stance and deliberately arguing over stuff that really doesn't matter so that we spend time and energy arguing over that instead of over the code itself and what it's trying to achieve...
> Er... that's a simple, widely accepted and understood standard
Yes, and pointless, all the examples were readable.
> Bikeshedding, on the other hand, is taking a contrarian stance and deliberately arguing over stuff that really doesn't matter
Imagine thinking that using tabs is a contrarian stance! I remember when being a rubyist was seen as being able to think for yourself. Times have changed.
None of your examples pose a fundamental problem for tab-indentation; here's the basics how it should (always) be done, and works, and never breaks anything regardless of the width of the tab character as long as you don't break the gist (which is the hard part, especially with editors which sometimes work against you):
I don't even know what I use. It probably changes in different repositories. I've never cared enough to check or set it one way or the other, and definitely don't care enough to have a 20 minute meeting with my team to decide.
Maybe it’s “Developers who care about tabs v spaces spend more time on that discussion and therefore make less money than those who go with the defaults (all spaces)”
Might be unfounded, but my personal theory is that the correlation might be something as simple as companies that adopt (for instance) the Google C++ coding style guide pay more.
In the beginning, there was only tabs, and all indentation was exactly one tab greater than the prior context.
Then, a few people started doing tabs and then spaces to indent their function arguments to align with the opening parenthesis of function arguments. Why? Because it looks like a windows drop-down menu hierarchy, opening the sub-menu to the right of the selection. These people tend to be UI-focused, heavy PowerPoint users, CS 101 teachers, and management types.
This was okay when everybody was using MSVC or Visual Basic (no Unix person would do this), and so tabs-then-spaces code crept into everything. Tab purists were at worst mildly annoyed. There was no such thing as a space purist. They would have been physically assaulted for banging on a mechanical space bar that many times in a cubicle office.
But if you opened up that file in notepad.exe, or wordpad.exe, or TextEdit, or Borland or vi or emacs or any other text editor, you would get a preview of the chaos that was about to be unleashed. When the web became popular, the standard programming environment for a lot of people became “right click -> view source”. Space width was all over the place. Tab width was blowing text off the page. Word wrap was horror, and saving a file in word wrap mode saved the imputed carriage returns.
But that was still just aesthetics. When python became popular, it changed behavior. Python tried to adapt by allowing many different styles of indentation. It worked most of the time, but not all the time. This is how it turned into a full-on war.
It is easy to convert tabs to spaces, and hard to go the other way. So naturally, people wrote a simple script to convert tabs to the right number of spaces. Then immediately the number of key bangs rose to a deafening roar. Nerf sales went through the roof as the office became a war zone. The accountants were still using pencil and notebook.
So people tried to write scripts to convert back to tabs. Hahahaha mortal. You can never go back. Your attempts are futile and the one bug you introduce will be your undoing. Foolish tab purist! Come to the dark side and embrace the space. Yesssss... see that giant bar at the bottom of your keyboard? Hit it! Again! Louder! What’s that? You made a mistake? Lost count? Start over! Hahahahahaha!
Then editors changed to no longer record your keystrokes, but instead try to guess at what you mean and show you what it wants you to have meant. These editors have other great features to churn out reams of code that nobody will ever be able to review or keep up with, which is the key to leading a project and getting that promotion. The worse the code, the more people you’ll have to manage to get it working.
Meanwhile, tab purists are an exiled minority, unable to find anybody to work with, begrudgingly accepting their orders from some young superstar coder that blew out the git log in their first 30 days on the job.
Oh the lowly tab purist. Go home and seethe; you are defeated. Watch again one of the five movies you own on your Betamax or HD-DVD. Better standards? Hahahaha!
I forgot the 80-character limit. Because of word-wrap, and the tendency for editors like notepad to save the newlines it adds, the 80-character limit came into fashion. People that write long chains of functional code also like tabs. This forced them into deep nested calls with lots of tabs, and the tab display width changed from 8 to 4, sometimes 2. There was good reason for this. In C/C++, you had to declare every variable at the top of every function so that the compiler could allocate space for it on the stack. This was inefficient, hard to get right with the types, and ugly to read, but it was the way that people were taught in school, and the other intent of the 80-character limit was to force homegrown coders to do it like everybody else. Tabs of course wreaked havok upon these linters. Wars erupted over how many characters a tab should be. The internal divisions between old-school 8-space tabbers and the new hip 2-space tabbers made surrender to 4-spacers seem a little more like compromise rather than death of principles. 80 characters? Seriously? My template type declarations are greater than 80 characters.
This of course gave rise to the huge cultural phenomenon known as “wrap music”, which is composed by independent cubicle artists producing either ‘scratches’ using the scroll wheel ratchet on their mouse, or the loud unstoppable succession of system beeps that you get by holding the down arrow until your laggy system finally gets to the bottom of a text file.
> Because of word-wrap, and the tendency for editors like notepad to save the newlines it adds, the 80-character limit came into fashion.
Uh... No, absolutely not. What are you imagining, that this newfangled Windows Notepad is ancient history or something? Sheesh, kids nowadays, geroffmylawn etc. The 80-character limit comes from old terminals (and the text mode of at least CGA, possibly even EGA, PC monitors) and, ultimately, punch cards.
You are definitely right about this. I was thinking more of who it was enforced upon and how things got messed up with respect to the difference between tabs and spaces. I remember opening things in a terminal and it was relatively clean, maybe a few wrapped lines, and then editing in notepad, and then it looked like trash when opened in the terminal because newlines were all put in some arbitrary width. My perspective mostly comes from MSDN shops I interned with in the 90s, so the terminal (DOS) was mostly a printf debugger, scripting environment, gaming console, and BBS gateway. I installed zipslack once, and had no idea what to do with it. Forgive me for being a L4m3r (still actually).
Well, in some sense what happens with “smart“ indentation features in editors is anything but consistent (I know I'm not talking about the same consistency here), because they only ever make an exception for the backspace key to remove N spaces – in some cases. An arrow key only ever moves one space at a time and a delete doesn't ever remove N spaces and you can still land in the middle of an indentation level either with arrow keys or with your mouse cursor, etc..
And to make matters worse, the way the backspace key works isn't even always what you want; say you try to align something and happen to press space one time too many: in many editors pressing a backspace there doesn't fix your problem but only makes it worse...
In the editor I use, for any line containing whitespace the backspace takes me back to the previous indent point and the backspace only works as a single backspace for lines that contain visible text.
It doesn't matter just use the language convention, in python it's spaces in c it might be tabs.
It really doesn't matter.
My only pet peeve with spaces is people will occasionally use a number that is not a multiple of the indentation to align things with the text in the previous line. I find it unpleasant(harder) to read such code.
I dunno. When I automatically convert code from tabs to spaces, the end result seldom needs any revision. Going the other way almost always reveals a couple lines where the coder used an inconsistent number of spaces for no discernible reason.
That's like saying people who use "import" clauses make more money than those who use "requires" clauses.
I don't even know why this is a discussion, if ASCII has a character that represents an indent, we might as well use it (unless you prefer typing & as Et, < as LessThan, etc)
That being said, yes, using spaces for arbitrary alignment is easier
So there must be a confounder. What could it be?
- Do the top schools all instruct students to always use spaces? This should have been partly taken care of when the author controlled for level of education though, right?
- Choice of editor? This seems like a weird one, but editor defaults are definitely linked to tabs vs spaces, and the survey didn't even collect data on this.
- Starting language?
- Total number of languages used? Spaces are tolerable in more languages than tabs are. Of course, I'd expect "both" to beat "spaces" if this was the case.
None of these strikes me as particularly plausible, except maybe the last one. This result is kind of bothersome, because it's big, obviously not a statistical fluke, and hard to understand.
EDIT: a past thread (https://news.ycombinator.com/item?id=20719010) suggested that some higher paying companies mandate spaces. This also seems plausible.