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.
At most it's a matter of what tools you use as well as accepted standards in the individual programming language's community.
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.
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...
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.
I think that the OP would consider that a fine answer.
Absolutely not. Getting along with the team is a measure of competence. Asking this question can reveal that.
Regardless, thats a pretty unnecessarily aggressive response to an interview question; or maybe I'm just reading it that way.
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.
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.
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.
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.
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.
To me it makes as much sense as replacing dots with commas, but space indenters have gone beyond their delusion now
To me it makes as much sense as having invisible characters scattered throughout your code, but tab indenters have gone beyond their delusion now
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)
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.
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.
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 .
As long as it's relatively transparent for everyone to be able to use.
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.
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.
As others have mentioned, having a required auto-linting step helps a lot. But it really depends on your specific needs.
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
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'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.
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).
You are a lucky, lucky person.
Strong opinions loosely held and all that.
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.
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.
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.
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.
Let's all work hand in hand and follow the style guide! (Which requires the use of tabs, of course)
To achieve equality you should propose splitting a tab into four tabparts and equating each tabpart with a space. That's true égalité
That's where your issue lies; subconscious prejudice is happening during the hiring process, you just can't see it.
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.