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.
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.
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.
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.
Brace yourself: I use two spaces after the end of sentences too.  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.
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.
I see this cited every time. Unfortunately, it's bogus in practice. Consider:
print('some long thing',
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.
That being said, this problem and problems like it can be solved simply by not aligning things visually:
'some long thing',
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.
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.
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.
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
- using spaces throughout is worse theoretically because
it flattens the theoretical problem but solves impedance
- therefore I use spaces and am all the merrier in every practical
- except for languages who make dash 3 easy (such as Go thanks
- 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.
This problem goes away if you indent parameters instead of aligning them:
'some long thing',
One way to avoid this would be use a hanging indent. For example:
'some long thing', further,
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.)
also the fly by night devs who still don't see tabs on their text editors... I mean, ide.
some_function_name('some long thing',
The longer the function name, the better the advantage of indenting like this.
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.
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. 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.
 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:
That's an irrational choice.
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.)
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.)
> 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.
It's probably been mentioned 20 times in this thread alone.
How does that prevent the use of tabs? You can use tabs to indent, and spaces for your = signs.
Interesting. Unfortunately I cannot find anything on the internet regarding that. Care to share a link proving that?
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.
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", but other than "it's everywhere" is there a more solid reason?
 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...
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.
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).
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.
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.
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.
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
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).
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.
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...
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.
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.
> you view a file with a different tab size than it
> 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.
Ah, the old argumentum ad ubiquitam, which has saddled us with the x86 ISA, Unix kernels, and other brokenness we can never shake.
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?
- 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.
The paragraph above this one seems to use single spaces after periods. Is this a Hacker News formatting thing, or are you conning me?
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
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 :).
Why don't you just use a tab character?
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.
Tabbers know how many tabs to use: one, per indent.
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.
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)
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.
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.
You got it backwards. In companies that sell code, code is an asset.
In companies that sell services code is a necessary evil.
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.
It's official: science proves that highly paid tab users just don't need it.
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.
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.
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.
* 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:
* 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
[tab]void some nice method(int param a,
[tab] int param b
[tab]void some nice method(int param a,
[tab][tab][tab][space][space]int param b
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.
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
"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.
What actual benefit does tabbing even get you at that point?
Spaces in a fixed width typeface will be up to about 5 times as wide as in some proportional width ones.
(edited for line breaks)
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.
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.
As a bonus, this indentation style works equally well if Jim uses a non-fixedwidth typeface.
> 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.
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.
> * Someone calls a meeting and demands we all switch to spaces
They compromise on the average 5 spaces per tab and everybody is dissatisfied.
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.