Hacker News new | comments | show | ask | jobs | submit login
Developers who use spaces make more money than those who use tabs (stackoverflow.blog)
881 points by edward 157 days ago | hide | past | web | 663 comments | favorite



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, because then people can set the indentation render size to whatever they prefer in a way that doesn't affect other users" way more than someone who says "whatever my editor sets it to".

Also, fuck spaces. Long live tabs.


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


> 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 doesn't signify anything. I think you might be giving a bad impression of your company by asking that question. In an interview, you have a limited amount of time to come to a judgment about a candidate. Using that time to ask pointless and borderline flamebait questions is going to be a red flag for a lot of candidates. You are also going to put candidates on edge by making them worry about whether or not they have given the "right" answer to a silly question.


It just signifies that someone has worked with enough pedantic developers that they had to form an opinion on something as insignificant as this, or that this person is pedantic enough to have a strong opinion on it.

I wouldn't consider the first to be a good indicator of someone's skill as a developer, and the second would be a good indicator that it was someone I didn't want to work with, but I'm guessing that's not how you're using it...


I agree. This is ridiculous.


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


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


> Does spending time considering the implications of spaces vs tabs really indicate competence?

Absolutely not. Getting along with the team is a measure of competence. Asking this question can reveal that.


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


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.


My answer would be: why are you asking me? Shouldn't I be asking you? Do you have coding standards here? Or is it going to be my job to decide on the coding standards?


Coding standards are what everyone compromises/agrees on. The interview question is about your preference.


and you would have missed the point of the question entirely.

Regardless, thats a pretty unnecessarily aggressive response to an interview question; or maybe I'm just reading it that way.


Or you would be missing the point of the answer.

It's not meant to be aggressive, but to make a point. It's important that everybody uses the same coding style, regardless of personal preference. Spaces are fine, tabs are fine, but mixing them would be absolutely terrible. A programmer's personal preference for one or the other is irrelevant. What matters is that he's willing to adapt to the coding style of the company.


> Spaces are fine, tabs are fine, but mixing them would be absolutely terrible. A programmer's personal preference for one or the other is irrelevant. What matters is that he's willing to adapt to the coding style of the company.

That sounds like a better answer to the question right there. It's the "some though out response" that the interviewer was looking for, willingness to put the team's decisions ahead of your own, and so on.


I don't know who you are, but tabs?? We definitely can't be friends anymore.


This guy gets it.

Tabs for indent, spaces for formatting within. No need to push your tab size standards on the next person to edit your code, and no need to force their editor to retab it to their preference, and back again when it's saved.

"It's the editor's default", or worse, "I never really thought about it" are horrible reasons for doing anything, and hearing something else might be a sign of a pulse.


I also prefer tabs, but always make sure to write spaces to disk. The better you are with your editor, the less you have to worry about whether the original file was using spaces or tabs.

Therefore, writing 100% spaces to disk is the best way to insulate yourself from possible issues of people who _don't_ know what they're doing with spaces, tabs, or their editor.


Plus, when most people are using an editor that doesn't have a per-project settings for the language/format to use, it's really hard. Getting everyone else on a VS solution to change their JS editor to 2 spaces, and disable the auto-format is an exercise in frustration.

That said, the convention for most languages seems to be towards spaces at this point, and I don't care enough to argue anymore as my choice of editor(s) allows me to set it per project at least.


Since space indenters can't have keys matching what's produced by them I wonder what else they remap beyond the tab key, to something else completely unrelated

To me it makes as much sense as replacing dots with commas, but space indenters have gone beyond their delusion now


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.


> having SOME thought out response can be a GREAT indicator of how well versed someone is in general.

Did you cross-check this against any other measure? I can see it going both ways - maybe someone who saves their attention for more important matters would be better at producing value than someone who cares about such minutiae.


yea, thats why I specified "and it doesn't mean anything on its own,"


So how can it be a great indicator then?


an indicator is just that, an indicator. It doesn't mean anything on its own, but in the presence of additional information (interview question responses and discussions in this case) it can help paint a better picture. If someone answered this question with "what? I don't know/care", and then knocked more important questions out of the park, then it was obviously a bad indicator and isn't relevant.


I don't follow. Either their answer means something or it doesn't.


Some answers only mean something in combination with other answers. You're looking at the cloud of data points, not the answer to any single question.


Some answers will mean something and other answers will mean nothing.


Correct.


Yeah, it can start some interesting conversations too - I don't care personally and tend to go with whatever autoformat in the editor uses. My view is that formatting code shouldn't be a human's job, adding linebreaks on long lines, spacing things out to exactly line up, etc is just a waste of my time.

That's the computer's job - it should do it based on human readability rules though, clang-format is probably the best example of these rules applied, it uses a TeX-style formatting engine for code.


completely agree with you. and i religiously autoformat my code before i read the code and just before i save the file.

However it still amazes me how the majority of developers i work with either have no opinion on the topic or worse think this is a bad idea. some the reasons I've heard was it makes alot of changes to a file causing alot of diffs with previous version making it harder to figure was was actually changed, or they don't like they way its formatted .


Yep if you're going to convert from tabs to spaces or vice versa, please do a check-in/commit consisting only of that change before making any substantive code changes.


Was going to say the same... nothing wrong with a commit including only format changes... for that matter, add it as a task to the project, commit, run it, commit, then proceed to edit. If you have commit hooks setup, add it as a precommit hook/task.

As long as it's relatively transparent for everyone to be able to use.


I've been following this practice for a while, but never really thought much of mentioning it until I watched an interesting talk the other day:

https://channel9.msdn.com/Events/GoingNative/2013/The-Care-a...

