Tabs -vs- Spaces: Tabs should have won.
dotancohen at gmail.com
Sun Jul 17 21:26:20 CEST 2011
On Sun, Jul 17, 2011 at 15:53, Thomas 'PointedEars' Lahn
<PointedEars at web.de> wrote:
>> I am also a recent spaces-to-tabs convert. One of the reasons is that
>> I've discovered that programing in a non-fixed width font is a real
>> pleasure, but the spaces are too narrow. Tabs alleviate that.
> Not using a fixed-width font avoids this problem and others in the first
>> I'm still looking for the perfect programming font. Suggestions welcomed.
> I can recommend Consolas (Windows) or Inconsolata (elsewhere), which are
> designed for programming and are near perfect in that regard. However, I
> have decided for "Deja Vu Sans Mono" for reading and writing Usenet articles
> because it supports more Unicode characters and can be sized appropriately
> for running text.
I have used those three in the past. Terrific fonts each of them,
especially Inconsolata if I remember correctly.
> But, all of them are fixed-width fonts. I do not understand how you can
> consider using a non-fixed-width font in programming "a real pleasure" as
> many them show a lot of ambiguities in source code. Take for example the
> lowercase "l" (el) vs. the capital "I" (ai) vs. the "|" (pipe) character,
> or the "0" (zero) vs. the capital "O" (oh) character in Arial.
The ambiguity has never been an issue for me. In the unlikely event
that an l (el) is in the place of a pipe, the code won't compile and
I'll get an error on the line in question. Though that has never
actually happened: the IDE is double-checking way before the code gets
to the compiler. Zero vs. O (oh), I've never had this issue either and
even if one key was hit in place of the other (they are close by) then
either the IDE or compiler would catch it, or it would result in a
minor bug in a text string.
It simply isn't an issue.
More information about the Python-list