checkstyle on axis

[Steve Loughran <st...@iseran.com>]

Axis has now its own checkstyle run; go ant checkstyle in the base dir with
checkstyle.jar downloaded from checkstyle.sf.net and placed into
ANT_HOME\lib. You need xalan there for the next stage of the build; a
transform of the XML report into HTML.

If you run the task in the Jedit command window BTw, you can even go from
the rolling error log to the lines, though 4000+ errors does give jedit
problems.

I have done the .* imports, JLS issues and errant tabs. If any more crop up
now, we can go through the CVS logs to see who put them there :)

This leaves the key diffs between axis source and the sun style rules as

-nowhere near enough javadocs (that is turned off in checkstyle as it was
too distracting)

-not enough use of braces after if()  and  else clauses. I know it's extra
work, I know it bloats methods, but it is important for maintenance.

-inconsistent variable naming. A bit of the _something style, some of the
m_something; these should be cleaned up in a refactoring IDE.

-too much scope given for things. Example, all the logs that classes create
that dont have private scope. This should be tightend up on a case by case
basis.

-lines too long. 68 chars is the rule, we have many over 100, some over 250.
Again, this causes maintenance and readability issues.

-different brace rules, traces of other styles in there.

Having now been into bits of the code I normally ignore, the lack of javadoc
comments and general readability in places worries me. The deliverables of
an open source project are not just the binaries and end user docs, they are
the source and the source docs, and Axis is weak there. If the source is
hard to work with, people wont work with it.

>From now on I'm only going to clean up files on a case by case basis, as and
when I work with them. It would seem a good habit to start by javadocing a
file when you get to work with it, then re-lay out the bracing; commit that
change then maybe do some of the other cleanups before anything else. The
aim should be that not only is the total number of checkstyle errors reduced
(4049 ignoring javadocs), but that whole files dont raise a single warning.

-Steve

Re: checkstyle on axis

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Steve Loughran" <st...@iseran.com>
To: "axis-dev" <ax...@xml.apache.org>
Sent: Thursday, August 29, 2002 2:18 PM
Subject: checkstyle on axis


>
> Axis has now its own checkstyle run; go ant checkstyle in the base dir
with
> checkstyle.jar downloaded from checkstyle.sf.net and placed into
> ANT_HOME\lib. You need xalan there for the next stage of the build; a
> transform of the XML report into HTML.
>
> If you run the task in the Jedit command window BTw, you can even go from
> the rolling error log to the lines, though 4000+ errors does give jedit
> problems.


and on checkstyle 2.3, that number goes up to 5000+

But on a brighter note, Mark Roder has pointed me at jalopy;  jalopy.sf.net,
that not only cleans up source, it can apparently do fancy thngs like insert
logger.isDebuggerEnabled() probes around log.debug statements.

I'll see how easy it is to use on my own code...