Mon Mar 19 06:28:53 CET 2007
> } Source files should be kept to a maximum width of 80 columns;
On 16 Mar 2007, at 8:36 am, Vance Shipley wrote:
> A number of years ago I would have whole heartedly agreed
> but no longer. A few years ago I did a project which used
> ASN.1 and it ended up having really long names which I did
> not have the luxury of choosing. It became impractical to
> use 80 column pages. I did all my work in 132 column windows
> for that project. I now find I really prefer working that
> way as I have plenty of glass these days. I wouldn't however
> unecessarily force others into it.
The psychology-of-reading results really do seem to be clear this time"
narrower columns really ARE easier to read. That doesn't mean 80
is right. 80 columns is too wide. It's a tradition that goes back to
punched cards, not something which is grounded in human factors.
I suspect that anyone who claims to find 132 columns comfortable is
suffering from a bit of protective self-deception. I've spent my time
reading with a ruler in my hand and have no desire ever to repeat it.
While consenting adults may do whatever they please in the privacy of
their cubicles, that does not mean that beginners should be encouraged
to flout what little we know about readability.
The important point is that anyone who DISTRIBUTES a file in
wider-than-80-column format *IS* thereby 'unecessarily forc[ing] others
to' deal with it.
Also, while it may be straightforward to switch your terminal to 132-
column mode, or to stretch your window sideways, you cannot stretch your
printer to handle such stuff without substantially reducing the
size. I like to print listings off and take them home to look at.
I do not enjoy reading with a microscope.
So the point remains:
If you want OTHER people to read your stuff, have the elementary
courtesy to keep the lines 80 characters or narrower, and if you
can keep them 72 characters or narrower, so much the better.
> } Source code should be indented using your text editor's indentation
> } features, NOT one tab per tab stop. 8-column indentations (what
> } get when you use the tab key) are eye-jarring.
> That is just wrong. First of all tabs are whatever your tabstops
> are currently set to.
'That is just wrong' is forcefully put, but quite untrue,
and the second sentence gives the very reason that it is untrue.
YOUR tabstops are whatever YOU have set them to.
The tabstops I see are for the most part whatever I have been given
and are almost certainly *NOT* the tabstops you see.
Some of the editors I use can set tabstops; some can't.
Some of the commands I use for printing files can set tabstops;
some can't. The ones that do don't use the same options (-e, -T,
others). NONE of these programs have ANY idea what YOUR tabstops
are, and the default is the standard tab=8.
> I write all my code using tabs for indentation
> the beauty of which is that you can easily change the appearance to
> your personal taste (i.e. in vi: set ts=3).
The ugliness of this is that YOU see what you want, but NOBODY ELSE
can tell that you ever did 'set ts=3'. If you embedded the command in
the source code, it is quite certain that other people reading the
code will do so using a different editor that doesn't know how to read
those embedded commands.
I don't care what keys you press to make indentation happen (the TAB key
in Emacs doesn't normally insert a literal tab; Vi uses > and < for
changing indentation; Xcode uses Cmd-] and Cmd-[; &c). You could do it
by clicking your teeth like castanets for all I care. But if you want
other people to be able to look at your code and see what you see, any
tabstops had better be 8 columns apart, and it is best of all if there
are no tab characters in the file at all.
There used to be a compression benefit from using tabs instead of
but with 720GB discs the price they are, I care a lot less about that
than I used to.
But we do agree that Emacs is pathetic at choosing where to indent.
More information about the erlang-questions