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.
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.
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.
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.
> 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...
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.
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".
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.
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.
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.
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.
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
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
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.
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.
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.
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 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.
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 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.
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.
- 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
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":
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).
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 ?
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.
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.
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.
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:
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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,
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.
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/).
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 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.
> 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:
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.
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?
261 comments
[ 0.32 ms ] story [ 263 ms ] threadMy 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.
Tabs, however, are superior - everyone can use the 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...
After fixing a couple of mixed tabs/space files back in the glory MS-DOS days, I became a space zealot.
Apparently it was a good decision.
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.
I rather keep using spaces, like I have been doing since 1992, plus apparently it reflects on salary.
But in practice, any combination of tabs and spaces will look wrong for someone.
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.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size
With testing and code auto formatting pipelines already in place, this isnt a problem
It's one line in a githook for this to really be true.
[1] https://news.ycombinator.com/item?id=14560042
[2] https://news.ycombinator.com/item?id=20718031
There is no other sane way
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
[1] https://termbin.com/qzwzy
Or in other words: I know who's pulling down the average because it's me.
I guess 99% of the arguments around tabs or spaces are wrong.
I use spaces because that's common in Python, which is the first language I learned and because I saw some bad codebases that mixed tabs and spaces.
But I don't think it matters. The only thing that matters is consistency.
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...
i'm sitting behind visual studio, which requires backspacing through.
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.
That's my 100% unscientific, non-evidence based guess.
There are good reasons for using tabs. I am still to find a good reason for using spaces.
Just the first few that come to mind.
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!
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.
but viewing that code with anything other than the tab length it was written for breaks it !
here are some screenshots:
- I wrote the code with ts=4 and it looks as it must look: https://imgur.com/Bgr6Pvl
- if your editor is configured for two spaces tabs ? broken ! https://imgur.com/oxj2If7
- if your editor is configured for eight spaces tabs ? broken ! https://imgur.com/puCqdL8
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.
I just reply to the comment text
> 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)
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":
https://www.theguardian.com/stage/2005/sep/29/comedy.religio...
That's us!
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...
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.
From the fact that with exception of languages with significant whitespace/tab it's a matter of visual representation:
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).
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.
Edit-typos
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 ?
Then that's a bad example since this alignment with preceding line style commits you irregardless of your history with any function.
> I don't understand what you mean there, what would "aligning connect with foo" mean ?
If you are aligning with lines above you and your coworkers have so many options:
If you are nesting with fixed indents, then everything is fairly well defined and simple changes to one line don't cause significant reflow.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.
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.
I have never experienced this. Tabs are of consistent length, so how can the indentation be garbled?
There can still be alignment issues if different people choose different tab-stop intervals.
The problem is not the tabs, instead it stems from trying to mix lines indented with tabs and lines indented with spaces.
https://github.com/rome/tools/issues/425
(Especially look at the Reddit thread linked from that issue: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t... )
(The problem is that people with visual impairment disabilities benefit a lot from being able to customize tab widths.)
If tabs-as-whitespace trouble you, editors since the 1990s have allowed you to choose/configure other representations of tabs.
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.
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.
I didn't claim as such - I'm just contesting your claim that using tab for indentation is an "abuse" because it's "for aligning columns in a table".
Space bar is our chisel, to craft beautiful codes and reassure our mammal brain that being in the zone make us closest to god
I use Tab (the key) for indentation, but I have my editors configured to enter spaces and not tabs.
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
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.
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.
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.
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.
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.
is one (or some) high paying companies coding practices skewing the results?
a) More smart
b) More correct.
It is not that complex.
Also they are more likely to be using emacs, another big win.
For one example of something that wouldn't work with tabs (although not my original point, see the whitespace between `key:` and `key,` on line 66 here: https://github.com/rails/rails/blob/main/actionmailbox/app/c...
For an example closer to my original point, see line 13 here: https://github.com/heartcombo/devise/blob/master/app/control...
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.
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...
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.
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:
``` helpers = %w(resource scope_name resource_name signed_in_resource resource_class resource_params devise_mapping)
helpers.each do |h| puts h end
$ ruby test.rb resource scope_name resource_name signed_in_resource resource_class resource_params devise_mapping ```
Apologies if the HN markdown sytax means this get mangled, no idea if it'll take fenced code blocks but you get my drift.
[1] https://github.com/ioquatix/universal-style-guide#indentatio...
[2] https://github.com/ioquatix/rack-freeze/issues/2#issuecommen...
Edit: It did get mangled :/ there's a newline and then plenty of tabs in there. Worked like a charm.
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.
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?