Live data from Hacker News

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

stackoverflow.blog

641–650 of 690 posts

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

#641
post #318

Earlier quoted context omitted.

You think you are doing others a favor by using tabs, but in fact you are creating a hassle instead. When I open your tabbed code the first thing I have to do is run it through some script that replaces all tabs with spaces, so that the files will be formatted the same way as the rest of the code base.

Some script? You mean the built in Unix utility 'expand'? Supposing I submitted code indented with spaces, but the wrong number. Would making the formatting match be easier, or harder? Maybe you should just use tabs in your codebase.

Maybe you should use the right number of spaces in your codebase.

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

#642

Earlier quoted context omitted.

> 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 t…

I am genuinely baffled (but I don't think I'm right and you're wrong... I trust HN people to be smart and capable). Can you please explain to me how using tabs vs spaces would encourage people to indent their code differently? I mean, if I have an "if" statement, then I indent my code -- but why would people indent their code for reasons other than what the flow of the code suggests? And if these hypothetical "indenting just because I can and not because I should" people exist, how would their inconsiderate behavior be any different whether they are using tabs or spaces?

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

#643

Earlier quoted context omitted.

Since tab indenters have characters indistinguishable from spaces that are a different width from any other character on the screen I wonder what other bizarre escape codes are in their source To me it makes as much sense as having invisible characters scattered throughout your code, but tab indenters have gone beyond their delusion now

> Since tab indenters have characters indistinguishable from spaces Most editors can be made to highlight it > that are a different width from any other character on the screen Yes, and? That's its purpose and it can be configured to your preferred value (beyond unicode)

The best ones can, but by far, most can't.

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

#644

Earlier quoted context omitted.

> Does spending time considering the implications of spaces vs tabs really indicate competence? No, it signifies that you have spent enough time programming in a wide variety of platforms and with enough other peers to run in to the issue and understand that it exists.

> it signifies that you have spent enough time programming in a wide variety of platforms and with enough other peers to run in to the issue and understand that it exists Or maybe it signifies youthful inexperience? Of the programmers that I know, the longer they have been programming, and the more varied projects they have worked on, the less they care about tabs v. spaces. Whatever standard the project they're work…

>Whatever standard the project they're working on uses, that's how they set up their editor for that project, because it's one less thing to have to worry about.

I think that the OP would consider that a fine answer.

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

#646

Earlier quoted context omitted.

My answer would be that any modern software development shop should be using a linter like Rubocop, eslint or gofmt that runs automatically on every commit. It doesn't actually matter what standard a group chooses, but there is real cognitive overhead to trying to understand inconsistently formatted code. And, people shouldn't be the ones criticizing incorrectly formatted code; a GitHub robot should be.

Exactly. The impact of any decision has much more significance socially that the sum of all of the individual significance.

The article is taking about average salary, which is a society topic, i.e. social.

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

#647
post #568
post #312

Earlier quoted context omitted.

> The fact that Python's rule used to be 8 spaces, then got changed to 4 thereby invalidating old code really showed me how shortsighted it is to use a set number of spaces in a whitespace sensitive language. Not sure what you're talking about here. In Python, as long as the indentation is consistent you could (e.g.) use 2-space indentation to make a code block. It's considered bad practice, and most linters will com…

The right solution here would be to treat a tab as exactly pi spaces. This, while not forbidding the use of tabs, would guarantee that any inconsistent mixture of tabs and spaces would be considered misaligned.

> exactly pi spaces

That's an irrational choice.

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

#648
post #640
post #623

Earlier quoted context omitted.

> 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.

It is subjective to some extent, but I do find that those who don't wrap their code at 80 characters aren't really particular in terms of wrapping their code at all. So most lines may be between 70 to 130 characters, but there may be the occasional line that's a bit longer.

Plus, it also depends on the tools one uses to review code. Github, for instance, will present a horizontal scroll bar for the unified diff view if there are lines that are too long. Using that scroll bar is not something I appreciate having to do when reviewing code.

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

#649
post #639

Earlier quoted context omitted.

> 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. "…

Just because it originates from teletypes that are no longer used doesn't mean that there's a problem with that width today. We need some standard, because otherwise you end up in formatting hell. There's nothing wrong with 80, so it might as well continue to be 80.

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

#650

Earlier quoted context omitted.

> "whatever my editor sets it to". Whats wrong with this? I just accept the defaults. Whether that is what the current project demands or what the editor defaults to. Why waste my time over these things?

There are two very different reasons for this same answer: the don't care vs the don't know. Not caring is fine, not knowing is concerning.

ok so don't answer "whatarespaces?", got it.
Post reply on HN