Not to start a religious war, but maybe using camelCase instead of under_score would save even more space given the 78-character line limit? :)
-- Ziad On Tue, Jul 17, 2012 at 9:03 PM, Niko Matsakis <[email protected]> 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<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<https://mail.mozilla.org/listinfo/rust-dev> >> > > > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
