[HN Gopher] Developers Who Use Spaces Make More Money Than Those...
___________________________________________________________________
Developers Who Use Spaces Make More Money Than Those Who Use Tabs
(2017)
Author : aminozuur
Score : 106 points
Date : 2021-05-17 07:55 UTC (15 hours ago)
(HTM) web link (stackoverflow.blog)
(TXT) w3m dump (stackoverflow.blog)
| avipars wrote:
| What about IQ
| pitched wrote:
| 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.
| mosselman wrote:
| Is 'lazy' the correct term then? Shouldn't it be 'more
| efficient'? By looking at the rest of your analysis anyway.
| pitched wrote:
| 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.
| finalight wrote:
| so in a way, the lesser i do, the more i get paid?
| nottorp wrote:
| This has been posted before.
|
| 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.
| [deleted]
| gjulianm wrote:
| 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.
| xdrosenheim wrote:
| This is clearly because people who use spaces, lie about their
| income.
| m463 wrote:
| Maybe they pad their paycheck and their files.
| bguebert wrote:
| maybe they get paid per character typed
| postalrat wrote:
| They put what they think they are worth.
| FriedrichN wrote:
| Perhaps they compare their productivity with their colleagues
| based on the size of their code in bytes. find
| -type f -name *.EXT -exec du -cb {} + | grep total
| tffgg wrote:
| My editor and IDEs convert tabs to spaces...
| orangepanda wrote:
| No one actually presses spacebar 4 or 8 times...
|
| Tabs, however, are superior - everyone can use the indentation
| they prefer without causing conflicts.
| mosselman wrote:
| > 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...
| eloisius wrote:
| 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.
| cjfd wrote:
| That is why one should use tabs for indentation and spaces
| for alignment. Then this problem does not occur.
| throwawayffffas wrote:
| 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.
| pjmlp wrote:
| 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.
| j1elo wrote:
| 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".
| kstenerud wrote:
| 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.
| eloisius wrote:
| 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.
| pjmlp wrote:
| In theory, assuming the files are always opened by the same
| tool and no one ever types a single space instead of a tab.
|
| 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.
| globular-toast wrote:
| 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.
| pjmlp wrote:
| If one needs to be force fed to appreciate them, that
| already shows how much of a problem they are.
| globular-toast wrote:
| Children need to be forced to learn to read and write.
| pjmlp wrote:
| So using spaces is being illiterate.
| globular-toast wrote:
| Not necessarily, but I am arguing that most people are
| tab illiterate. Things that are worth learning are rarely
| easy/obvious.
| pjmlp wrote:
| 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.
| m463 wrote:
| If it were all tabs or all spaces, that could theoretically
| work.
|
| But in practice, any combination of tabs and spaces will look
| wrong for someone.
| Tade0 wrote:
| The indentation I use cannot be expressed through tabs,
| unless they're of width 1, which defeats the purpose.
| AlexSW wrote:
| 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.
| Tade0 wrote:
| If you're using indentation to e.g. align method
| parameters then no, tabs would just make a mess out of
| it.
| j1elo wrote:
| 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.
| withinboredom wrote:
| 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.
| orangepanda wrote:
| > 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
| gsich wrote:
| I don't care how it looks on other computers. This is a
| problem of the user of that other computer.
| _pgon wrote:
| So you don't care how readable your code is?
| gsich wrote:
| It's readable. If you set your tabs to width 0 or 10 it's
| not my problem. And not a readability problem on my part.
| brigandish wrote:
| There's always the CSS tab-size property[1] if you don't
| like the default width (and who would, it's huge!)
|
| [1] https://developer.mozilla.org/en-US/docs/Web/CSS/tab-
| size
| BelenusMordred wrote:
| > everyone can use the indentation they prefer without
| causing conflicts
|
| It's one line in a githook for this to really be true.
| strogonoff wrote:
| 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.
| srl wrote:
| 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.
| Stranger43 wrote:
| 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.
| renewiltord wrote:
| 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)"
|
| A.k.a The Market Hates Bikesheds
| benrbray wrote:
| Probably needs a (2017). Past discussion [1,2].
|
| [1] https://news.ycombinator.com/item?id=14560042
|
| [2] https://news.ycombinator.com/item?id=20718031
| aminozuur wrote:
| Thanks, I've added (2017).
| mclightning wrote:
| Developers who are not stuck on the argument of this duality are
| making even more.
| jl2718 wrote:
| Not true. The article points out that they are paid the same as
| the tabbers.
| tmccrary55 wrote:
| What about people who use tabs and spaces?
| orangepanda wrote:
| Yes! Tabs for indentation, and spaces for alignment.
|
| There is no other sane way
| eMSF wrote:
| Unfortunately, most editors support that "workflow" very
| poorly.
| red2awn wrote:
| I hope you configured soft tabs...
| mnd999 wrote:
| Hopefully they code in Whitespace -
| https://en.m.wikipedia.org/wiki/Whitespace_(programming_lang...
| lioeters wrote:
| There's a special circle in hell for such people.
| trog wrote:
| Is there a group of developers somewhere that charge per byte of
| code they write?
| totalZero wrote:
| I'm surprised they didn't normalize for age, which is correlated
| with income up to a certain point and then drops off.
| argvargc wrote:
| Most plausible explanation so far; a generation gap.
| raverbashing wrote:
| 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
| isitdopamine wrote:
| 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.
| mnd999 wrote:
| What about developers who follow the coding standards because
| they value consistency over personal preferences?
| zelphirkalt wrote:
| But how do they write makefiles? _hard thinking face_
| matbatt38 wrote:
| Maybe they don't and that's why they make more money
| ybbond wrote:
| 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?
| Gibbon1 wrote:
| What would be better would be formatting as a display setting
| in whatever IDE you're using.
|
| There debate settled permanently.
| King-Aaron wrote:
| Correlation and Causation something something
| dang wrote:
| Some past threads:
|
| _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)
| Ballas wrote:
| 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.
| maury91 wrote:
| Joke: Devs are paid by how many buttons they press, devs who use
| spaces press the spacebar a lot!
| thejosh wrote:
| do you know any devs who use spaces who press space 2-4 times
| instead of their tab key that indents it 2-4 spaces?
| maury91 wrote:
| Honestly no, but it's a joke, doesn't need to be 100% true
| globular-toast wrote:
| People use the tab key? Emacs automatically indents to the
| correct level and has done for decades I assume.
| gpderetta wrote:
| right, and I would expect most editors to indent
| automatically these days. Do people really routinely indent
| code by hand?
| withinboredom wrote:
| 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.
| tasuki wrote:
| Why not use editorconfig? https://editorconfig.org/
| fps_doug wrote:
| 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.
|
| [1] https://termbin.com/qzwzy
| est31 wrote:
| 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.
| traceroute66 wrote:
| Surely this nonsense is a textbook example of statistical
| overfitting ?
| blackbear_ wrote:
| Hard to overfit a median.
| thanatos519 wrote:
| Tabs ... of acid? :-P
| elihu wrote:
| 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.
| jcelerier wrote:
| The effect stays true within a language, C programmers with
| spaces are paid more than C programmers with tabs
| fps_doug wrote:
| This is the first thing that came to my mind: Different
| languages have different traditions/defaults here, and might
| correlate stronger with salaries.
| d--b wrote:
| Wait, there are still people who use tabs?
| smallstepforman wrote:
| Yes, there are millions of us. When you need to backspace you
| immediately appretiate pressing the backspace key once instead
| of 4 times (or more).
| turbinerneiter wrote:
| That's not how this works in any editor or IDE.
|
| 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.
| eMSF wrote:
| 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...
| jussij wrote:
| This will depend on the editor used.
|
| 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.
| tokai wrote:
| Ctrl+Backspace deletes all the spaces in one go.
| FriedrichN wrote:
| 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.
| gjulianm wrote:
| Why couldn't it be that the people who use spaces are the ones
| with stronger principles?
| DocTomoe wrote:
| Principles are founded in reason.
|
| There are good reasons for using tabs. I am still to find a
| good reason for using spaces.
| _old_dude_ wrote:
| It's easy to forget that programming is an art and being
| soul crushed by the business side of it.
|
| Space bar is our chisel, to craft beautiful codes and
| reassure our mammal brain that being in the zone make us
| closest to god
| mlang23 wrote:
| 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.
| Zarel wrote:
| 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:
|
| https://github.com/rome/tools/issues/425
|
| (Especially look at the Reddit thread linked from that
| issue: https://www.reddit.com/r/javascript/comments/c8drj
| o/nobody_t... )
|
| (The problem is that people with visual impairment
| disabilities benefit a lot from being able to customize
| tab widths.)
| DocTomoe wrote:
| - 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
|
| Just the first few that come to mind.
| hnedeotes wrote:
| 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!
| jcelerier wrote:
| That does not work in practice. Consider
| void foo() { connect(this, action,
| that, callback); }
|
| 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 ??
| eMSF wrote:
| 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.
| jcelerier wrote:
| > 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...
|
| 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
| eMSF wrote:
| 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.
| jcelerier wrote:
| > Why are you writing this to me?
|
| 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)
| mlang23 wrote:
| 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.
| giardini wrote:
| 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":
|
| https://www.theguardian.com/stage/2005/sep/29/comedy.reli
| gio...
|
| That's us!
| hnedeotes wrote:
| 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...
| jcelerier wrote:
| > 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.
| hnedeotes wrote:
| > where does this assumption come from ?
|
| 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);
| }
|
| 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).
| foolmeonce wrote:
| 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.
|
| Edit-typos
| jcelerier wrote:
| > 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 ?
| foolmeonce wrote:
| > from experience ?
|
| 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(
|
| If you are nesting with fixed indents, then everything is
| fairly well defined and simple changes to one line don't
| cause significant reflow.
| benrbray wrote:
| 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. void foo() {
| connect( this, action
| that, callback ); }
|
| 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? :-)
| jcelerier wrote:
| > 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.
| postalrat wrote:
| If it's not using my preference for the size of a tab
| then it's broken.
| junon wrote:
| It's really not hard to understand...
|
| 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.
| dangerface wrote:
| void foo() { connect(this, action,
| that, callback); }
|
| problem solved.
| FriedrichN wrote:
| > garbled alignment when reading a diff of a file which
| used tabs to indent
|
| I have never experienced this. Tabs are of consistent
| length, so how can the indentation be garbled?
| Aaargh20318 wrote:
| Tabs are not of consistent length. A tab does _not_
| insert X spaces worth of whitespace. A tab moves the
| cursor to the next tab-stop.
|
| There can still be alignment issues if different people
| choose different tab-stop intervals.
| FriedrichN wrote:
| That's why tabs are used for indentation and not
| alignment. From col 0 on tabs are consistent.
| CannisterFlux wrote:
| 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.
| rrrazdan wrote:
| 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.
| DocTomoe wrote:
| 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.
| rrrazdan wrote:
| 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.
| dTal wrote:
| 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.
| rusk wrote:
| 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.
| dTal wrote:
| I'd say they're "for" whatever we want. Nowadays they're
| far more widely used for semantic indent than for tabular
| alignment.
| rusk wrote:
| Sorry I misunderstood you, I thought you were making the
| argument that spaces aren't for indentation.
| treesprite82 wrote:
| > 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.
| rusk wrote:
| 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.
| treesprite82 wrote:
| > and you can't make any strong argument that it's what
| tab is "for" based on original purpose
|
| 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".
| rusk wrote:
| That's fine. You're supporting my point in that case.
| mousepilot wrote:
| 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
| dangerface wrote:
| 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.
| rusk wrote:
| Here was I thinking "tab" was for "tables"
| TomSwirly wrote:
| Because if I use spaces I know exactly how my code will
| look on every output device, whereas if I put in tabs, I am
| at the merge of the viewer.
| FriedrichN wrote:
| If you believe very strongly that indentation should be >1
| char then that is entirely possible.
| andyxor wrote:
| 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
| alias_neo wrote:
| There's a point I want to clarify. When we say tabs and spaces
| do we mean using Tab vs Space or not?
|
| I use Tab (the key) for indentation, but I have my editors
| configured to enter spaces and not tabs.
| phist_mcgee wrote:
| Tab character vs spaces characters is the debate, not the
| manner in which they are inputted
| alias_neo wrote:
| 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
| masonj188 wrote:
| Gofmt rewrites spaces to tabs
| alias_neo wrote:
| 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.
| professoretc wrote:
| I'm not familiar with the standard Go coding style. Does
| it correctly handle the case mentioned above, where you
| have a function call like
| connect(option1, option2,
| option3);
|
| That is, will the spaces from the column `connect` starts
| in be preserved as spaces, or will they be converted to
| tabs?
| gspr wrote:
| It is generally understood to be the tab character, not the
| tab key.
| abcdasfwe wrote:
| i'm a python dev, and i don't agree with this
| srl wrote:
| 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.
|
| EDIT: a past thread
| (https://news.ycombinator.com/item?id=20719010) suggested that
| some higher paying companies mandate spaces. This also seems
| plausible.
| shinryuu wrote:
| My qualified guess is that PHP developers overall tend to use
| tabs more, and PHP developers are generally paid less on
| average.
| srl wrote:
| 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.
| bradlys wrote:
| 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.
| jcelerier wrote:
| 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 ?
| johnisom2001 wrote:
| > 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.
| tom_mellior wrote:
| > 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.
| mfbx9da4 wrote:
| Correlation does not imply causation but very fun title!
| iamgopal wrote:
| Which should be the correct way ? Space or Tabs ?
| throwawayffffas wrote:
| 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.
| diegoperini wrote:
| Neither. Consistency among team members is the correct way.
| blarg1 wrote:
| What if I use both?
| iovrthoughtthis wrote:
| where do all the people who use spaces work?
|
| is one (or some) high paying companies coding practices skewing
| the results?
| mikewarot wrote:
| [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?
|
| Reference: https://theasciicode.com.ar/ascii-control-
| characters/vertica...
| mvolfik wrote:
| My guess is that lf/crlf is just a proxy for windows/linux
| comparison
| wavegeek wrote:
| This is because they are
|
| a) More smart
|
| b) More correct.
|
| It is not that complex.
|
| Also they are more likely to be using emacs, another big win.
| uniqueid wrote:
| 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.
| nyuszika7h wrote:
| 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.
| yummybear wrote:
| Are there languages that lend themselves more to space-
| indentation? That could explain the wage gap.
| throwawayffffas wrote:
| The convention in python is space-indentation.
| boffinism wrote:
| 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.
| brigandish wrote:
| Do you have an example? I write Ruby and switched to tabs a
| while ago, haven't noticed any problems.
| boffinism wrote:
| 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/).
|
| 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...
| boffinism wrote:
| See also the first "good" example at
| https://github.com/rubocop/ruby-style-guide#no-double-
| indent, and the placement of 'from' in it
| throwawayffffas wrote:
| In my book the third example is also bad, only the simple
| indentation is good.
| brigandish wrote:
| 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.
| boffinism wrote:
| 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...
| brigandish wrote:
| > 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.
| eMSF wrote:
| 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): def
| send_mail(source) TABMailer.deliver(to:
| 'bob@example.com', TAB from:
| 'us@example.com', TAB subject:
| 'Important message', TAB body:
| source.text) end
|
| Here, TAB has a width of three but of course the
| alignment would stay put even if it were wider or
| narrower.
| jcelerier wrote:
| Such a good argument against tabs. Spaces don't need all
| these shenanigans.
| brigandish wrote:
| > 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:
|
| ``` 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.
| vishnugupta wrote:
| Maybe the causality is inverted?
|
| 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.
| eckesicle wrote:
| 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?
| jl2718 wrote:
| 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!
| armatav wrote:
| This is unironically the true story. Never forget.
| Cerebrum1234 wrote:
| Programmers who use spaces 'paid more'* Computer programmers who
| use spaces as part of their coding earn.
| u801e wrote:
| 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.
| Yizahi wrote:
| 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.
| tapland wrote:
| Oh yes.
|
| 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.
| Yizahi wrote:
| 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).
| tapland wrote:
| 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.
| jakub_g wrote:
| 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.
| mg wrote:
| 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.
| 0-_-0 wrote:
| 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.
| mjsir911 wrote:
| > Out of the box, VIM has no easy way to colorize tabs.
|
| From my vimrc: set list
| listchars=tab:>-
|
| It's not colorizing, but will list out a tab character as
| `>---`
|
| Not exactly sure what you mean by "show list" but I believe you
| can append to `listchars` whatever nonprintable character
| formatting you want
| cryptica wrote:
| 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...
| benrbray wrote:
| > 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.
| cryptica wrote:
| 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.
| benrbray wrote:
| 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?
| Symbiote wrote:
| I would do the same, but it's unfortunately becoming more
| common for code formatting to be enforced with plugins,
| GitHub actions etc. start = getData( 0,
| 0) middle = getData( 50, -50) end =
| getData(100, -100)
|
| I would also exceed the line limit, if the arguments to
| only 1 of these lines are a bit longer. But apparently we
| now have to live with this: start =
| getData(0, 0, 0, 0) middle = getData(50000, -50000,
| 50000, -50000) end = getData(100000, -100000,
| 1000000, -100000)
|
| (I have, completely accidentally, an extra zero in this. It
| would be easier to spot if it were aligned.)
| [deleted]
| Firadeoclus wrote:
| 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.
| samatman wrote:
| Don't agree, here's why: -- this comment is
| on the margin, the code is indented
| youCantDo("this kind of", "function
| parameter", "mixing tabs and spaces")
| acuozzo wrote:
| Yes, you can.
|
| The three lines of code all start with exactly one tab. The
| second two lines each have 10 spaces after their initial tab.
| samatman wrote:
| Great so I'm using two kinds of invisible character in a
| pointlessly difficult way... why, exactly?
|
| Can you write a linter for this which doesn't contain a
| complete parser for your language?
| junon wrote:
| > invisible character
|
| 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.
| alex_smart wrote:
| But which editor has support for that?
|
| 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.
| junon wrote:
| I've been doing it for ~10 years in vim without a single
| issue.
| tasuki wrote:
| I don't get why people do that. It's ugly, and it breaks when
| the `youCantDo` name changes. youCanDo(
| "this kind of", "function parameter",
| "with just tabs" )
| samatman wrote:
| Ugly is subjective.
|
| 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.
| twinkletwinkle_ wrote:
| 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.
| u801e wrote:
| But it does make for more compact and easier to read
| diffs.
| dangerface wrote:
| Don't agree, here's why: -- this comment is
| on the margin, the code is indented
| youCantDo("this kind of", "function
| parameter", "mixing tabs and spaces")
| samatman wrote:
| No idea what you tried to do here, but this doesn't line up
| properly.
|
| Fix it and I'll merge: except I wouldn't see it because CI
| won't pass code with tabs in it.
| tom_mellior wrote:
| > Out of the box, VIM has no easy way to colorize tabs.
|
| This is slightly simplified from my .vimrc:
| highlight ExtraWhitespace ctermbg=darkred match
| ExtraWhitespace /\t/
|
| It will highlight any tab in dark red.
|
| (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.
| hankchinaski wrote:
| Chocolate consumption per capita is positively correlated with
| the stock of Nobel prizes per capita [0]
|
| [0]
| https://www.sciencedirect.com/science/article/pii/S259029112...
| jcelerier wrote:
| 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 ?
| globular-toast wrote:
| I'm someone who uses spaces, but knows I should be using tabs.
|
| 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.
| thenoblesunfish wrote:
| Do employers who tend to pay more (e.g. Google) tend to have
| style guides which encourage spaces over tabs?
| Threeve303 wrote:
| This is why early languages had no white space at all. /s
| paulolc wrote:
| 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.
|
| [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
| will4274 wrote:
| 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.
| alephnan wrote:
| Because Google engineers use spaces, even after they leave Google
| kstenerud wrote:
| 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.
| dTal wrote:
| > tabs... are invisible
|
| I highly recommend using an editor which renders them as
| distinct glyphs, or enabling that function in your editor of
| choice.
| garmaine wrote:
| Great. Now get everyone else who touches your codebase to do
| the same.
| tasuki wrote:
| > It's easy to adapt to the house rules, and the benefits
| outweigh the headaches.
|
| This applies even to tabs.
| kstenerud wrote:
| ... except for the problems listed above
| dangerface wrote:
| 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.
| kstenerud wrote:
| I just use the editor's CMD-[ and CMD-] or tab and shift-tab
| indentation commands. You can also apply it to entire blocks.
| alpaca128 wrote:
| > 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.
| cryptica wrote:
| 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.
| kstenerud wrote:
| I've seen it used to great effect for describing code
| sections, either using ASCII diagrams, tables, sample output,
| etc.
|
| The point is, formatted monospace text will happen (albeit
| rarely), and when it does you want it to remain intact
| despite user settings.
| alpaca128 wrote:
| > 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.
| ensiferum wrote:
| Aligning stuff is awesome for multiline editing however.
| Which happens more than one night think!
| stinos wrote:
| How so? I.e. in what situation multiline editing works less
| good when things aren't aligned?
| CRConrad wrote:
| 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"?
| cryptica wrote:
| 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.
| junon wrote:
| 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).
___________________________________________________________________
(page generated 2021-05-17 23:01 UTC)