In it, they mention an autoformatter as one of the best tools they gave their developers in terms of productivity gain and it really got me thinking about how this should be versus how it is in practice. There are some really bad autoformatters and some really good ones - find one that works and is configurable to match your standard and I think it really does result in a good productivity improvement.


completely agree, I'm also the (original) author of https://github.com/jdc0589/JsFormat though, so I'm probably just more sensitive to formatting stuff in general.


Doesn't that mean you make tools like git blame a whole lot less useful? I'm all for formatting my own code correctly, but I'm not going to nuke git history for a few spaces.


Blame is for me at least a fairly infrequently used operation and there's really not much else it breaks unless there are other active branches at the time. I don't find blame information that valuable and would argue that most uses are in fact counterproductive (it's in the name - blame).

You'd only have to do it once, all changes past that point would be good assuming you set it up in your IDE automatically or in your precommit. So if for some reason you needed to go back a long ways and blame something you could always check out back past that initial styling fix and see it.


Wow, I am a spaces guy but honestly, didn't care this much. Clearly, I should! I mean, I would have failed that interview question totally. Except, I would have said whatever the team consensus was.


I don't use it as a question to really be scored as a critical pass/fail. It's intended to potentially start a conversation and maybe give me an idea of someone's experiences.


Is this before or after you ask them how many ping pong balls would fit inside a Boeing 747?


I personally prefer tabs for the reason mentioned above... also, before JS minimizers, it meant less characters in the output. Now, I'll set my editor to whatever is the convention in the team, and/or the greater community (JS is 2 spaces, mostly, C#/VB 4, etc.).

As others have mentioned, having a required auto-linting step helps a lot. But it really depends on your specific needs.


Maybe you should allocate scarce interview time to something that matters instead.


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


> "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?


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


Frankly, if over 90% of your peers are using a given editor/ide, odds are they're using the defaults... as trying to get everyone to change the defaults is painful. Having spent years fighting this in some environments, it's far easier to accept.

If your editor supports a common config format (.editorconfig), then use that... if you're all using the same IDE, then best to adapt to the defaults (mostly).


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.


I assume from this response that you have never worked with someone who created semi-constant issues because they didn't realize that .vimrc they copied from GitHub was silently turning spaced into tabs whenever they saved a file.

You are a lucky, lucky person.


"whatever my editor sets it to" is what I would answer, precisely because I've heard the arguments for both sides to death, and I acknowledge that this holy war exists because both sides' arguments have merits. For me, I expect that my team as a group has a rationale for whatever choice is made in the interest of avoiding pointless bikeshedding, but I expect each individual to be adaptable enough that the choice doesn't actually negatively impact their productivity.

Strong opinions loosely held and all that.


What about "whatever you're using"? It probably doesn't seem well thought out, but is there any other answer? Personally I don't care. I use spaces in Python because of pep8 and tabs in PHP or JS depending on whether or not the file is using tabs or spaces already. Sometimes I realize I checked in a file to git with tabs instead of spaces so I go back and run a find and replace to match indentation. Is that so wrong? Shitty question IMO


Is "depends on whether I'm writing the batch file in notepad or wordpad" a valid answer?


If I were the candidate I will be giving mean looks while tapping the space bar as fast as possible!

Spaces FtW!

Ps. On a more serious note, the editor (actually the vim plugin) takes care of this.. default is 2 spaces for ruby and 4 for python (PEP8). I like ruby more, the identation too.


rant: a default unconfigured vim instance is a perfect example of my main issue with all this whitespace crap. Personally, I like tabs, but ultimately, like you mentioned, it doesn't matter with a well set up editor.

HOWEVER, a default unconfigured instance of vim is not capable of editing, for example, a YAML file in a valid manner without the user knowing that they have to manually set the tab character to spaces or mash the spacebar 1000000 times instead of using the tab key. Thats some REALLY horribly UX. It's not VIMs fault, and its not the YAML spec's fault, but it adds up to some bullshit.


Does anyone actually use an unconfigured instance of vim for actual development?

I can see for people sshing in, editing a file and getting back out without bothering, but you'd have to be a quite a purist to do all your development in an unconfigured Vim.

You can yank and modify existing lines which will keep your YAML spaces.

For years I never used Vim to develop full time so never invested the time to setup my vimrc file. But now that I use it for development and spent the time to set up my vimrc, it's brilliant to be able to just take the goodness with you.


> I can see for people sshing in, editing a file and getting back out without bothering, but you'd have to be a quite a purist to do all your development in an unconfigured Vim.

Thats really the only instance. It's more of a "hey, look at this bullshit I'm pointing out from my fundamentalist high horse" argument than a legitimate one.


Use nvi instead of vim for precisely this reason - Customization is for emacs.. which I also use when I want to customize things.


It's not really prejudice if those 'tabbies' are just inferior, is it?


I can't believe that in 2017 I'm reading comments containing blatant spacial prejudice on Hacker News of all places.


I wish I could say I'm surprised. Hacker News has a known spacial prejudice problem. It's exacerbated by the fact that few people of those who experience spacial preference (please use the proper terminology) feel comfortable here, so many just leave.


Espousing notions of whitespace power. Get that trash out of here.


More like get those tabby cats out of here.


And here I was about to say that I can't wait for the spacist shitposts from the alt-tab


Hacker News should be a Safe Space.


As someone who uses Tabs, I vote that every location should be a Space Safe Space.

Let's all work hand in hand and follow the style guide! (Which requires the use of tabs, of course)


Safe spaces are exclusionary towards tabs. Ban safe spaces! We need safe tabs!


Just one space?


It happens with the best of us. Even Thomas Jefferson used spaces when drafting the Declaration of Independence, despite being an outspoken tabs supporter.


Oh, no! A tab must equate to four spaces (not two, three or eight, only four).

To achieve equality you should propose splitting a tab into four tabparts and equating each tabpart with a space. That's true égalité


Your time would be better spent implementing ':set list' on classic whiteboards.

That's where your issue lies; subconscious prejudice is happening during the hiring process, you just can't see it.


#NotMyIndentation #Resist


The reason I use tabs is pretty simple. It's faster to move around only using the keyboard. It's also faster if I'm changing code that requires reformatting. Finally, when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc. In other words, it adds flexibility.

Brace yourself: I use two spaces after the end of sentences too. [1] I am quite the rebel.

Modern IDE's (Sublime Text) let you easily convert spaces to tabs (or vice versa) and intention length of existing code. [2]

[1] http://www.slate.com/articles/technology/technology/2011/01/...

[2] https://css-tricks.com/changing-spaces-tabs-sublime-text/


> Finally, when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc. In other words, it adds flexibility.

This is exactly why I use tabs and the reason which appears to never get cited in the holy wars.

People who use spaces want to line up their '=' signs, that's fine, but I don't believe it's my position to enforce the amount of whitespace another developer has to use in their editor. It's an accessibility thing, they might have their font size really large because of eyesight problems in which case 8 spaces is going to make reading the code a lot harder.

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.


> This is exactly why I use tabs and the reason which appears to never get cited in the holy wars.

I see this cited every time. Unfortunately, it's bogus in practice. Consider:

    print('some long thing',
          further, arguments)
If this is an indented block, you'd have to indent the second line to the correct depth with tabs, then add exactly six spaces for alignment. You have to mix spaces and tabs, which is never good news. Additionally, if you try to actually type in the six spaces, editors might take, say, four of them and group them into a tab. (I have vague memories from a long time ago of Emacs doing this. I might be wrong.)

If you get this wrong in program parts that are by definition invisible, it might look good for you and look really bad for others (i.e., the opposite of the stated goal). In code I see mixing spaces and tabs, the latter tends to be the case.


I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs.

That being said, this problem and problems like it can be solved simply by not aligning things visually:

    print(
        'some long thing',
        further,
        arguments
    )
Strictly adhering to indentation and never alignment can make the code a bit less readable, but conforming to a canonical indentation like this also makes it easier to reindent, move code around, etc.

I think that's what the argument really comes down to – alignment flexibility vs display flexibility. It's interesting to see which people generally prefer.


> can make the code a bit less readable

Yes, and I'd say that that's a big problem. I'm not a religious opponent of tabs, but making code less readable just so you can keep using them wouldn't fly if I were Malevolent Whitespace Dictator For Life.


IMO, that reads just as well. Each object is still indented, it's close enough.


> I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs.

Could you please clarify why do you consider "tabs for indentation, spaces for alignment" such a bad practice? I have never read any argument against it.

Alignment itself can be done automatically by any editor that supports smart tabs.


Simple: it's hell to automate.

My process is as follows:

    - tabs allow for custom settings
    - tabs need spaces to allow for alignment, because previous
    - automatically deciding what constitutes alignment vs
      indent is a non-trivial problem, highly dependent on the
      language†
    - using spaces throughout is worse theoretically because
      it flattens the theoretical problem but solves impedance
      mismatch
    - therefore I use spaces and am all the merrier in every practical
      use case
    - except for languages who make dash 3 easy (such as Go thanks
      to gofmt)
    - except for projects I have no say in, where I respect the will
      of the maintainers, because conventions among well-behaved
      people matter more than my highly individual opinion. 
† to which the usual answer is "but your editor sucks with lang X", well too bad, I'd rather have pragmatic editor portability than have perfect language parsing in every editor being a pipe dream I hinge upon.


It's not that "tabs for indentation, spaces for alignment" is a bad practice, it's that alignment itself is a bad practice. It doesn't help readability, it directly causes overly long lines of code (which pushes people to try to use narrow indentation to compensate), it's something you have to fiddle with every time you refactor a name, and it gives you spurious changes in your VCS diffs. (Yes, you can set any diff program to ignore whitespace changes, but I want to know when whitespace has changed.)


Yes, Emacs used to group spaces into tabs. I think most editors these days do the right thing.

This problem goes away if you indent parameters instead of aligning them:

    print(
        'some long thing',
        further, arguments)
In this case it takes an extra line, but it's often shorter.[1]

[1] https://github.com/pennersr/django-allauth/blob/a44134688f5b...


Gross, You purt 3 parameters are on two lines. Either indent none of them and keep it on one line or indent all of them. What are you doing, trying to hide "arguments"?


That's how the original example was formatted. I'm illustrating one small change.


> I see this cited every time. Unfortunately, it's bogus in practice. Consider: > > print('some long thing', > further, arguments) > > If this is an indented block, you'd have to indent the second line to the correct depth with tabs, then add exactly six spaces for alignment. You have to mix spaces and tabs, which is never good news.

One way to avoid this would be use a hanging indent. For example:

    print(
        'some long thing', further,
        arguments)
That would work well with either tabs or spaces.


This is the right way to do it always, because it is the consistent way. You'll always be indenting the same way everywhere if you do it like this.


This is an example of where it's absolutely okay to mix tabs and spaces. If it's Python, that's not going to work, but depending on one's preferences and opinions that can be seen as a defect of the language, not the formatting. In C, C++, Java, Javascript, and nearly every other language, this is a great practice.


I agree in theory. Having seen terrible mixes of tabs and spaces, I don't agree in practice.

I've worked with several projects that painfully switched from tabs to spaces because tabs didn't work for them in practice, in a setting where several people work on one thing. I haven't seen projects go the other way. (Yes, automated formatting would solve part of thise.)


you're going to be downvoted by the thou shalt not mix tabs and spaces crowd that fails to understand the reason of what they preach. sigh.

also the fly by night devs who still don't see tabs on their text editors... I mean, ide.


I feel it's a matter of style. I've resisted a long time, but then I've come to appreciate:

    some_function_name('some long thing',
        further, arguments)
Assuming a tab width of four, there is no problem with starting the second line with a tab. And the whole thing can be indented by tabs, as well (in which case the first line has N tabs and the second line has N+1 tabs).

The longer the function name, the better the advantage of indenting like this.


Spaces are only beneficial if you use styles with alignment. I dislike them: they sometimes look pretty, but they waste a ton of space on the left and don't work well in all situations.


I wonder how much time have been wasted trying to make margins and columns look good with a proportional (non-monospace) font ...


Almost certainly none at all. Those of us who use proportional fonts simply don't try to do column alignment, because it would be a fool's errand.

In most situations, I consider column alignment to be detrimental to code maintainability. I actually stopped using it long before I switched to a proportional font.

When I later got curious about trying different fonts, I discovered to my surprise that the code looked just the same in a proportional font as it did in a monospaced font.

Regarding margins, if you mean indentation, that works the same in a proportional or monospaced font. The only thing that doesn't work well is the popular two-space indents. That ends up with very little visible indentation in a proportional font.

But to my eyes, two spaces isn't enough in a monospaced font either. It's just not enough spacing for me to see the code structure clearly. Four-space indents solve this problem; tabs solve it even better. When you use tabs, you don't have to argue about how many spaces to use.

I think these are related. Why do people want to use two-space indents? I believe it is often because their lines of code are getting too long. Why are the lines getting too long? Often that is because of the use of column alignment, especially with function arguments and the like.

If you stop using column alignment, your lines will naturally be shorter, and there is less reason to try to save horizontal space with narrow indents.


> 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 complain about it since 4-space indentation is the "golden rule."

If you're talking about the Python interpreter's interpretation of the tab character in indentation, that's different[1]. In any case, old code that has 8-space indentation using spaces rather than tabs is still good. The only issue would be old code that mixed tabs and spaces for indentation, which might not match up anymore to make correct code blocks. But, in general, it's just a bad idea to mix tabs and spaces for indentation.

[1] To the uninitiated, the Python interpreter treats a tab as X number of spaces when parsing the source code. This means that technically you could mix a block's indentation between tabs and a corresponding number of spaces. For example, if X = 4, then this code block would work:

  def function():
  <tab>something()
      something_else()


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.


I think pi*pi is even better. Twice the pi!


"I don't believe it's my position to enforce the amount of whitespace another developer has to use in their editor."

I suspect this might not be my most popular comment, but I honestly think that this is why tab users might actually make less than space users on average. On average, it's more productive to enforce things than leave everything configurable, thus different everywhere, thus harder to make sense of and debug. I knew brilliant people who don't want to "enforce" and decide and dim people who happily enforced and decided and it's always amazing how badly the former do career-wise relatively to their talent and effort, and how well the latter do relatively to theirs.

(Of course there might be another explanation for the data and I don't claim that my just so story is in any way scientific; though I think it should pass as a scientific theory in the social sciences.)


It's plausible and goes to show why the blog post choosing salary is itself a bad metric to begin with. It has skewed the entire discussion.


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

When exactly did it use 8 spaces? I have been using Python since 1996 and I don't recall this 8-spaces thing. Almost all code I've seen uses 4 spaces.

In any case, it doesn't matter because, as another commenter pointed out, as long as your indentation is consistent, your code will work just fine, no matter how many spaces you use for indentation. Even if some code does use 8 spaces, it should work without problems. (Tabs as well, by the way... it's mixing tabs and spaces that is a problem.)


I may be misremembering since it has been a long time since I've used it, but I thought at one point Python treated one tab as equivalent to eight spaces.


First, my golden rule is "do whatever the other devs using the repo do" but

> People who use spaces want to line up their '=' signs, that's fine

To me this feels like it's a good use of spaces as well as tabs. Tabs for indentation, to get your nesting right. Spaces to align things. That way setting your tabs to X spaces works just fine and everything remains nicely aligned.

Though I'm not sure how common this is, so I just use spaces.


Get your blasphemous mixing of spaces and tabs out of this holy war!


> This is exactly why I use tabs and the reason which appears to never get cited in the holy wars.

It's probably been mentioned 20 times in this thread alone.


> People who use spaces want to line up their '=' signs

How does that prevent the use of tabs? You can use tabs to indent, and spaces for your = signs.


Mixing tabs and spaces is a nightmare, unless it is your personal non-open project. If a project is open or shared with anyone you need a simple rule to follow. There shouldn't be another leaf in the decision tree for when to use tabs or spaces. We have enough decisions to make the way it is.


> Python's rule used to be 8 spaces

Interesting. Unfortunately I cannot find anything on the internet regarding that. Care to share a link proving that?


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

There's also the (more minor) issue that you then can't line things up on a line below at an arbitrary place if the indentation of the two lines is to be different. This is admittedly less of an issue, but it does arise on the occasion one wants to structure text, for example in a table in a comment block.

I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere. But I'm not writing this to get into a holy war; only to point out that the "it adds flexibility" in your argument is a fallacy.


> 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 earth if you let them. But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done."

I realize that the 80-character limit is "everywhere"[1], but other than "it's everywhere" is there a more solid reason?

[1] When editing text emails in Vim the default textwidth value is 72, so that there is still some flex for quoting explicitly wrapped text (i.e. prepending "> " to the lines) and staying within the 80-character limit. The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters. etc...


80 character line wrapping is IMO more important on larger and wider-aspect ratio screens. Even the smallest 16:9 aspect ratio screen can be split into two columns, one being an 80 character column for code and the other left wide for a web browser or document viewer (this is now my setup when working on 16:9 aspect ratio laptops).

I see a lot of people work on large displays and with multi-monitor setups. Those who do not have their screens split into an 80-character or similar terminal and text editor width columns spend a lot of time switching between screens or applications. Couple this with the fact that you have to move your eyes around a lot on larger displays (and even head, in the case of multi-monitor set ups) and their setups actually make them navigate slower than they would on a smaller display.


> 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 similar reason that you mentioned for emails. Specifically, it's because the git log output indents the commit message relative to the diff (when using the -p option).


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


Too long lines are harder even in prose as they make you confuse the start of the next line when you reach the end of one.


Further, given that you're dealing with a language that uses significant indentation, you end up having to use stupid tricks that make your code less readable to stay under the bar.

Indented two levels (an 'if' block in a function in a class) and a couple of interpolated variables in an error message isn't unreasonable to have on a single line.


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


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.


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


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?


I'm not talking about using a different style. I'm saying that different tab widths lead to different requirements for how many columns wide my window must be.


Someone who uses 8 spaces for tab will do less nesting them someone who users 2. Thay is how I read the above comment.


You misunderstand me. I can set my tab size different from yours, but doing that will change the horizontal window width required to view your code. This is the problem I'm describing.


How is that problematic though? I'm not aware of any language or situation where the width of the window has any impact on anything.


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

So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs.

>I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less).

Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running.

Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...


