My two cents: When I was programming in C++ I liked the m_ prefix (and no other part of what was more generally called "Hungarian Notation"). Since I've moved over to java, I have tended toward a style of trying to always prefix fields with "this.", whether "necessary" or not. That seems stronger than "m_" even if it's more typing since it means something in the language, it's not just a convention. It sort of surprises me that I have come to prefer this style - earlier I wouldn't have been caught dead using a style like this. But I do prefer it now. Especially when I'm reading code. Does the Sun style guide say anything about this? -----Original Message----- From: Stephane Bailliez [mailto:sbailliez@imediation.com] Sent: Monday, January 14, 2002 7:44 AM To: Ant Developers List Subject: RE: Ant Coding guidelines > -----Original Message----- > From: Conor MacNeill [mailto:conor@cortexebusiness.com.au] > > Note: I don't like non-prefixed fields. Food for self > assignation problems. > > I presume you are referring to the "m_fubar" style field > names. I do not like them :-) Even though I don't like it very much, I find it better than 'fubar' alone. As I said I think this is food for problems because of the confusion that can arise when refactoring code w/ local or formal parameters. A mistake of self assignation is done quickly and from what I now, nearly every developer out there has been hit by the self assignation problem. Whatever the ego. I like the '_fubar' style :) In C++ I was using 'fubar_' or 'm_fubar' for obvious reasons that were barely mentioned in general. The ANSI standard states in paragraph lib.global.names that a leading underscore followed by a digit or lowercase letter is legal in the programmer's namespace but not in std:: or global namespace, however AFAIK when it has been reported that some compilers are using these identifiers. Concerning 2 consecutive underscores (whatever their position), they are reserved for implementation. There are no such things to my knowledge in Java, and _ makes things more readable and less error prone to me... As well it helps to be consistent since we never always use a prefix 'this.' for all references to fields but only when there is a clash between names. As I said this is food for mistakes. A software such as Parasoft JTest or Metamata Audit warns users about such multiple use of variables with same name, and it makes perfect sense to me. > I think that we should pretty much stick to the Sun standard. > Whatever > its faults, it is the defacto standard for Java programming. It is > likely therefore that most code submissions will, for better > or worse, > come in this style. There are sections where the Sun standard > is pretty > out of touch with common practice (such as restrictions on use of // > comments somewhere in section 5) and we should explicitly state our > decision to ignore those sections. Agreed. Stephane -- To unsubscribe, e-mail: For additional commands, e-mail: