This is interesting. When I first started working on the Rust compiler,
I very much enjoyed the Unix-like, abbreviated names. However, I have
to admit that reading Patrick's resolve3 code is making me ashamed of
the code I've written lately. I plan to go back and "verbos-ify" some
of my code. I do think it helps with readability overall, though it is
definitely true that if names are unnecessarily long (e.g.,
`ty_param_bounds_and_ty` or `optional_interface`) they can become
distracting. Also, our 78-character limit starts to become more of a
burden.
Niko
On 7/17/12 2:39 PM, Patrick Walton wrote:
On 7/17/12 2:23 PM, Elliott Slaughter wrote:
Now imagine that third-party Rust libraries follow this example. Now
I have to learn abbreviations for every library I use in my
application. If for any reason I need to modify a third party library
for my own purposes, I'll need to learn its internal abbreviations as
well.
Should we really be using short name everywhere? And if not, how do
we encourage people to use readable names, given the example we are
providing in the standard library?
Agreed. I personally prefer longer, unabbreviated names (and
camel-cased types) in user code for this reason. Keywords are a small
fixed set of things that all users of the language must know, while
user code contains an unbounded number of abbreviations in the limit.
See resolve3 for an example of this (although perhaps my names are
*too* long there...)
In general I'm not a big fan of Unix-command-line-style abbreviation.
It works and is elegant when programs are kept very small, but as
programs grow larger and larger programmers have to page in and out
abbreviations too often for easy reading. Functions like
CreateOrRecycleThebesLayer() and UpdateDisplayItemDataForFrame() in
Gecko may be lengthy, but they sure make digging through MXR easier.
Unix was forced to abbreviate for the 6 character limit, but that
doesn't exist anymore. In fact, modern Plan 9 code doesn't abbreviate
nearly as often as we do; they just pick short names. Take esc.c (just
as an example) from Go:
http://code.google.com/p/go/source/browse/src/cmd/gc/esc.c
We have escapes(), visit(), visitcodelist(), visitcode(), analyze(),
escfunc(), escloopdepthlist(), escloopdepth(), esclist(), esc(),
escassign(), esccall(), escflows(), escflood(), escwalk(), and
esctag(). If we assume that the "esc" prefix is just C namespacing,
then the only *abbreviation* there is "func". The rest are just short
names. The resulting code reads much nicer than the Rust code in our
compiler. Short names are fine and read well; abbreviations don't.
(In fact, I prefer unabbreviated keywords in general; I'd prefer
"return", "module", and "match", but I'm happy to yield to the tastes
of the community and BDFL here, since I feel that abbreviated keywords
have a much smaller cost than abbreviated user code.)
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
