The best lack all conviction, while the worst are full of passionate intensity. \u2014 \u201cThe Second Coming\u201d, William Butler Yeats
\nKeep the above in mind when considering either side of the debate. ;-)
\nHerein I assert and discuss the following:
\nUsing spaces has subtle advantages over using tabs in collaborative environments.
\nThe \u201ctabs reduce file size\u201d argument is factually true, but is a case of optimizing on the wrong resource.
\nThe \u201ctabs allow each developer to set his own indent widths\u201d argument sounds good in theory but leads to problems in practice regarding line length recognition and inter-line alignment.
\nIn the PHP world, there are effectively two competing indenting practices: \u201c4-spaces\u201d and \u201ctab.\u201d (There are some in the 2-space camp as well but they are very few.)
\nI want to point out a couple things about why spaces might be considered preferable in a collaborative environment when style is important on a PHP project. And yes, it turns out this dicussion does matter.
\nI used to use tabs, and slowly migrated over to spaces. Over the course of several years, I have found there is a slight but useful advantage to using spaces for indentation when working with other developers, and I want to discuss that one advantage in this essay.
\nNote that I am not asserting an overwhemling, absolutely obvious, infallible moral rule that clearly favors spaces over tabs as the One True Path. It is merely a noticeable improvement regarding more sophisticated rules of style.
\nDo I expect this essay to change anybody\u2019s mind on using tabs? No; but, I do hope it will give some food for thought.
\nWhen making an argument, it is important to state the alternative viewpoint in a way so that people who hold that viewpoint actually agree with it.
\nWhat are the reasons for preferring a tab indent? As far as I can tell, they are:
The tab is a single character, so files are smaller.
\nUsing a tab character allows each developer to change the level of indent
\nthat he sees, without actually modifying the on-disk file.
If there are other reasons I have missed, please let me know.
\nIn general, I assert that the \u201cfile size\u201d argument is a case of \u201coptimizing on the wrong resource.\u201d
\nBy way of example, let\u2019s take one file from a real project that uses 4-space indenting, Zend_Db_Abstract, and use wc -c to count the number of bytes in the file.
$ wc -c Abstract.php\n40953 Abstract.php\nNow, let\u2019s convert each 4-space indent to a tab.
\n$ unexpand -t 4 Abstract.php > Abstract-tabs.php\n$ wc -c Abstract-tabs.php\n34632 Abstract-tabs.php\nWe save 6K of space on a 40K file, or roughly 15%, by using a tab character for indents instead of a 4-space indent.
\nNow, to get an idea of how that compares to another way to reduce size, let\u2019s remove all the comments from the original 4-space file and see what that does. We\u2019ll use a tool I found after two minutes of Googling (you may need to change the hashbang line of remccoms3.sed to point to your sed):
$ wget http://sed.sourceforge.net/grabbag/scripts/remccoms3.sed\n$ chmod +x remccoms3.sed\n$ ./remccoms3.sed Abstract.php > Abstract-no-comments.php\n$ wc -c Abstract-no-comments.php\n21022 Abstract-no-comments.php\nThat\u2019s about a 50% reduction. If disk storage is really a concern, we\u2019d be much better off to remove comments than to convert spaces to tabs. Of course, we could do both.
\nThis example makes me believe that the \u201cfile size\u201d argument, while factually correct, is a case of \u201coptimizing on the wrong resource.\u201d That is, the argument gives strong consideration to a low-value item. Disk space is pretty cheap, after all.
\nA followup argument about this is usually, \u201cEven so, it\u2019s less for the PHP interpreter to deal with. Fewer characters means faster code.\u201d Well, not exactly. Whitespace is tokenized, so the parser sees it all the same.
\nThis, to me, seems to be the primary argument for preferring tabs over spaces for indenting. Essentially, the idea is to allow each individual developer on a project to make the code look the way that individual developer prefers.
\nThis is a non-trivial argument. It\u2019s very appealing for the individual developers to be able to work on a project where Developer A sees a tab stop every 4 characters, and Developer B sees a tab stop every 2 or 8 or whatever characters, without changing the actual bytes on disk.
\nI have two arguments against this; they seem to be minor, until we examine them in practice:
\nIt becomes difficult to recognize line-length violations with over-wide tab stop settings.
\nUnder sophisticated style guides, inter-line alignment for readability becomes inconsistent between developers using different tab stops.
\nThese arguments require a little exposition.
\nBecause of limitations of this blog, let\u2019s say that our coding style guide has a line length limit of 40 characters. (I know, that\u2019s half or less of what it should be, but it serves as an easy illustration.)
\nThe following code, with 4-character tab stops, shows what that line length limit looks like:
\n 1 2 3 4\n1234567890123456789012345678901234567890\nfunction funcFoo()\n{\n $varname = '12' . funcBar() . '34';\n}\nIt\u2019s clearly within the line length limit. But it looks like this under an 8-character tab stop:
\n 1 2 3 4\n1234567890123456789012345678901234567890123\nfunction funcFoo()\n{\n $varname = '12' . funcBar() . '34';\n}\nA developer who sees this code under 8-character stops will think the line is past the limit, and attempt to reformat it in some way. After that reformatting, the developer working with 4-character tab stops will think the line is too short, and reformat it back to being longer. This is not particularly productive.
\nSome will say this just shows that line length limits are dumb. I disagree.
\nBy \u201cinter-line alignment\u201d I mean the practice where, if we have several lines of code that are similar, we align the corresponding parts of each line in columns. To be clear, it\u2019s not that unaligned code is impossible to read; it\u2019s just noticeably easier to read when it\u2019s aligned.
\nTypically, inter-line alignment is applied to variable assignment. For example, the following unaligned code \u2026
\n$foo = 'bar';\n$bazdib = 'gir';\n$zim = 'irk';\n\u2026 is easier to scan in columns aligned on the = sign:
$foo = 'bar';\n$bazdib = 'gir';\n$zim = 'irk';\nWe can see clearly what the variables are in the one column, and what the assigned values are in the next column.
\nAlternatively, we may need to break an over-long line across several lines, and make it glaringly obvious during even a cursory scan that it\u2019s all one statement.
\nNow, let\u2019s say we have a bit of code that should be aligned across two or more lines, whether for readability or to adhere to a line length limit. We begin with this contrived example using 4-space indents (the spaces are indicated by \u2022 characters):
\nfunction funcName()\n{\n\u2022\u2022\u2022\u2022$varname = '1234' . aVeryLongFunctionName() . 'foo' . otherFunction();\n}\nUnder a style guide where we align on = to keep within a line length limit, we can do so regardless of tab stops:
function funcName()\n{\n\u2022\u2022\u2022\u2022$varname = '1234' . aVeryLongFunctionName()\n\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022 . 'foo' . otherFunction();\n}\nUnder a guide where we use tabs, and Developer A uses 4-character tab stops, we need to push the alignment out to the tab stops to line things up (tabs are indicated by \u2192 characters):
\nfunction funcName()\n{\n\u2192 $varname\u2192 = '1234' . aVeryLongFunctionName()\n\u2192 \u2192 \u2192 \u2192 . 'foo' . otherFunction();\n}\nHowever, if a Developer B uses an 8-character tab stop, the same code looks like this on Developer B\u2019s terminal:
\nfunction funcName()\n{\n\u2192 $varname\u2192 = '1234' . aVeryLongFunctionName()\n\u2192 \u2192 \u2192 \u2192 . 'foo' . otherFunction();\n}\nThe second example has the same tabbing as in the first example, but the alignment looks broken under 8-character tab stops. Developers who prefer the 8-character stop are likely to try to reformat that code to make it look right on their terminal. That, in turn, will make it look broken for those developers who prefer a 4-character stop.
\nThus, the argument that \u201ceach developer can set tab stops wherever he likes\u201d is fine in theory, but is flawed in practice.
\nThe first response to alignment arguments is generally: \u201cUse tabs for indenting and spaces for alignment.\u201d Let\u2019s try that.
\nFirst, a 4-character tab stop indent, followed by spaces for alignment:
\nfunction funcName()\n{\n\u2192 $varname = '1234' . aVeryLongFunctionName()\n\u2192 \u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022 . 'foo' . otherFunction();\n}\nNow, an 8-character tab stop indent, followed by spaces for alignment:
\nfunction funcName()\n{\n\u2192 $varname = '1234' . aVeryLongFunctionName()\n\u2192 \u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022 . 'foo' . otherFunction();\n}\nThat looks OK, right? Sure \u2026 until a developer, through habit (and we are creatures of habit) hits the tab key for alignment when he should have used spaces. They are both invisible, so the developer won\u2019t notice on his own terminal \u2014 it will only be noticed by developers with other tab stop preferences. It is the same problem as before: misalignment under the different tab stop preferences of different developers.
\nThe general response at this point is to modify the tab-oriented style guide to disallow that kind of inter-line alignment. I suppose that is reasonable if we are committed to using tabs, but I find code of that sort to be less readable overall.
\nThe solution to these subtle and sophisticated issues, for me and for lots of other PHP developers, is to use spaces for indentation and alignment. All professional text editor software allows what are called \u201csoft tabs\u201d where pressing the tab key inserts a user-defined number of spaces. When using spaces for indentation and alignment, all code looks the same everywhere, and does not mess up alignment under different tab stop preferences of different developers.
\nI realize this is a point of religious fervor among developers. Even though I have a preference for spaces, I am not a spaces zealot. This post is not evangelism; it is a dissection of the subtle and long-term issues related to tabs-vs-spaces discovered only after years of professional collaboration.
\nPlease feel free to leave comments, criticism, etc. Because this is such a touchy subject, please be especially careful to be civil and maintain a respectful tone in the comments. If you have a very long comment, please consider pinging/tracking this post with a blog entry of your own, instead of commenting directly. I reserve the right to do as I wish with uncivil commentary.
\nThanks for reading, all!
\n" }