Tabs vs. Spaces for code indentation
The debate over whether to use tab characters
or spaces for indenting code is probably as old as Fortran. In fact, the
arguing over this topic has led to many a newsgroup and mailing-list flame
war, many whose intensity far surpass any Saturday night Quake Area session
your thirteen brother ever saw.
A tab in this context represents a unit of indentation, which should be separate from the "physical" size of the representation of that unit (on the screen). I happen to set all my editors to render that unit as equivalent to 4 spaces on the screen (even though the file only knows there is one unit of indentation, the tab character), but you may set your editor to render it as 2, 4, 8, or 100 spaces - whatever floats your boat. Point is, I don't care how big you want the indentation unit to be, and you shouldn't have to care how big I want(ed) it either. Any decent editor will let you control how tabs are rendered, and should preserve them in the file regardless of how they were rendered on the screen.
By always using tabs, my code always looks consistent when I write it and you can always make it the indentation as big or small you want it. What is important to the notion of a "unit of indentation" is not the size of the indents, but rather the position of statements relative to each other. Using tabs all the time preserves that property, but using spaces unnecessarily merges the notion of your or my particular visual choice with the notion of relative positioning.
The more important effect of using tabs
is that we abstract out the "unit of indentation" and each implement
it with whatever number of "simulated" spaces we prefer. Later,
if I decide my indentation unit rendering is not the right size for me,
I don't have to go change a bunch of existing code to be consistent nor
do you have to even know I changed my mind.
All photographs and content is copyright © 2003-2006 Eric Rizzo & Jazmine Rizzo