ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <>
Subject RE: Ant Coding guidelines
Date Mon, 14 Jan 2002 13:44:02 GMT
> -----Original Message-----
> From: Conor MacNeill []

> > 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 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.



To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message