> So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs.

I think that the point was that if your IDE displays tabs as 8 spaces, and you read code written by someone that sets their IDE to display tabs as 2 spaces, then the line lengths will display longer in your IDE.

It "just works" when the writer has configured longer tabs than the reader, but not necessarily in the opposite direction.

> Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...

One example: enforced line-length limits. If you are wrapping at 80 characters with tabs set to 2-spaces, you will display a longer than 80 characters when viewing with tabs set to 8-spaces.


> So change your tab size?

Then open another file, change the tab size again. Or start setting up macros/extensions/whatever to remember or auto-detect settings. This flexibility to have different developers view the same code with different tab widths comes at a cost. Many of those same developers would rather not keep paying the cost, and would prefer that code written by many people fit in their editor/IDE windows and look consistent without any special settings.


> Also, what do you mean "works"? The world doesn't

explode if

> you view a file with a different tab size than it

was created

> with. Again, kind of the point...

It does, as I demonstrate in my quote of you above. Try reading source code like that.

The only sensible way of reading source code is by viewing it with at the same overall window width in which the author wrote it. Viewing at a different tab size destroys this.

> Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running.

Except that I need to figure out the most appropriate tab size to use on a per-file-author basis if "variable tabs" were used, so this doesn't work because I get the problem as described above.


> I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere.

