emacs-lisp-style-guide
emacs-lisp-style-guide copied to clipboard
bbatsov
Why 2 spaces rather than tabs?
No reasons are given for the recommendation to use two spaces rather than single tabs in indentation. At least two questions must be answered: (1) Why prefer spaces to tabs and (2) Why prefer multiples of 2 spaces? Addressing the second question: Arbitrary numbers are always suspicious; in this case the result is an amount of indentation which looks good with some choices of font sizes, printing options, etc. and looks poor under other circumstances. Addressing the first question: Since the display width of tabs is easily adjustable, e.g. to the width of 2 spaces when desirable, and this functionality is not available with spaces, why would one not always prefer tabs? Note also that the recommendation of using multiples of 2 spaces conflicts with the recommendation to align with the first argument of forms. A logical alternative might be to use tabs to align to the level of the form followed by spaces to align with the first argument.
I've reordered the quotes a bit.
(1) Why prefer spaces to tabs?
Note also that the recommendation of using multiples of 2 spaces conflicts with the recommendation to align with the first argument of forms.
As you mentioned above, indentation is not /really/ always a multiple of 2 (I'll make a PR to reorganize that section and make that more clear), it is either 1, 2, or any number which vertically aligns the arguments. So we can't use only tabs.
A logical alternative might be to use tabs to align to the level of the form followed by spaces to align with the first argument.
In the end, that's a double-edged blade. If you use tabs so that the guy next to you can make it look better on his font, it just might end up looking worse because his tabs are configured for another language or not configured at all. On a more subjective note, it also sounds unnecessarily complicated, "spaces-only" is simple and effective.
(2) Why prefer multiples of 2 spaces?
Arbitrary numbers are always suspicious; in this case the result is an amount of indentation which looks good with some choices of font sizes, printing options, etc. and looks poor under other circumstances.
Because we follow Emacs' source.
Just to reiterate--the alignment recommendations come from the Emacs auto-alignment engine, which is the canonical reference for Emacs Lisp alignment (the conventions are very old and mostly common to other Lisp dialects). As for tabs vs. spaces, that's more of a matter of opinion (there's no official recommendation in the manual, and the Emacs source code contains a mixture of tabs and spaces), but spaces are simple and consistent. (I think tabs for indentation are an especially poor choice for Lisp, since the indentation rules are more complicated than in C-based languages and necessarily involve a mixture of tabs and spaces.)
As for tabs vs. spaces, that's more of a matter of opinion (there's no official recommendation in the manual, and the Emacs source code contains a mixture of tabs and spaces), but spaces are simple and consistent.
AFAIK there's a policy to move toward spaces in the Emacs source, but this happens slowly as they don't want to simply run untabify on all the source code at once.
A logical alternative might be to use tabs to align to the level of the form followed by spaces to align with the first argument.
In a perfect world, this rule would be applied in any text based language I can think of.
Reality is that:
- both tabs and spaces are hidden symbols by default on any IDEs or text editors I can think of, and being able to see those symbols is mandatory to effectively apply the rule
- from the above point, you are forcing people to watch at noisy symbols which don't bring any additional sense to their code, there are just here for formatting purposes
I was like you a few years ago and I had hidden characters slightly visible all the time, it worked great.... when I was the only one editing the code, which defeats the purpose of the whole point.
We can transpose the same formatting debate to length of lines of code, and the answer is the same:
stick with what peers found the most effective and adapt.
AFAIK there's a policy to move toward spaces in the Emacs source
No actually policy, but more like a gentle recommendation, currently.
