Live data from Hacker News

Developers who use spaces make more money than those who use tabs

stackoverflow.blog

631–640 of 690 posts

Re: Developers who use spaces make more money than those who use tabs

#631
post #358

Earlier quoted context omitted.

> The reason I use tabs is pretty simple. It's faster to move around only using the keyboard. Well, yes, if you use the arrow keys (unmodded) and nothing else. But who does that? Even Notepad lets you jump from word to word with CTRL-left/CTRL-right. Sublime Text must have something similar, surely?

On OSX, in Sublime Text: - CMD with arrow keys moves to line ends - Alt with arrow keys moves between words - Ctrl, under some circumstances, lets you operate on parts of a camelCased or snake_cased word (with backspace and with shift + arrow keys, but not with arrow keys all by themselves) It's the best setup for moving around code that I've encountered.

I like vims better to be honest. More granularity, and I can stay on home row instead of moving my hand to and from the arrow keys.

Re: Developers who use spaces make more money than those who use tabs

#632
post #452

Earlier quoted context omitted.

> Whats wrong with this? I just accept the defaults. Whether that is what the current project demands or what the editor defaults to. There's your answer: if letting your editor do whatever and not caring to 'waste time over these things' means you've committed a bunch of code ignorant of the convention respected by the rest of the project, that's not that great.

I did say "what the current project demands". I did not say "I just push whatever I feel like". Again, I don't see the problem with not caring and just going with what others have picked.

Yes, sorry, I meant that you answered your own question when you said that.

Re: Developers who use spaces make more money than those who use tabs

#633

Earlier quoted context omitted.

If you're looking for efficiency for text navigation/editing you should consider learning vim/using vim mode in your editor.

Every editor made for coding supports moving through whitespace with a single command.

Problem is that moving from and to the arrow keys to navigate is an anti-pattern that is not present in at least vim where you can stay on home row at all times, which is why I dread having to write in editors that don't support a vim mode.

Re: Developers who use spaces make more money than those who use tabs

#634

Almost certainly a result of the spaces cabal and the (often unspoken of) prejudice against tab users. Don't think you make hiring decisions based on tabs vs spaces? Well you're part of the problem, then. I'm building an app to help you easily email your congressperson and ask them to create legislation requiring space/tab equality. This has to stop. Please consider donating to my Patreon.

> Don't think you make hiring decisions based on tabs vs spaces? I actually ask candidates "spaces or tabs?" in every single interview. I don't really care what the response is in regard to the holy war, and it doesn't mean anything on its own, but having SOME thought out response can be a GREAT indicator of how well versed someone is in general. e.g. I'm going to think way more highly of someone that says "tabs, bec…

My life is easy. https://www.drupal.org/docs/develop/standards/coding-standar... "Use an indent of 2 spaces, with no tabs." Anyone writing custom code with a different coding style than the ecosystem they rely is a fool so that's decided for me.

If my dreams come true I will work with Elixir next. https://github.com/christopheradams/elixir_style_guide#space... "Use two spaces per indentation level. No hard tabs." See, this is why I like Elixir, I do not need to change my spacing habits from Drupal! :D

Re: Developers who use spaces make more money than those who use tabs

#636
post #310

Earlier quoted context omitted.

> Don't think you make hiring decisions based on tabs vs spaces? I actually ask candidates "spaces or tabs?" in every single interview. I don't really care what the response is in regard to the holy war, and it doesn't mean anything on its own, but having SOME thought out response can be a GREAT indicator of how well versed someone is in general. e.g. I'm going to think way more highly of someone that says "tabs, bec…

Does spending time considering the implications of spaces vs tabs really indicate competence? To me being over-obsessed with minor details might be either negative or at most neutral value. There are thousands of interesting programming subjects to initiate a conversation to evaluate competency. At most it's a matter of what tools you use as well as accepted standards in the individual programming language's communit…

Exactly. One's ability to allocate their most precious resource is probably the greatest signifier of competence, and vice versa, incompetence.

Re: Developers who use spaces make more money than those who use tabs

#637

