Most people would not understand why anyone would even have a preference on how many spaces a text file should be indented, but for people who interact with text files all day this can be a big deal. Seriously. People like to feel comfortable in their work places, and for software developers, or coders, their work place is their source files. Consider this analogy. It should not matter which side of my desk the phone is on, yet I prefer to have my phone on the left. The reason for my preference is that I often need to use my mouse while I am on the phone, so it is more convinient for me to reach over with my left hand and pick up the phone while leaving my right had free. I would expect a leftie to have the exact opposite preference.
The key concept here is that of preference. In almost all cases, the use of tabs or spaces will not impact the resulting program, it only impacts the developers who interact with the raw source code. Of course Python is the notable exception to this. Python was designed without block delimiters to enhance ease of use, as a consequence of that indenation was choosen as the semantic for block scoping. So, for Python, indentation is an integral part of the language and thus not really open to individual preferences. For languages with explicit block delimiters this should not be an issue. Preference, or the ability to exercise ones preferences, can make people feel more efficient; people should be able to exercise their preferences wherever practical.
As with anything, some people will claim that this is in fact not a preference. I, however, have found no logical reason which would mark this as anything other than a preference. If you have an unyeilding dogmatic conviction that either tabs or spaces is the right thing to do, then I probably don’t want to be on your team; your closed-mindedness will likely impact other areas of your work, and your inabilty to compromise will inhibit accomplishment of meaningful objectives.
But, regardless of whether you beleive it is a preference or not, as technologists we should all be able to agree that there should be a technological solution to the problem of tabs versus spaces. At this point in time, it really should not matter how the code is actually formated, it should just show how I want it to show. Here is a rough outline of what I think should happen:
It could be difficult to get this approach to work properly on lines of code which are continuations of previous lines but have been spaced to match up with the preceeding lines. (Example 1) Of course, for me, ever since the advent of horizontal scrolling and word-wrap, I just write a line of code on one long line, or I refactor to make it smaller.
Christopher// Example 1 -- original
static void metasyntactic(int foo,
===>===>===>===>===>===>..int bar)
So, I am not a fan of perfeclty spacing out parameters. Assuming that Lehman’s First Law is valid, all software which is actually used will need to evolve. As the software evolves there is a good chance the method name will need to be changed. Then, one of three silly things will happen: the person making the change will feel compeled to keep the method name the same length as it was; the person will change the method name and re-space the subsequent lines marking them as changed in the commit; the person will just make the relevant change and the subsequent lines will no longer be aligned. (Example 2) Being a pragmatist, I realize that someday an intern will be maintaining my code, so I don’t spend too much time aligning parameters. The beauty of my code comes from the logical structure, not the physical structure. Or so I like to think.
// Example 2 -- refactor
// metasyntactic is to hard to remember
static void placeholderName(int foo,
===>===>===>===>===>===>..int bar)
The inteligent editor approach also does not address using tabs or spaces for end of line comments. But, for the same reasons I just mentioned, I prefer to have comments on their own lines rather than at the end, especaially when they span more than one line. (Example 3)
// Example 3
int fubar(int foo, int bar)
{
===>int flu = 0;===>===>/* Below this line,
===>===>===>===>===>===>...but above this line
===>===>===>===>===>===>...is where a student might
===>===>===>===>===>===>...add a variable declaration */
===>int bla = 0;
===>return 0;
}
Of course, an editor that operates as described above would natively save indentation using tabs; tabs take up less memory, and it is slightly easier to convert tabs to spaces than spaces to tabs. But, lest you think that I am a tabs indentation zealot, I actually tend to use IDE defaults where possible. It’s only when I jump into the freedom of an unopinionated editor that turn on tab indentation styles.
Though not what I had envisioned, someone showed me EditorConfig. This is a plugin for various text editors which will help ensure that project defined styles will be used. If a .editorconfig file is added to the project directory, then every editor with the plugin will change its settings to match those set by the project.
