ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: Ant Coding guidelines
Date Mon, 14 Jan 2002 19:24:56 GMT

----- Original Message -----
From: "Conor MacNeill" <conor@cortexebusiness.com.au>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Sent: Monday, January 14, 2002 04:46
Subject: Re: Ant Coding guidelines


> Stephane Bailliez wrote:
>
> >
> > 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 :-)

We use the _ prefix in our own code here; "fowler style", for the following
reasons
1. -distinguishes class from local variables.
2. -works great with jedit completion; hit _ and then ^B and you get a list
of member fields

But both of these could be addressed with better editors; the editor should
colour members differently from locals, for example.

The .net classes in ant show this style of coding, but everything else is
consistent with sun

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

I think I go along with this. While I am willing to use a different policy
on in-house code, I think we should be consistent with the rest of the world
in open source dev.

See also : http://www.ambysoft.com/javaCodingStandards.html  (he forgets to
say "if you implement finalize(), always call super.finalize(); my old style
guidelines from past (1998 era) projects
http://www.iseran.com/Win32/Articles/java_style_guidelines.html ...etc.

I use jEdit's javastyle plugin to lay out and stub doc comment our code;
that is an easy xform to apply to files before they get committed

As mentioned, check style can be a code policeman. Maybe we should consider
running some of these external tasks over the codebase on a nightly basis,
to keep us in line

 -checkstyle
 -doxygen
 -xdoclet for todo

regarding coding guidelines, I have started to use @since tags on new
classes, methods; but we need to formalise what is it since? Ant versions or
versions of the class being edited? Or both?
I also use @todo as my marker for things to finish off; xdoclet does a great
things to do report from these, and that tag is promised by sun for real
javadoc eventually.

Plus of course: jdepend, <maudit> (litte french language joke there
Stephane?), and jprobe coverage. If someone has these tools on their system
they could do a regular code quality report, though of course without
everyone paying attention to the result the effort may be wasted.

I guess that is the diff between local team projects and big OSS efforts; it
is harder to enforce things. In our team we can say things like "Comment
your code like that and we send you the Cold Room for half an hour to
install stuff on the server"; the room being so cold that would be against
the law to send engineers to if it wasnt full of load balanced java app
severs. But at least cellphone coverage is so bad there management can't
find you, and since our student house in scotland was colder than that, I am
happy to sit there with a laptop for hours at a time, especially if it means
I can get away with single letter variable names.

-Steve








--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message