English unabbreviated names seem like the way to go (they're not long if you're used to AbstractWidgetWithNetworkingConfigurationFactorySingleton or something like that from that Java world).
I don't think it's about the number of keystrokes though - for two reasons: [1] Your editor (/IDE) should help you complete the keywords and type names [2] Code comprehension research so far shows it's about word count not character count - i.e. the more words of code you have to read, the longer it takes to comprehend I personally prefer to have an editor that can code complete as it both reduces the number of keystrokes and allows me to remember names of concepts rather than abbreviations or particular combinations of class names. I haven't written much Rust code because of a lack of good editor. When someone in your team asks you - hey, can you help me with this problem - I often find myself reading code that I've never seen and simulating what it's doing in my head. If I also had to learn a vocabulary or look at the documentation while standing at someone else's desk then debugging the code would take longer. Good code should be self-documenting - you read it once, and you can begin to understand what it's doing. Symbolic abbreviations (like @ or ~ are different because there are a fixed number of them with a fixed meaning) and you should be able to learn these when you've learnt the language. This is in contrast to abbreviations like 'ccx' or 'bcx' where the number of abbreviations is not fixed and differs from program to program. Obviously this is all just my opinion. Thanks, Vlad On Tue, Jul 17, 2012 at 10:37 PM, Tim Chevalier <[email protected]> wrote: > On Tue, Jul 17, 2012 at 2:23 PM, Elliott Slaughter > <[email protected]> wrote: >> Take, for example, trans/base.rs in the Rust code base. The code uses >> abbreviations fairly aggressively, including ccx, bcx, icx, ty, ti, insn, >> ptr, t, incr, sess, among others. None of these are especially difficult to >> figure out, but the time it takes to get used to the code is non-zero. >> > > This could be addressed by better documentation (inline comments or > something else). The advantage of that is that the documentation is > confined to one part of a particular module that no one needs to > re-read once they've learned what the abbreviations mean; in contrast, > everyone pays the cost of using (both typing and reading) long names > over and over. > > Also, since in Rust it's usually visually apparent what the type of a > variable is, at least if it's a function argument or a top-level > function, all you really need to do to figure out what "ccx" or "bcx" > means is figure out their types. The piece that's missing right now is > useful documentation for each type. > >> 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. >> > > Likewise, I think that's a documentation issue. > >> 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? > > To me, short versus long names are a matter of taste and not something > we should dictate. Different contexts suggest different sorts of > naming conventions. I trust anyone who is sensible enough to choose > Rust to be sensible enough to choose those conventions for themselves > :-) > > Cheers, > Tim > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "Debate is useless when one participant denies the full dignity of the > other." -- Eric Berndt > _______________________________________________ > 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
