[erlang-questions] On TABSTOPS Re: Semaphores
Mon Mar 19 07:47:08 CET 2007
This discussion has nothing to do with Semaphores anymore and has
degenerated into a "protective self-deception" -- the least one can do is to
change a message subjectso so we do not deceive others as well.
On the subject of tabstops: I'm using an editor that replaces TAB's with
configurable number of blank characters (spaces), thus insuring that anyone
can see my code the way I see it. Not as efficient regarding file's memory
utilization, but, hey, we're not in 70's.
----- Original Message -----
From: "ok" <>
To: "Erlang/OTP discussions" <>
Sent: Monday, March 19, 2007 7:28 AM
Subject: Re: [erlang-questions] Semaphores
>> } 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.
> erlang-questions mailing list
More information about the erlang-questions