Ah, the old argumentum ad ubiquitam, which has saddled us with the x86 ISA, Unix kernels, and other brokenness we can never shake.


You're begging the question. There's nothing wrong with the principle of having a standard format, or the currently accepted standard format.


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


Beyond that, this tends to work across all input fields in your OS. If you're missing this you're missing out on being more efficient in any typing based activity.


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.


You are among friends, in your use of tabs and two-spacing at the end of sentences. There aren't many of us, and seemingly fewer every day, but we are a force.


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


Rubber duck is trying to lead you astray. Use emacs!


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


This is extended to all text editing -- use ctrl to modify your movement (arrows, backspace, delete) to word boundaries.


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.


You think you're a rebel? I have my tabs set to three spaces.


You must be stopped!


> Brace yourself: I use two spaces after the end of sentences too. [1] I am quite the rebel.

The paragraph above this one seems to use single spaces after periods. Is this a Hacker News formatting thing, or are you conning me?


Don Knuth seems to agree with you a bit; TeX automatically inserts some extra spacing between the end of a sentence and the beginning of the next one. You don't have to type it yourself though!


That's why most people stopped inserting the extra spaces themselves, instead allowing the layout engine/word processor etc to do it for them.


Then your editor / layout engine has to be smart enough to distinguish between Dr. Smith and the end of a sentence.


