commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: [general] checkstyle report
Date Sun, 20 Oct 2002 13:20:55 GMT
Just a note from some experiment I've done on projects at work and on
Cactus:

- I've turned on the build failure on checkstyle errors. The initial
period was a bit of a pain but then afterwards, everybody loved it as :
  - it is not possible to introduce any more coding convention error as
the build will report it (be it local build or Gump)
  - it forces each developer to correct one's own code and not force
other developers to correct checkstyle errors introduced by someone else
  - there is almost no overhead as commits are usually small, so
correcting a few checkstyle errors is absolutely not a pain
  - it kind of "forces" developers to run a local build before
committing, which should always happen

Now, in order to overcome the initial period where lots of checkstyle
errors exist, I've found the following strategies to work quite well:

- When using the checkstyle task, it is possible to specify the code the
classes that are checked. Thus, you would write 2 checkstyle checks: one
for code that is supposed to have no more checkstyle errors (and
failonerror is true for this ant task) and one for code that is not yet
free of checkstyle errors. As classes are cleared of checkstyle errors,
they are moved from one set to the other. This allow to gradually bring
number of errors to 0.

- The other solution is by checkstyle checks. It is possible to tell
checkstyle for example to only check for unused imports. So you could
also have 2 checkstyle tasks, one checking for some type of errors and
failing the build in case of error and another one checking for the rest
but not failing the build.

- Of course, the 2 approaches can be combined with no problem.

The only "issue" I would say is Maven. ATM, the checkstyle plugin for
Maven does not support this strategy. However, I believe it would be
quite possible and easy to implement it should it be something that we
want to do.

Just some thoughts ... I would be curious to know what you think :-)

-Vincent



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


Mime
View raw message