Can I assume that silence is agreement on Ray's OTHER proposed change, namely that acronyms should be treated as words, thus GwtSomething and HtmlSomethingElse and TheUrlThing? If it's not clearly agree-to, I cast my support with Ray.
On the other point, I don't care much... my bike shed is a light gray. But if we do have to have a rule (I mostly agree with John Tamplin here), you also need to figure out what to do with the collision case (e.g. my class is parameterized for event, error, and exception types; that clearly can't be <E,E,E> so is it <V,E,X> or what? The acronym, incidentally, is uncontrived... but the point is that V won't scream "eVent" in the way that <K,V> screams Key,Value). If the point is to make parameters stand out as meta-types, perhaps they should by convention be all-caps? That collides with similar convention for statics, but I'd expect the uses for metatypes (i.e. declarations, casts, instanceof) to be clear enough in context. On Tue, Oct 28, 2008 at 2:34 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > > > On Tue, Oct 28, 2008 at 11:32 AM, John Tamplin <[EMAIL PROTECTED]> wrote: > >> On Tue, Oct 28, 2008 at 2:28 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: >> >>> I would be more in favor of forbidding them everywhere then allowing them >>> in only 1% of the cases, as knowing it is always the case that generics are >>> one letter is more useful, and easier to create automatic checks for, then >>> if it is true 99% of time. >> >> >> I still think the comparison to loop indices is useful -- we don't have a >> style guide entry for "you must use only i,j,k, etc for loop indices" nor do >> we require descriptive names -- we leave that up to the discretion of the >> author and reviewer that the naming is appropraite. I don't see any reason >> this should be treated differently. > > > Because at the moment our code is leaning too heavily toward long names and > away from standard short names, making our code hard to read for people used > to the rest of the Java world. Having a standard in place short circuits the > potential to bike shed on this issue on each CL. > >> >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
