[racket-dev] current-*-port
On Fri, May 4, 2012 at 4:04 PM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:
>
> On May 3, 2012, at 11:03 PM, Neil Van Dyke wrote:
>
> > Matthias Felleisen wrote at 05/03/2012 10:57 PM:
> >> I don't think Eli is proposing an elimination of the old names but
> supplementing the code base with new ones.
> >>
> >> I am in favor -- Matthias
> >
> > Would be good to have a shorter naming convention for all parameters.
> The "current-" prefix is not short, but it's what I've been using when
> coding new parameters, because that's the convention.
> >
> > Of course, a naming convention is much less important when we have
> static checking of argument types, but we usually don't.
>
>
> General, off specific topic:
>
> Even in the presence of [on-line] type checking, naming conventions make
> programs readable, as do other conventions.
>
If I may add my opinion:
They also make programs easier to write.
And you've probably already been there several times, but:
However, long names make programs both easier and harder to read: many
symbols on the screen gives a lot of information to the eye, which then
takes more time to see relevant info.
As sad as I am to say this, "arr[x] = 3" is read quicker by the eye than
"(vector-set! my-integer-array the-current-iterator the-number-three)"
(obviously exaggerating): for the reader to understand what the
instruction/expression means the former only requires syntactic reading,
i.e. quick pattern matching for the mind, whereas the latter requires
semantic expansion of the words, although the "!" here is helpful.
I'm certainly not advocating very short names though (and I also like
Racket's real words, although sometimes it is indeed too long), just
stating some debatable thoughts.
An interesting idea would be to count the number of times each identifier
is used in the sources, and see how many characters would be saved by using
different conventions.
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120504/00ccb0fa/attachment.html>