> It's faster to move around only using the keyboard.

There are faster ways, at least with JetBrains products, to navigate code that doesn't involve arrowing through spaces/tabs

The only reason I use spaces is the formatting is the same everywhere without messing with settings.

> Brace yourself: I use two spaces after the end of sentences too.

Me too! I was brought up this way. If you want to get into really sick and demented old habbits, my wife indents the first sentence of each paragrah... in emails lol


To me, moving around faster using only the keyboard is an editor feature.

My experience is with emacs but to go from the left margin to the first non-whitespace character across a vast swath of spaces in auto indent mode, I just press <tab> once. I'm sure other editors have something similar.

If you're iterating over the whitespace manually you are doing it the slow way :).


> I use two spaces after the end of sentences too. [1] I am quite the rebel.

Why don't you just use a tab character?


Don Knuth seems to agree with you a bit; TeX automatically inserts some extra spacing between the end of a sentence and the beginning of the next one. (But the extra space is less than one full inter-word space.) You don't have to type it yourself though!


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.


But what's the "right number"? Space enthusiasts can't agree.

Tabbers know how many tabs to use: one, per indent.


Well, of course. Only companies with fuck-you money can afford the extra bytes spaces take up versus tabs, so it follows logically that they'd pay their developers more.


While your comment is obviously meant as a joke, it somehow rings true from my anecdotal experience.

