The problem then is that it then becomes a bike shed discussion at many code reviews. I'd rather have a clear standard and not have to think about it all the time, almost regardless of what that standard is.
On Sun, Oct 26, 2008 at 1:26 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > > > I really think for simple collections it is much better to keep the > > single-letter conventions. T, E, K, V all seem clear enough in that > > context. I think it is like using for(int i=...) -- i is perfectly > > understood in that context so it is actually better than > > customerRecordIndex, even if the latter is more descriptive. > > I think the loop index is a good analogy and I agree that for simple > cases, single letter names for type parameters aren't harmful. Maybe > this needs to be examined on a case-by-case basis instead of a global > style rule? Could you rely on the discretion of the reviewer to > identify cases where longer, more descriptive type parameter names are > needed? Too much room for argument (like... this thread)? > > Oh, and +1 for bringing the caps-lock acronyms under control. > > > > On Sun, Oct 26, 2008 at 1:04 PM, John Tamplin <[EMAIL PROTECTED]> wrote: > > On Sun, Oct 26, 2008 at 12:51 PM, Isaac Truett <[EMAIL PROTECTED]> > wrote: > >> > >> This reminds me of prefixing interfaces with the letter "I" which I > never > >> took stock in either. Why is it important that type parameters stand > out? I > >> think the "Type" suffix that Emily mentioned is much better than a "T" > >> prefix; it is descriptive and unambiguous, and it leaves the code > looking > >> more Java-ish. Shouldn't the type parameter naming rule be the same as > for > >> any other Java identifier? Keep code self-documenting by naming things > what > >> they are. > > > > I really think for simple collections it is much better to keep the > > single-letter conventions. T, E, K, V all seem clear enough in that > > context. I think it is like using for(int i=...) -- i is perfectly > > understood in that context so it is actually better than > > customerRecordIndex, even if the latter is more descriptive. > > > > I agree if you have a generic which is not of that sort or if you have > lots > > of type parameters (analogous to using more descriptive loop indices when > > you have many levels of nesting), having more descriptive names is good. > > > > And I vote strongly against a T prefix -- I personally think Hungarian > > notation is a blight upon all programming :) (how often have you had to > go > > change lots of variable names when you changed the type of something or > > worse, had to look at code where they were too lazy to do that and the > > prefix was actively misleading?). So for the cases where they are > needed, I > > prefer the Type suffix or nothing. > > > > -- > > John A. Tamplin > > Software Engineer (GWT), Google > > > > > > > > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