Earlier quoted context omitted.

Could well be. I know that Google for sure requires spaces, and some cursory Googling leads me to the believe that Facebook does as well. Does anyone have information on Amazon, Microsoft, Apple, etc.? Of course, if all of the top companies are requiring spaces, then there's probably a reason for that, and its impact on salary data is thus meaningful, not just a spurious correlation.

Don't work there, but I know that Apple tends to use spaces for their public-facing code–I'd expect that their internal code does too.

It's sounding like all the top tech companies use space-based indentation. Our style guide makes some pretty convincing arguments as to why it's better. It sounds like good developers are either more likely to (a) work at top companies or (b) search out information on best practices for handling indentation. Mediocre developers probably just use whatever, which ends up being tabs a lot of the time.

Re: Developers who use spaces make more money than those who use tabs

#638
post #207

Earlier quoted context omitted.

> when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc. This is an argument I hear often from tab proponents. What it misses out is the downside: my IDE has a certain arrangement on my screen, and I'll either have to invoke horizontal scrolling or I'll have a bunch of wasted space if you are using different size tabs from me. This is far from fle…

> if you are using different size tabs from me. But the point of tabs is that you tell your editor how many spaces wide you want them to be, so unless I'm misunderstanding you, this is not an issue. As for lining things up, tabs are used for the indentation level of the current line, but if you need to further nudge things within that line then you'd of course use spaces (after the initial tab indent).

Assume you want to eliminate horizontal scrolling. This is a valuable enough goal that a lot of coding style guides have a width guideline. That keeps everybody from having to make their editor windows as wide as the last person who worked on the code.

If this arrangement is working, nobody has to scroll horizontally, and there is no arms race of ever-wider editor windows.

Now introduce tabs into this situation. In theory I can set tabs to be whatever size I like. But in practice, I can't make them wider than the last person who worked on the code, because then I'm back to horizontal scrolling. Moreover, if I make them narrower, then they have to narrow their tabs to keep pace. So you get an arms race of tab- narrowing instead of window widening.

I just want to code. I don't want to scroll horizontally, or constantly mess with my window width and/or tab settings to avoid that. It's extra work that doesn't accomplish anything.

Re: Developers who use spaces make more money than those who use tabs

#639
post #343

Earlier quoted context omitted.

> Further, the only sensible screen width is 80 characters, since that also works everywhere. I'm curious. Where does 80 characters not work now? How many people / industries are still using green-screen terminals with a fixed-width of 80 characters? I'm generally in favour of enforcing line-wrapping requirements, because I've worked with people that would have a tendency to write code that trails off the end of the…

> but other than "it's everywhere" is there a more solid reason? IMO you'd need a pretty good reason not to use the de facto standard, even if it's arbitrary. IIRC it has something to do with the width of teletypes

I know that it has to do with the width of older terminals, perhaps even back to the teletypes. But those hard restrictions don't exist anymore, yet some people treat "80 characters" as some golden law passed down from heaven that cannot be broken lest you incites the wrath of the gods. That kind of fervour (without some sort of concrete, logical reasoning) is nothing but cargo-cultism so far as I'm concerned. E.g. "we do it this way because it's always been done this way."

Re: Developers who use spaces make more money than those who use tabs

#640
post #623
post #343

Earlier quoted context omitted.

> Further, the only sensible screen width is 80 characters, since that also works everywhere. I'm curious. Where does 80 characters not work now? How many people / industries are still using green-screen terminals with a fixed-width of 80 characters? I'm generally in favour of enforcing line-wrapping requirements, because I've worked with people that would have a tendency to write code that trails off the end of the…

> But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done." Having shorter lines makes reading diffs easier (whether it's unified, context, or split diffs). > The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters. It's actually 72 characters for the commit message body for a sim…

> Having shorter lines makes reading diffs easier (whether it's unified, context, or split diffs).

But is the difference that significant between 80-, 100- and (say) 120-characters wide? I personally wrap at 100 characters, I don't find that I'm fatigued by looking at diffs of the code.

Post reply on HN