I'd also like to see an analysis of space-vs-tabs as it relates to operating systems. Again, from anecdotal experience, it seems spaces are more common for folks with *nix background who tend to work in product-oriented companies (i.e. where code is an asset) and tabs are more common with windows folks, who tend to work on IT (i.e. where code is liability)


Hmmm...

I've mostly only ever worked in Windows environments with the odd linux machine here and there, but mostly Windows, I've worked in both I.T. and product-oriented shops. I've mostly favored spaces. I've never been questioned it or asked to do differently. Generally speaking, those that care about the money, don't give a fuck about whether I use tabs or spaces. I've worked in tight-ass shops that have nickeled and dimed for every cent savings and I've worked for shops flush with cash to pay developers to do it right.

In my actual experience, I've never seen any relation to tabs vs. spaces with regards to being paid more. Nobody that has ever paid me for what I do has cared about which I use, nor have they questioned it.

One thing I have noticed in programmers are an asset vs. programmers are a liability is that companies who understand that automation is going to extend their profitability by more of a margin than it costs them will pay you what you're worth. Those that view programming as a sunk cost, that just makes their lives easier or cuts costs will pay you what they can get away with.

Don't work for a company that views you as a cost centre. Work for a company that views you as a profit centre. The work will be more meaningful. You will be more fulfilled. You will most likely be less stressed and you will most certainly be appreciated and respected more.


I'd like to add my own anecdote: Windows development primarily happens on one vendor's IDE - Microsoft Visual Studio, and where MS leads, Windows-based developer follow.

Case in point - I use the default Visual Studio settings which are spaces, BUT they weren't always. I remember as recently as 2008 tabs were the default.


Visual Studio 4-6 (1996-2000) the default was tabs


The good years for Microsoft.. feels like there’s a story there :)


Most of the time I've seen people refer to code as a liability, they aren't referring to the 'cost-center' mentality, but rather recognizing code is the liability you incur in order to get the business value [1], and thus you should minimize the code you write per solved business problem.

[1]: https://twitter.com/tastapod/status/726747175317852160


> product-oriented companies (i.e. where code is an asset > IT (i.e. where code is liability

You got it backwards. In companies that sell code, code is an asset. In companies that sell services code is a necessary evil.


I think you misunderstood him/her.

If you're a software developer and you're part of the "IT" department, then you're a liability. Your code is a necessary evil.

If you're not part of the "IT" department, then you're working in a product-oriented environment where the company is selling your code (either as a good or as a service) or otherwise making money from the code. In that case, your code is an asset.


I've always understood it as functionality is an asset and code is a liability. The company wants and uses the functionality to make money. Code has to be maintained, has bugs, etc. Your goal should be to provide the required functionality while reducing the costs incurred by your code.


This is...this is actually brilliant logic.


Windows itself is indented with spaces.


Because the code of Windows is the asset ;)


I use spaces because python.


The eight spaces companies are clearly flying high and the place to be if you're looking for mad bank.


poor ruby devs and their two-space indentation rules.


Dilbert (well, Ashok really) has a few more storage-saving suggestions: http://dilbert.com/strip/1996-08-20


Palapa money


...if you hit ten spaces you might afford a full Palapa forest ;)


You probably mean companies that are loaded or well-funded or stupidly rich. This isn't the same as fuck-you money, which refers to the amount of savings a person would need in order to retire early and thereby bid their employer goodbye. See for example: http://time.com/money/4187538/f-u-money-defined-how-much-cal...


I think that a rational sounding inerpretation can be found: all spaces means python programmer (mixing spaces and tabs messes up the indentation), python rulez, therefore high salary


According to the article, he tried controlling for language and the effect remained.


Spaces over tabs is the default for IntelliJ. Given there are over ten million Java developers who are in very high demand, Python is practically a rounding error.


Also, they controlled for language and the effect was still present.


The only thing they didn't control for is Stack Overflow use.

It's official: science proves that highly paid tab users just don't need it.


Warning, the parent post is sarcastic and should be chuckled at.


your comment seems to imply that the article and all other comments are not... I'm confused now.


The article is serious. But I'm guessing there is either something subtle wrong in the analysis (they even find Go programmers who use spaces earn more, which makes no sense given that 99% of Go programmers use tabs), or it's some kind of weird selection bias, given that it the sample is self-selected.


just because it was not posted on april 1st, it doesnt make the article serious.

they are publishing a very limited, informal, unscientific, survey and having fun drawing outlandish conclusions.

if you think this was serious in any way you may want to bring back pirates to counter global warming.


Well, white-space is removed anyway in compressed production files...


Woooosh...


So you're saying that if I spent 30 minutes learning fmt then I can expect a raise? Sold!


This is one of the funniest comments I've read on here. This deserves more recognition


This is one of the many unconstructive comments


So's your mum.


yeah, just because in 2017 storing source code is the most expensive thing for a company. but really, the storage is almost free nowadays...


Seems unfair to downvote you just for misunderstanding, that was sarcasm friend.


It's pretty much an unwritten rule that a sarcastic joke on the internet with sufficient exposure will get a response by someone who didn't get it. Using /s really kills the fun (and whole point) of using sarcasm so it's a trade off to accept these comments will happen.

I'm impartial to downvoting as to reply literally doesn't usually add to the conversation, which is generally the point of downvoting. Losing karma shouldn't hurt your feelings.


Known as Poe's Law [1]

