Developers Who Use Spaces Make More Money Than Those Who Use Tabs (2017)
stackoverflow.blog
stackoverflow.blog
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.
- 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.
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.
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"?
The point is, formatted monospace text will happen (albeit rarely), and when it does you want it to remain intact despite user settings.
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.
I highly recommend using an editor which renders them as distinct glyphs, or enabling that function in your editor of choice.
Do you have any other code editor visual customization tips you'd recommend for a better experience?
This applies even to tabs.
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 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.
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.
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.
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 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.
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.
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?
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.
start = getData( 0, 0)
middle = getData( 50, -50)
end = getData(100, -100)
start = getData(0, 0, 0, 0)
middle = getData(50000, -50000, 50000, -50000)
end = getData(100000, -100000, 1000000,
-100000)
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.
But it's 15 years since that was proposed.
-- this comment is on the margin, the code is indented
youCantDo("this kind of",
"function parameter",
"mixing tabs and spaces") -- this comment is on the margin, the code is indented
youCantDo("this kind of",
"function parameter",
"mixing tabs and spaces")Fix it and I'll merge: except I wouldn't see it because CI won't pass code with tabs in it.
youCanDo(
"this kind of",
"function parameter",
"with just tabs"
)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.
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.
The three lines of code all start with exactly one tab. The second two lines each have 10 spaces after their initial tab.
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.
Can you write a linter for this which doesn't contain a complete parser for your language?
Which respectable text editor in 2021 doesn't have an option to show whitespace?
> Can you write a linter for this
Every linter uses a "complete parser", else it wouldn't be a linter.
From my vimrc:
set list
listchars=tab:>-
Not exactly sure what you mean by "show list" but I believe you can append to `listchars` whatever nonprintable character formatting you want
This is slightly simplified from my .vimrc:
highlight ExtraWhitespace ctermbg=darkred
match ExtraWhitespace /\t/
(My actual .vimrc uses /\t\| \+$/ to also highlight extra spaces at the ends of lines.)
I hate (and am confused by) pretty much everything about vimscript, but this particular snippet is actually surprisingly clear.
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.
find -type f -name *.EXT -exec du -cb {} + | grep totalOr in other words: I know who's pulling down the average because it's me.
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 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.
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!
void foo() {
connect(this, action,
that, callback);
}
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:
void foo() {
connect(this, action,
that, callback);
}
> 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:
void foo(..
connect(..
int foo(..
connect(..
int foo(..) {
connect(
void foo() {
connect(
this, action
that, callback
);
}
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.
void foo() {
connect(this, action,
that, callback);
}
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
connect(option1,
option2,
option3);
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.
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.
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.
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.
[1] Nobody talks about the real reason to use Tabs over Spaces https://news.ycombinator.com/item?id=20381027 https://news.ycombinator.com/item?id=20341354)
Previous threads https://news.ycombinator.com/item?id=20381027 https://news.ycombinator.com/item?id=20341354
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.
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.
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?
There debate settled permanently.
until you have to review the code on SaaS Git host site
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?
Reference: https://theasciicode.com.ar/ascii-control-characters/vertica...
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.
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.
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).
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.
Developers Who Use Spaces Make More Money Than Those Who Use Tabs (2017) - https://news.ycombinator.com/item?id=20718031 - Aug 2019 (148 comments)
Developers who use spaces make more money than those who use tabs - https://news.ycombinator.com/item?id=14560042 - June 2017 (663 comments)
In other sad missed opportunities, see the ASCII delimiters: https://en.wikipedia.org/wiki/Delimiter#ASCII_delimited_text
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.
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.
[0] https://www.sciencedirect.com/science/article/pii/S259029112...
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...
def send_mail(source)
TABMailer.deliver(to: 'bob@example.com',
TAB from: 'us@example.com',
TAB subject: 'Important message',
TAB body: source.text)
end
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.
A.k.a The Market Hates Bikesheds
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!
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.
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.
I very strongly suspect that it was historically the exact opposite.
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.
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.
There is no other sane way
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.
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