Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
nobody at 127.0.0.1
Thu May 18 02:34:15 CEST 2006
We've finally hit the meta-discussion point. Instead of talking about tabs
and spaces, we're talking about talking about tabs and spaces. Which
frankly is a much more interesting conversation anyway.
> Does it matter? Perhaps not if we can use tools which enable us to
> bridge the divide, like indent auto-detection in emacs and vim. I'm
> prepared to do that in cases where I have to work with an existing
> group of coders uasing spaces.
If you ask me, which of course you didn't, indentation is just one small
part of the larger issue of code formatting. Unfortunately it's the only
one that allows some semblance of flexibility. Formatting like brace/paren
placement and inter-operator spacing greatly affect readability but are
hard-coded into the source. And none of this matters a wit to the
semantics of the code.
What really should happen is that every time an editor reads in source code,
the code is reformatted for display according to the user's settings. The
editor becomes a parser, breaking the code down into tokens and emitting it
in a personally preferred format. Comments are left untouched apart from
initial indentation. On output back to a file, the code can be either
written as-is (the next guy's editor will reformat it anyway) or put in
some standard form (for the poor shlubs who code with cat/notepad).
All this becomes completely transparent to the user, who sees every file he
edits in exactly the format he's accustomed to. It's similar to the
various pushes for syntactic code storage formats like abstract syntax
trees or <shudder> xml, but works with the existing infrastructure built
around processing plain text files. Meanwhile LISP has been storing code
in paren-based ASTs since the 50s.
vim and emacs can already do this today. It might not be perfect, but if
people spent half as much time perfecting this as arguing about tabs vs
spaces, we'd all be a lot better off (yes I'm guilty too).
> It's a cruel irony that Python's creator
> didn't appreciate the benefits that tab indentation would bring to his
> own language - the only major language in which indentation levels
> actually have semantic significance.
Fate is a cruel mistress. Or maybe just a heartless bitch. Either way,
watch your back.
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
More information about the Python-list