Tabs versus Spaces in Source Code

Kaz Kylheku kkylheku at gmail.com
Tue May 16 13:51:35 EDT 2006


Xah Lee wrote:
> Tabs vs Spaces can be thought of as parameters vs hard-coded values, or
> HTML vs ascii format, or XML/CSS vs HTML 4, or structural vs visual, or
> semantic vs format. In these, it is always easy to convert from the
> former to the latter, but near impossible from the latter to the
> former.

Bahaha, looks like someone hasn't thought things through very well.

Spaces, under a mono font, offer greater precision and expressivity in
achieving specific alignment. That expressivity cannot be captured by
tabs.

The difficulty in converting spaces to tabs rests not in any bridgeable
semantic gap, but in the lack of having any way whatsoever to express
using tabs what the spaces are expressing.

It's not /near/ impossible, it's /precisely/ impossible.

For instance, tabs cannot express these alignments:

  /*
   * C block
   * comment
   * in a common style.
   */

  (lisp
   (nested list
    with symbols
    and things))

  (call to a function
        with many parameters)
  ;; how do you align "to" and "with" using tabs?
  ;; only if "to" lands on a tab stop; but dependence on specific tab
stops
  ;; destroys the whole idea of tabs being parameters.

To do these alignments structurally, you need something more expressive
than spaces or tabs. But spaces do the job under a mono font, /and/
they do it in a completely unobtrusive way.

If you want to do nice typesetting of code, you have to add markup
which has to be stripped away if you actually want to run the code.

Spaces give you decent formatting without markup. Tabs do not. Tabs are
only suitable for aligning the first non-whitespace character of a line
to a stop. Only if that is the full extent of the formatting that you
need to express in your code can you acheive the ideal of being able to
change your tab parameter to change the indentation amount. If you need
to align characters which aren't the first non-whitespace in a line,
tabs are of no use whatsoever, and proportional fonts must be banished.




More information about the Python-list mailing list