[1] https://en.wikipedia.org/wiki/Poe%27s_law


I will don't understand why it's called Poe's Law if he said it in 2005. This phenomenon was well documented on Usenet by the early nineties.


If we called everything that was first described on Usenet as "Usenet's Law" then everything would be Usenet's law, probably even a couple of things in physics.


Also known as Usenet's Law [1].

[1] https://news.ycombinator.com/item?id=14561801



Poe's Law is when extreme views seem to self-parody. That's different from someone missing the joke on mundane sarcasm.


Could also be that the reply is also an attempt to play the into the joke (kind of like a vaudeville straight man).


Do you mean partial to? As in, you favor downvoting over commenting to point out their mistake? Don't mean to be nitpicky, just genuinely confused if that was a mistake or I'm misunderstanding.


I meant that as I'm indifferent to whether or not they get downvoted but I see there could be a justification for doing so.


Yeah but we are human. Most people's feeling probably are hurt when their [non-malicious] comments are downvoted. But besides that I mostly agree with what you wrote.


Yeah, I guess. If the person didn't catch the sarcasm they probably won't catch why they are being downvoted, at least 1 person has to tell them.


I strongly think \s should be enforced in every post in HN.\s


For portability you should use /s, not \s. \s only works on Windows.


You should have escaped the tag, like this \\s. Your second tag closed, forcing people to take your post seriously.


Killed the fun with the second one.


I can't debate sarcasm.


I'm confused. Do you mean that we're allowed to create posts on Hacker News that are not sarcastic? I thought there was a rule, with a powerful AI enforcing it, stating that all posts had to be sarcastic. (Warning, this post is sarcastic and not meant to be taken literally.)


I've grown so tired of sarcasm. Online and in real life people are often saying the exact opposite of what they mean. We have to pick up the sarcasam to truly understand.


The real issue with sarcasm is that it actually places the burden of subtleness on the speaker, whereas people will usually blame the listener for not understanding. If the tone and wording isn't just about perfect, then it's obviously easy to miss sarcasm, let alone the humorous intent. And that is sometimes very hard in writing, hence the "/s" which ruins the fun for everybody. Likewise if the listener isn't educated about the object of sarcasm, little can s/he get the irony of the statement... I think missed sarcasm has more to do with failed cultural fit than fault of anyone involved. Which is probably why it's much more common and accepted within social circles than in general discussion. HN clearly fits the former, though; sarcasm is just about yet another norm here!


> HN clearly fits the former, though; sarcasm is just about yet another norm here!

Agreed, this is why I didn't want to take a hard position on downvoting someone for missing the sarcasm. We're in a public forum which crosses cultural boundaries. I see the argument for both sides.

Although I lean more towards downvoting as the majority of people on HN will get the joke and it's an opportunity to learn for those unfamiliar with the mainstream culture.


sarcasm is one of the true idiosyncrasies of humanity that differentiates us from the machines. Embrace it.


Right up until we can type "include('sarcasm')" and have it work.


