Hacker News Reader

Comment by jdc0589 | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com