Having recently read a considerable amount of code in SpiderMonkey and quite a bit in various parts of the Rust compiler, I can attest to strong use of abbreviated names making things much harder to understand.
While Tim is right about documentation helping with that, I agree with Patrick that that just doesn't scale indefinitely. Also, at least for me, the additional burden of keeping a translation table in my head makes a surprisingly big difference in my ability to parse code and figure out its semantics quickly. The bottom line is that I don't think it's just a matter of taste: it's a usability issue. Maybe not the biggest one, but certainly not a small one, either. On Wed, Jul 18, 2012 at 6:03 AM, Niko Matsakis <n...@alum.mit.edu> wrote: > 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 >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
