Why I prefer spaces to tabs

Coding convention discussions are always fun. I just had one of them on the weekly Orchard meeting, where I’ve joked that spaces are objectively superior to tabs, by which I meant that there are objective arguments in favor of spaces that I find subjectively compelling..

The first argument for me is that a good programming font has to be a monospace font. Tabs are weird in that context because they are the only useful characters that are a different width than everything else. If, for whatever reason, you have to replace a space with another character, nothing else will move. If you replace a tab with anything else, the rest of the line will move. Additionally, if you change the tab width in your editor settings, the code will look different to you than to its author.

The second argument is that what you align is not always line beginnings. There are legitimate cases where the beginning of a line is aligned with some boundary inside the previous line. A typical example is a list of arguments for a method that is too long to fit on one line:

It is a legitimate preference to want the additional lines of parameters to align with the opening parenthesis. Tabs can’t do that consistently.

That’s my opinion. Pick your own. As always, what’s important is to set the rules for the project and stick to them…

25 Comments

  • Of course it is somewhat dependent on the language and IDE, but i can't say in all my years of programming either of the cases in your first argument have caused any concern. Why would you want to replace a tab with another character? And letting other developers control tab size seems like a useful thing to me.
    You are correct that lining up content vertically is trickier with tabs, but i would say this is a very time consuming thing to be worrying about as a developer. When you rename the method using a refactoring tool all of your precious spacing is going to be messed up.

  • No, because there is tooling, such as VS and R#, that can enforce your spacing and alignment preferences.

  • On other hand, unless you don't actually use the tab key, a space preference means that not every keystroke is deletable with a tap on the backspace. True, if indentation is repeated on newlines that is the case with the enter key as well, but with tabs it is usually 4 backspaces to one tab, double the penalty of an errant enter keystroke. Who has time for that?

    Also, code navigation time is one of my top concerns, and navigating across a single tabstop with one left/right arrow is (usually) 4x faster than the equivalent in spaces.

    If you use something like ctrl+arrow to recoup some of the lost arrowing time, you still have the problem of correctly lining up with an intermediate tabstop (where there might be whitespace to the right of your cursor).

    I maintain that tabs are the more productive option. Usually 4x more productive.

  • You need to learn about CTRL+Backspace, Home, and End ;) I don't see why white space should be faster to navigate over than the rest. If anything, having variable speed makes it more difficult.

    As for "intermediate tabstops", ew. What's wrong with you?

    If you want to use tabs, I don't see a problem with it. Just not on my projects.

  • There's also a thought experiment you can do - imagine a world where 'X' didn't exist and was being proposed for the first time.

    Imagine a world where leading space characters doesn't do anything and all code is exclusively tab indented. One day someone says to his colleague - hey, let's change the editors so leading space characters in a line can be used to indent on the left one column at a time. It seems like the colleague would say that sounds like a reasonable idea, there are a number of advantages to tabs, but sometimes you need more precision in alignment so both are probably necessary.

    Next, imagine a world where tab characters don't do anything and all code is exclusively space indented. One day someone says to his colleague - hey, let's change the editors so a horizontal tab control character advances the rendering column of the subsequent text to an even, user-configurable multiple, ignoring the modulo remainder of printable characters that had previously been displayed. That way everyone can configure their own indentation as an editor display preference, and I can type less.

    It seems in the second world the colleague would quite rightly question the judgement of the person who proposed adding such an arcane scheme to an otherwise dirt simple one-character-per-column monospace text file standard. They would probably say something like "why don't we just make tab and backspace keys jump that number of columns, adding and remove spaces as needed?" or "the tab control code was a feature of dot matrix printers thirty years ago. what else would you suggest - should we have a carriage return without a line feed enable you to display multiple overlapping lines of text on the same row?"

  • Sometimes it's unfortunately not possible to just "pick your own", as many are working on several projects - both alone as well as part of a group.

    In case of multiple developers working on the same project, with different local configuration or even several different editors being used, a standardization like based on http://editorconfig.org/ can be handy, to avoid each developer to change when switching between projects - and each developer can still keep their own preferences for private projects.

    In addition, there won't be a lot of issues with whitespace-only noise in commits, which can occur when not using the same settings.

  • @Nikolaj: you're right. I meant "pick your own" as a group, if the project is managed by a community. I should have made that clearer. And yes, there is tooling to enforce whatever rule is picked.

  • Why not both? I look forward to the day when this "debate" is a thing of the past, where it belongs: http://blog.developers.win/2015/10/roslyn-powered-code-views/

  • Why not both? Because that would be the worst possible choice: now if someone changes their tab settings, the code will get reformatted in completely inconsistent ways. With tabs only, at least, things would still be correctly and consistently indented.

  • @bleroy: There is a blog post that I am sharing in these links that is either not showing up, or you are not taking the time to read. In what I propose, the files get *saved* as one format (100% StyleCop-compliant), but *loaded and viewed* in the format that is preferred/configured by the developer.

    http://i1.wp.com/blog.developers.win/wp-content/uploads/2015/09/ielz0.jpg

    Does that make sense? Is there something about my post/idea that is confusing? I am open to feedback here as it really seems nobody gets it and is determined to hinge on these very divisive and borderline-religious debates on what style is "better."

    If the blog post above doesn't load or you are not getting it, then here is the UserVoice vote it is meant to promote:
    http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/10020390-enable-roslyn-powered-code-views

    Thank you for any feedback and continued dialogue around this very important idea,
    Michael

  • As I said in the comment above yours "there is tooling to enforce whatever rule is picked". What you pointed to is one of many ways of doing it, with .NET or other platforms. It's nice and somewhat novel to provide a view that can enforce different preferences than what the author of the code intended, and I can see how it could be appealing to someone who feels very strongly about those issues. I'm not convinced that it would solve the problem once and for all.
    As a matter of facts, in all the project I contribute to, after the initial debate over which conventions to adopt, there is usually no conflict, people make peace with whatever convention was picked, and move on to more important issues. I would see anything else as alarming for the community in question.

  • Cooooooooooool... My links work after all. :) :P Thank you for taking the time to read and respond, @bleroy.

    There is indeed tooling to enforce the rules selected for styling, but again, they are ultimately arbitrary and dictated by one (or more, if you are lucky) person on the project that subjugates their team members to their wishes for the duration of the project they are stuck with. Hardly ideal or desired working conditions.

    As far as team members "falling in line" after the initial debate, that is also the response that I have heard in regards to team environments. But really, what choice do they have?

    Of COURSE they are going to compromise and yield to such a "minor" issue because they are at the mercy of the failure of the tooling that has put them in this position in the first place. At the end of the day they are working in an environment (or more succinctly creating art) under the eyes of a beholder that are not their own. Restrictive, prohibitive, and divisive.

    Finally (at the risk of hijacking your thread, #sorrynotsorry but I do very much appreciate the feedback/dialogue), I would love to hear why you are not convinced this would work. You basically have a file format (StyleCop) that files would be persisted in (and checked into source control) -- btw StyleCop demands spaces so you two would get along! haha -- and then loaded to the preferences of the developer, which could either be spaces or tabs. Everyone wins, buddy. :)

  • BTW, 2005 called and wants its comments section back. Your comments section is SORELY overdue for a makeover and Disqus integration!!! Please consider following Azure's lead and upgrading to 2016 appropriately and accordingly. :)

  • Because it's overkill, and you'll still have make a decision about what gets persisted to the repo, and what people without the tool will see. If an individual dev feels that they can't live with the convention and wants to use that, then more power to him, I have no problem with that. It does help make the problem even less important than it was to begin with (which was not a lot).
    As for the comments section, I write this blog, I don't maintain it, but if you want to contribute improvements to Orchard, you're more than welcome to do so, and it will eventually make its way here.

  • Something is clearly getting lost in the translation here. You do not have to make any decisions about what gets persisted in the repo; it is 100% StyleCop complaint code. For your reference:
    https://en.wikipedia.org/wiki/StyleCop

    What gets checked into source is code that is 100% compliant to every rule defined within this ruleset -- which is defined by MSFT btw. If every group and every MSFT developer follows this, they (at the very least) benefit from a consistent, predictable, and reliable format for code, whenever it is viewed from a raw source and/or source control perspective.

    I am sure you can see the value in that. This is before you even consider the additional value of having every developer being able to code in exactly the manner they prefer and see fit (via the use of their own personal views). You even save a day or so of arguing with a new project over style preferences (which again are 100% wholly subjective and really not your -- in the rhetorical sense -- place to dictate).

    Is the effort to attain this world overkill? Perhaps if you value bickering among and control over your teammates over the value of allowing them to create their code with absolute personal freedom. :P

    At the end of the day, the grand irony here is that this is a MSFT tech that apparently no one in MSFT uses and/or agrees with (or what in your case sounds like aren't even aware of). This fact paired with the recurring appearance of blog posts like this one (that -- again -- no one ever finds agreement/concensus with) here truly highlights the need for innovation in this space.

    The best we can do is have solid dialogue like this (thanks again for your engagement/time) and present votes for the developer community as a whole to (hopefully) rally around.

    Or continue to bicker amongst each other like a bunch of spoiled children. That also has its appeal, too. ;)

  • StyleCop is a choice. Are we done here?

  • LOL that is certainly one way of looking at it. And given the choice to improve your code (and by effect the community you both comprise and represent) it appears you choose to say no -- remaining complacent, apathetic, and #unnovative, blogging software and all.

    And we wonder why GOOG is eating MSFT's lunch.

  • Tabs is the most simple and direct way to format your code. No need to configure anything). There is already enough to configure in the programming, why would you need another one?)

  • @Mike, StyleCop encapsulates a set of choices. Those choices happen to be rather rigid, which is why nowadays, the preferred solutions are Roslyn analyzers and editor settings.

  • @Bleroy, your broken, busted site works again, horray. It was down this morning, which is surprising. asp.net IS hosted on Azure, correct? It seems like the last thing you would have to worry about is accessing this site.

    Additionally, I did try to sign in via your "sign in" link above and it is nothing but a worked up hassle: It keeps trying to get me to sign in with a username password, even though I am using my MSFT Account. It is also saying it is sending a password reset to my email, but I do not see an email in any of my accounts.

    Soooooo... annoying anonymous form refill, here I am... AGAIN. :P :P :P

    Now, as for your take on StyleCop, I am in agreement with your assessment. Like FxCop, it is a constrained set of rules to ensure some level of consistency and organization to a rather chaotic system. With that said, I agree with probably 1% of what StyleCop suggests. However, I would fully commit to it *as a file format* if it meant consistency to every file format that we view in source control and/or GitHub, etc.

    From my perspective, I have been arguing about this stupid subject for over a decade now. I am sure you have, too. Maybe you have a higher tolerance for these debates, but for me (and I am sure others) it seems like it is time to innovate this space rather than continuing the repetitive, boring, repetitive discussion.

    BTW, this is an issue that is specific to C#. One of the appeals (as I understand it) of F# is that its whitespace is significant, and totally takes these types of trite discussions out of its culture completely. So, there's that.

    My only plea in this (great, thanks again) discussion is to please consider innovation over the status quo. That is all, and my bottom line here. Do you really want to have this same argument a year from now? 5 years from now? A decade from now?

    If so, then yes, we are done here. :P

  • Good.

  • LOL! Right. https://imgflip.com/i/y438j

  • Wow. *I'm* a dick? You need to go away and never come back.

  • Awwww it's all fun and games on this end, duder. I thought i was funny, but you are probably speaking words of wisdom at this point. See you out there.

  • Interesting data here: https://medium.com/@hoffa/400-000-github-repositories-1-billion-files-14-terabytes-of-code-spaces-or-tabs-7cfe0b5dd7fd#.yd88uofs5

Comments have been disabled for this content.