Check Source

["Morrison, John" <Jo...@uk.experian.com>]

Hi,

Please read the attached EMail.  Basically this is *easy* to integrate
in the build as a seperate target.  Question is: should I.  Do people
see the point of this?

I added it (temporarily) and we have currently got "13779 errors".  Now,
most of these errors are, in all likelyhood, very trivial (whitespace
for example)...

Should it be available?

Additional jar's at compile time:

antlr.jar
checkstyle-1.4.jar
jakarta-regexp-1.2.jar

J.

-- 

The problem with engineers is that they tend to cheat in order to get
results.

The problem with mathematicians is that they tend to work on toy
problems in order to get results.

The problem with program verifiers is that they tend to cheat at toy
problems in order to get results.



=======================================================================
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF

Re: Check Source

[Ross Gardler <rg...@wkwyw.net>]

I'm new to this list and have yet to contribute in any way. However, I 
feel sure that my opinion will be as valid as any other so here goes...

I feel that conformance to coding standards is very important any 
project. In my internal projects I always enforce adherence to these 
standards (and will now consider using this application rather than 
relying on the code prettifiers in our IDE). I therefore feel that 
integrating this software is of great value.

13779 errors is a great many erros but if we encourage all developers to 
correct any they see in code they work on these should gradually reduce. 
For example Konstantin Piroumian recently highlighted a number of 
problems in some code he is looking at, perhaps he will take the time to 
fix them now he knows what standard we should be using. In the tiny bit 
of code he quotes there are 5 errors, all very easy to fix (especially 
if you have a code prettifier in your IDE which is set to the SUN 
standards).

I would say yes, lets have it, but lets not try and remove the 13000+ 
errros in one go. As long as the figure falls slowly and new 
contributions to not make it rise then we should eventually win the battle.

Ross


Morrison, John wrote:

>Hi,
>
>Please read the attached EMail.  Basically this is *easy* to integrate
>in the build as a seperate target.  Question is: should I.  Do people
>see the point of this?
>
>I added it (temporarily) and we have currently got "13779 errors".  Now,
>most of these errors are, in all likelyhood, very trivial (whitespace
>for example)...
>
>Should it be available?
>
>Additional jar's at compile time:
>
>antlr.jar
>checkstyle-1.4.jar
>jakarta-regexp-1.2.jar
>
>J.
>
>
> ------------------------------------------------------------------------
>
> Subject:
>
> Release 1.4 of Checkstyle
> From:
>
> Oliver Burn <ol...@cortexebusiness.com.au>
> Date:
>
> Thu, 24 Jan 2002 12:17:25 -0000
> To:
>
> ant-user@jakarta.apache.org
>
>
>Announcing release of 1.4 of checkstyle is available at:
>
>	http://checkstyle.sourceforge.net/
>
>What is it?
>===========
>
>Checkstyle is a development tool to help programmers write Java code that
>adheres to a coding standard. Its purpose is to automate the process of
>checking Java code, and to spare humans of this boring (but important)
>task.
>
>Checkstyle can be run via an ANT task (recommended) or a command line
>utility.
>
>
>What Changed?
>=============
>
>The detailed release notes can be see at
>http://sourceforge.net/project/shownotes.php?release_id=71711.
>
>Checkstyle now defaults to supporting the Sun coding standard "out of the
>box", but it is still highly configurable. Many new checks have been added
>or improved, and the performance has been improved by ~50%.
>
>It is now possible to configure Checkstyle to just check for unused import
>statements.
>
>Regards,
>Oliver
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>

-- 
--------------------------------------------
Ross Gardler
Tel: +44 (0)777 6231913




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org