Could it be that a few large, well-compensating employers are shifting the result? (E.g., https://google.github.io/styleguide/cppguide.html#Spaces_vs....)


that would be the most logical explanation, but the article mentions that "The effect is smaller in Europe and especially large in India, but it does appear within each country, suggesting this isn’t the sole confounding factor." Which makes me think that there are other factors at play that add up.


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.


When I was working in Windows about 5 years ago they required spaces.


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.


= Why Grown-Ups Don't Use Tabs =

* Joe likes 4-space tabs, I like 2-space tabs, and Jane is old-school with 8-space tabs.

* All goes well until someone aligns something visually, like so:

    void someNiceMethod(
[tab][tab][tab][tab][space][space]int myParam...);

* Now it aligns perfectly on my machine, looks mostly ok on Joe's machine, and is ON MARS on Jane's machine.

Thus one-or-more of three futures happens:

* Someone implements a code re-formatter into version control

* Someone re-aligns the code, starting the process over again.

* Someone calls a meeting and demands we all switch to spaces


You mean something like this don't you?

  [tab]void some nice method(int param a,
  [tab]                      int param b
So long as you only use tabs for indentation, not alignment, tabs look correct on _everyone's_ machine. The real problem with tabs is that (some) people are lazy and do stuff like this:

  [tab]void some nice method(int param a,
  [tab][tab][tab][space][space]int param b
Personally, I think if you work like that you need to learn to be professional and write code that follows whatever coding standard your organization uses. If they use tabs, the second example is _not_ following the coding standard.

So whether to prefer tabs or spaces, to me, depends entirely on how much you can/want to trust your coworkers to follow the coding standards.

Edit:

Or as pointed out below, change your coding style to this:

  [tab]void some nice method(
  [tab][tab]int param a,
  [tab][tab]int param b


No I think grand parent comment means that some developers sometimes add spaces instead of tabs, even if it is by mistake. That will mix everything up.

"Could" happen the other way too, but I think: If you use spaces you typically dont repeatedly hit space to produce a single indent. You use tab which gets translated to spaces. Once the editor is set up for this, you don't accidently insert tabs for indentation.


Wait ... you're saying that you should do a tab, and then a whole bunch of spaces?

What actual benefit does tabbing even get you at that point?


Respecting indent preferences of others while not breaking the formatting of that line-split function call.


This whole post would be so much more productive if "Tabs for indentation, spaces for alignment." was defined upfront for everyone to debate.


Formatting


The Linux codebase uses tabs, and presumably they have this rule about using spaces for alignment. I've seen tons of committed code that doesn't follow this rule, though, and hence Linux source looks like shit on anything besides 8 tab-width.


While this is true they will look correct on everyone's machine, they'll be annoyingly wide in tools that display tabs as 8 spaces (such as less, most online diff displays, etc). But spaces will look the same regardless of tool, editor, anything.


I don't know what online diff do you use, but less let you configure the tab stop with the -x option, which is the point of using tabs: being able to chose what's more readable for you.


The point of using spaces is to not worry about any of this. You need a specific fix for less, another specific fix for other diff tools, etc etc. With spaces, everything just works.


I don't see it as a "fix" but as a configuration. And tabs also just works, if you accept the defaults that are given to you :) but if you don't, then you can change your settings (which is trivial). With spaces you have no option but accept whatever is given to you.


Something tells me we'll just go back and forth on this. Should we discuss something else? Perhaps vim versus emacs? Windows versus Linux? :)


The only reason 2, 4 or 8 is less "readable" to anyone is because they have a mental breakdown when they see a style they don't prefer and can't get past it. Tab is a variable width character, it has no place in text laid out with fixed-width fonts.


Is having a style preference bad? One can freely configure color scheme and font, so why should indentation be restricted?


Those options are unambiguous and never require changes to a plain text file to work. I'm pretty sure it was Ayn Rand who said "A is A, but God only knows what Tab is." It's not always used for indentation, it might be for alignment, even if it's at the beginning of a line. There's no way to make any sane programmatic decisions base on it's presence. It does not belong in the digital world!


Some typefaces have spaces as narrow as 1/5em. Many are around 1/4em.

Spaces in a fixed width typeface will be up to about 5 times as wide as in some proportional width ones.


This is like an "eternal September" - when tabs vs spaces comes up each year, most commenters have never seen one of the rather simple ways of using tabs correctly.


There's actually a solid argument for "tabs for indentation, spaces for alignment", which solves both for preference and vertically aligning stuff:

  [tab]void someNiceMethod(
  [tab][space*20]int arg1
  [tab])
But it basically requires having some visual indicator of what is a tab, which most people don't like.

(edited for line breaks)


I have visual whitespace turned on in all of my text editors. The massive amount of mixed tabs/spaces and trailing whitespace I find in virtually every document with multiple authors leads me to believe that I'm the only person on the planet who actually cares about whitespace at all.


Trailing whitespace drives me batty! The only reason I can come up with for it is sloppiness.


If a system requires thought and care to be used properly then people will inevitably use it improperly. Even skilled, thoughtful people make mistakes or get fatigued and take shortcuts.

It seems to me that using tabs for indentation and spaces for alignment is a fragile technique. It's easy to make a mistake and not even notice. If you don't fix that mistake fast, people start to assume that maybe it's OK to ignore whitespace formatting issues. And so the problem compounds.

I would prefer to use a system that creates a "pit of success" so that even careless people have a hard time doing it wrong. I think sticking to just one whitespace character is better than mixed tabs and spaces, but best of all is using an editor that can automatically format your code.


What I didn't say in my original comment is that I don't actually do this for exactly the reason you describe, and that I think spaces-only is the most robust solution.

That said, all you would need is editors to enforce "any line with spaces before a non-whitespace character must have exactly the same number of tabs as the previous line." Which would not be all that difficult, but currently (afaik) does not exist.


I like how it is in Sublime (2) - it shows whitespace characters on highlight.


That's pretty nice. VSCode has a pretty good option too that shows whitespace except single spaces between non-whitespace characters.


Who aligns like that? It seems to defeat the purpose of putting it on a separate line.

  void someNiceMethod(
  <tab>int myParam...
  );
Hey Presto! You, Joe and Jane all get your preferred size size of tab.

As a bonus, this indentation style works equally well if Jim uses a non-fixedwidth typeface.


Well, as long as everyone always use tabs, that should work out okay. But in practice, of course, it doesn't ever happen that way. Nice thing about a space is that it is always a space, a tab is however many spaces you personally want it to be.


Non-fixed width typeface? That would be grounds for immediate termination.


You'd lose a pretty good employee then:

http://www.stroustrup.com/3rd_notes.pdf

> At first glance, this presentation style will seem ‘‘unnatural’’ to programmers accustomed to seeing code in constant-width fonts. However, proportional-width fonts are generally regarded as better than constant-width fonts for presentation of text. Using a proportional-width font also allows me to present code with fewer illogical line breaks. Furthermore, my experiments show that most people find the new style more readable after a short while

Great book, and I have used proportional fonts occasionally. It's much much better than you might imagine (as long as you are sane and use tabs for indentation). Obviously you can't get "perfect" alignment like you can with fixed-width fonts, but it is certainly nicer to read, so there is a trade-off.


People's opinions on that matter are always very strong and rarely... align (ba dum bump).

All-spaces lets the code look as-intended for everyone, and then their IDEs can let them hit the tab-key and get the look-and-feel they're after. It is the best option that gives the most freedom to everyone whilst also making us all play well together.


Do people actually code with non-monospaced fonts? I've never seen anyone doing that before


When I first started programming I had to share a single terminal with the rest of the school, so I wrote my programs on paper first. I used graph paper so that my handwriting would be monospaced.


> * Joe likes 4-space tabs, I like 2-space tabs, and Jane is old-school with 8-space tabs.

> * Someone calls a meeting and demands we all switch to spaces

They compromise on the average 5 spaces per tab and everybody is dissatisfied.


see, i just think that's why grownups don't do that shit. you've got something that would normally be on one line but it's too long? indent once extra and don't be weird. there's no value in lining it up with the parenthesis.


>All goes well until someone aligns something visually, like so:

I have been programming for most of my life, and I still don't know why people do this. I just don't feel the need to align stuff.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: