[rust-dev] Bikeshed proposal to simplify syntax
pwalton at mozilla.com
Tue Jul 17 14:39:37 PDT 2012
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
> 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:
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.)
More information about the Rust-dev