Announcing that Checkstyle version 3.4 has been released and is available from http://checkstyle.sourceforge.net. See the release notes for the many changes since the last widely announced release - http://checkstyle.sourceforge.net/releasenotes.html.
Checkstyle is a tool for performing analysis on Java source code. It is most infamous for performing syntax checks and enforcing coding standards. However, it is very flexible and includes checks for:
* J2EE coding problems (http://tinyurl.com/2y9vz)
* Unused declarations (http://tinyurl.com/32vcd)
* Metrics analysis (http://tinyurl.com/28jma)
* Coding Problems (http://tinyurl.com/36jo9)
* Class Design (http://tinyurl.com/2hnjx)
* Many others including Javadoc Comments, Naming Conventions, Headers, Imports, Size Violations, Whitespace, Modifiers, Blocks, Duplicate Code, Miscellaneous others.
The Checkstyle architecture has been designed to allow custom checks to be easily developed. See http://checkstyle.sourceforge.net/writingchecks.html for more details.
Plenty of documentation is available at http://checkstyle.sourceforge.net.
Third-party plug-ins are available for Maven, jEdit, NetBeans, Centipede, JBuilder, Eclipse/WSAD, Emacs JDE, BlueJ.
Regards,
Oliver
PS: The Checkstyle team are not responsible for any suffering caused by inappropriate use! :-)
-
Checkstyle 3.4 released (27 messages)
- Posted by: Oliver Burn
- Posted on: May 18 2004 08:53 EDT
Threaded Messages (27)
- Checkstyle 3.4 released by Konstantin Ignatyev on May 18 2004 10:35 EDT
- Filtering errors by Daniel Grenner on May 18 2004 10:57 EDT
-
Filtering errors by Konstantin Ignatyev on May 18 2004 11:17 EDT
-
Filtering errors by D S on May 18 2004 11:29 EDT
-
Filtering errors by Konstantin Ignatyev on May 18 2004 11:38 EDT
-
Filtering errors by D S on May 18 2004 12:11 EDT
- Filtering errors by Konstantin Ignatyev on May 18 2004 12:38 EDT
-
Filtering errors by D S on May 18 2004 12:11 EDT
-
Filtering errors by Konstantin Ignatyev on May 18 2004 11:38 EDT
-
XDoclet? (Was: Filtering errors) by Craig Cottingham on May 18 2004 12:38 EDT
- XDoclet? (Was: Filtering errors) by Konstantin Ignatyev on May 18 2004 12:50 EDT
- Filtering errors by Pavel Vlasov on May 18 2004 03:09 EDT
- Filtering errors by Oliver Burn on May 18 2004 07:26 EDT
-
Filtering errors by D S on May 18 2004 11:29 EDT
-
Filtering errors by Konstantin Ignatyev on May 18 2004 11:17 EDT
- Custom Check - re filtering results by Adam Judson on May 18 2004 14:56 EDT
- Filtering errors by Daniel Grenner on May 18 2004 10:57 EDT
- Thanks ;) by Yoav Shapira on May 18 2004 10:43 EDT
- Theoretical basis for the metrics by Haagen Hasle on May 18 2004 10:44 EDT
- Theoretical basis for the metrics by Oliver Burn on May 18 2004 19:00 EDT
- Checkstyle 3.4 released by John Davies on May 18 2004 10:46 EDT
- Is it similar to hammurapi? by Marcin Gryszkalis on May 18 2004 12:28 EDT
- Checkstyle 3.4 released - Ant task bombs with Ant 1.6. by George Coller on May 18 2004 12:58 EDT
- Checkstyle 3.4 released - Ant task bombs with Ant 1.6. More by George Coller on May 18 2004 13:07 EDT
- Checkstyle 3.4 released - Ant task bombs with Ant 1.6. More by Oliver Burn on May 18 2004 06:56 EDT
- Ant task bombs with Ant 1.6. Fixed, thank you. by George Coller on May 19 2004 01:19 EDT
- Checkstyle 3.4 released - Ant task bombs with Ant 1.6. by scot mcphee on May 18 2004 19:46 EDT
- Checkstyle 3.4 released - Ant task bombs with Ant 1.6. by scot mcphee on May 18 2004 07:52 EDT
- Checkstyle 3.4 released - Ant task bombs with Ant 1.6. by Daniel Grenner on May 19 2004 04:07 EDT
-
Categorizing of deviations by Igor Semenko on May 19 2004 04:20 EDT
- We use it with Ant 1.6.1 as well... by Yoav Shapira on May 19 2004 09:35 EDT
-
Categorizing of deviations by Igor Semenko on May 19 2004 04:20 EDT
- How I fixed it (at least I thought I did) by Bing Wu on June 03 2004 15:56 EDT
- Checkstyle 3.4 released - Ant task bombs with Ant 1.6. More by George Coller on May 18 2004 13:07 EDT
-
Checkstyle 3.4 released[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: May 18 2004 10:35 EDT
- in response to Oliver Burn
Suggestion: Ideally I should be able to review that error or suggestion and mark it as OK, the tool will see the mark and do not show that violation again.
For instance I really want to hide a field with local variable by whatever reason: I should be able to mark such place as reviewed and be OK. -
Filtering errors[ Go to top ]
- Posted by: Daniel Grenner
- Posted on: May 18 2004 10:57 EDT
- in response to Konstantin Ignatyev
It is possible to filter messages by configuring a filter submodule. See http://checkstyle.sourceforge.net/config.html#filters for details. The SuppressionFilter is probably the most appropriate for what you are suggesting.
/Daniel -
Filtering errors[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: May 18 2004 11:17 EDT
- in response to Daniel Grenner
The SuppressionFilter is probably the most appropriate for what you are suggesting.
Yes, that filter can do the trick but it is not inconvenient for use IMO:
Such check as
<suppress checks="MagicNumberCheck"
files="JavadocStyleCheck.java"
lines="221"/>
implies that I should edit the file and edit the file again when I edit main source file. Looks like error prone and inconvenient routine. How about some source code level remarks like:
// @checkstyle:ignoreNextLines n=1
for( int myStupidLongNameForLoopingVariable = 0; -
Filtering errors[ Go to top ]
- Posted by: D S
- Posted on: May 18 2004 11:29 EDT
- in response to Konstantin Ignatyev
It's an open source project. If it doesn't do what you want, feel free to write your own improved version. -
Filtering errors[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: May 18 2004 11:38 EDT
- in response to D S
It's an open source project. If it doesn't do what you want, feel free to write your own improved version.
This exact attitude kills Open Source. No! Somebody (me) should not start new project just because an existing does not do exactly what that someone wants!!!
Contribute!!! Ideas, code, submit bugs, etc. -
Filtering errors[ Go to top ]
- Posted by: D S
- Posted on: May 18 2004 12:11 EDT
- in response to Konstantin Ignatyev
If an open source project doesn't do what you want you have three choices:
1. Bitch and whine about the fact that it doesn't do what you want and expect someone else to fix it for you for free.
2. Take the code and create your own version with the features you want. Whether you keep this version for your own private use or make it publicly available is up to you (depending on the licence terms).
3. Take the code and add the features you want and submit it back to the original project so that others can benefit from your work, if it's judged good enough and useful enough.
You seem to have opted for choice number 1. -
Filtering errors[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: May 18 2004 12:38 EDT
- in response to D S
Bitch and whine about the fact that it doesn't do what you want
Name depends on attitude. Are you trying to say that Open Source authors should accept no feature requests?and expect someone else to fix it for you for free.
Yes, I do expect. Why not? Authors know codebase way better and what might be one hour work for them will require week or more from a lazy guy like me. -
XDoclet? (Was: Filtering errors)[ Go to top ]
- Posted by: Craig Cottingham
- Posted on: May 18 2004 12:38 EDT
- in response to Konstantin Ignatyev
Such check as<suppress checks="MagicNumberCheck" files="JavadocStyleCheck.java" lines="221"/>implies that I should edit the file and edit the file again when I edit main source file. Looks like error prone and inconvenient routine. How about some source code level remarks like:// @checkstyle:ignoreNextLines n=1for( int myStupidLongNameForLoopingVariable = 0;
Could XDoclet be used to generate the suppressions file? -
XDoclet? (Was: Filtering errors)[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: May 18 2004 12:50 EDT
- in response to Craig Cottingham
Could XDoclet be used to generate the suppressions file?
Good idea. Although I think XDoclet will not serve well because it does not care about line numbers IMO, so it will require a human to take care of line numbers and their changes.
But a simple regexp based parser might work very well: algorithm might look like this: on a first pass parse all files line-by-line and search for comments like // @checkstyle:ignoreNextLines n=5, as the parser will have exact line number where such comment was discovered it may generate suppress file correctly and keep track of line number changes automatically. -
Filtering errors[ Go to top ]
- Posted by: Pavel Vlasov
- Posted on: May 18 2004 15:09 EDT
- in response to Konstantin Ignatyev
Check out Hammurapi waivers. They aren't bound to line numbers but to parse tree path. So if you have a waiver in, say, second for loop in third try block in method a() of class B you can freely modify all the rest of your code and the waiver will stay in place. If you modify that method, then waiver can become invalid. I think it is more robust way of binding to position in the source file comparing with line numbers. -
Filtering errors[ Go to top ]
- Posted by: Oliver Burn
- Posted on: May 18 2004 19:26 EDT
- in response to Konstantin Ignatyev
There was a long discussion about whether to use an embedded notation to suppress errors. Ultimately it was decided to not use this approach as:
- It stopped Java code being polluted with "noise"
- It allowed a central place where suppressions were entered - and hence monitored.
- It allowed for more powerful suppressions like, ignore all complexity errors in package a.b.c.
In practice, I use it on a large commercial project, this approach has worked well. But yeh, YMMV. -
Custom Check - re filtering results[ Go to top ]
- Posted by: Adam Judson
- Posted on: May 18 2004 14:56 EDT
- in response to Konstantin Ignatyev
Rather than filter out results, I'd suggest writing a custom check to replace the one you'd like to filter.
As you have the source of the check you'd like to change, it should be simple to copy it and modify it to scan for
// checkstyle:skip next line
and throw away the error.
I'm not sure I'd suggest going down this path though, as adding a facility to allow users to defeat the style checking system seems somewhat risky. I'd preffer to suffer through some noise in the result set. -
Thanks ;)[ Go to top ]
- Posted by: Yoav Shapira
- Posted on: May 18 2004 10:43 EDT
- in response to Oliver Burn
Kudos and thanks to the CheckStyle team. I've been using it for years now, and it's been consistently helpful. I hope the 3.4 release improves the performance of the usage checks (unused method, can-be-private, etc.). -
Theoretical basis for the metrics[ Go to top ]
- Posted by: Haagen Hasle
- Posted on: May 18 2004 10:44 EDT
- in response to Oliver Burn
Could you tell me what the theoretical basis of the metrics you compute is? NPathComplexity mentions Nejmeh (that I have never heard of), and CyclomaticComplexity sounds like McCabe, but I'm not sure.
If you can give a short description of the background of the metrics, or point me to an url with a paper describing them, I would be very thankful.
Hågen -
Theoretical basis for the metrics[ Go to top ]
- Posted by: Oliver Burn
- Posted on: May 18 2004 19:00 EDT
- in response to Haagen Hasle
A good description of metrics can be found at http://metrics.sourceforge.net/. This is the excellent plug-in for Eclipse. Search for Metrics - Meanings. -
Checkstyle 3.4 released[ Go to top ]
- Posted by: John Davies
- Posted on: May 18 2004 10:46 EDT
- in response to Oliver Burn
This should be compulsory, if you've got a coding standard, use this, it's a must!
Works a treat with Maven too.
-John- -
Is it similar to hammurapi?[ Go to top ]
- Posted by: Marcin Gryszkalis
- Posted on: May 18 2004 12:28 EDT
- in response to Oliver Burn
I tested hammurapi today and it seems to be pretty good (although seeing
these 100+ warnings per file is not really fun ;) ). Is checkstyle
something similar? Maybe somebody could post little comparision?
regards
marcin -
Checkstyle 3.4 released - Ant task bombs with Ant 1.6.[ Go to top ]
- Posted by: George Coller
- Posted on: May 18 2004 12:58 EDT
- in response to Oliver Burn
There may be incompatibility with using the checkstyle ant task and ant 1.6's new import feature.
I get aCan't find/access AST Node typecom.puppycrawl.tools.checkstyle.api.DetailAST
with a matching0: Got an exception - java.lang.ClassCastException
for every file in the source.
Using the supplied ant task.
Did some googling and saw that Maven had a similiar problem a year ago.
Guess I'll try a prior release or wait for a patch. -
Checkstyle 3.4 released - Ant task bombs with Ant 1.6. More[ Go to top ]
- Posted by: George Coller
- Posted on: May 18 2004 13:07 EDT
- in response to George Coller
Just a little more information on incompatiblity with 1.6:
Checkstyle ANT Task documentation at: http://checkstyle.sourceforge.net/anttask.html
says that the task has been tested using ANT 1.5.
Darn. We are using subant and import extensively so rolling back to 1.5 is out. Guess I will wait for the patch. -
Checkstyle 3.4 released - Ant task bombs with Ant 1.6. More[ Go to top ]
- Posted by: Oliver Burn
- Posted on: May 18 2004 18:56 EDT
- in response to George Coller
Have you actually tried it? We use Checkstyle 3.4 successfully at work with Ant 1.6.1 and IBM JDK 1.3.1. -
Ant task bombs with Ant 1.6. Fixed, thank you.[ Go to top ]
- Posted by: George Coller
- Posted on: May 19 2004 13:19 EDT
- in response to George Coller
Thank you everybody who responded to my post.
It turns out it was weblogic.jar in my classpath that was stopping checkstyle from working. After removing it, checkstyle worked great. Weblogic also uses classes from Antlr (whatever that is, must be a java parser or something similiar).
I'm happy now, was hoping it was something small on my part. -
Checkstyle 3.4 released - Ant task bombs with Ant 1.6.[ Go to top ]
- Posted by: scot mcphee
- Posted on: May 18 2004 19:46 EDT
- in response to George Coller
George, we use Checkstyle with Ant 1.6.1 and have no problems with it. -
Checkstyle 3.4 released - Ant task bombs with Ant 1.6.[ Go to top ]
- Posted by: scot mcphee
- Posted on: May 18 2004 19:52 EDT
- in response to scot mcphee
In fact we define a custom checkstyle macro with a standard set of stuff being done using the macrodef tag in a 'commons' ant build.xml and import this into our other builds, using checkstyle 3.4, ant 1.6.1 and ibm jdk 1.3.1 as oliver said and this this works great under cygwin, aix, and eclipse on NT environments.
You can see samples of the macrodef and import in action on my blog entry;
http://modular.autonomous.org/blog/2004/05/10/1084170945000.html
You will see the two example I use are clover and checkstyle. -
Checkstyle 3.4 released - Ant task bombs with Ant 1.6.[ Go to top ]
- Posted by: Daniel Grenner
- Posted on: May 19 2004 04:07 EDT
- in response to George Coller
The reason for this problem is probably due to the way the classpath is set up, and not Ant 1.6 (I had the same problem with Ant 1.5 before I found a fix).
To fix the problem make sure you do not have any old version of "antlr" in your classpath (either as antlr.jar, or bundled inside something else, which e.g. is done in weblogic.jar).
/Daniel. -
Categorizing of deviations[ Go to top ]
- Posted by: Igor Semenko
- Posted on: May 19 2004 04:20 EDT
- in response to Daniel Grenner
We've got huge code base with lots of deviations, we can't fix them all at once but we do want to keep track of different categories.
Example categories are:
- Whitespace issues
- Coding issues
- Documentation issues
- Complexity issues
- Block issues
...
As I can see possible implementations are:
1. add <property name="severity" value="XXXX"/> for each module used (checkstyle.xml), where XXXX can be "whitespace", "coding", "bug"...
2. patch SeverityLevel.java from checkstyle to accept any severity level defined in checkstyle.xml, not only "warning", "error", "ignore" and "info"
3. write/adjust .xsl file which uses custom severity levels in generated xml output to group checkstyle errors.
Any better ideas?
Thanks. -
We use it with Ant 1.6.1 as well...[ Go to top ]
- Posted by: Yoav Shapira
- Posted on: May 19 2004 09:35 EDT
- in response to Igor Semenko
... no problems, but we don't use import yet. The ANTLR on the classpath sounds like a good thing to check ;) -
How I fixed it (at least I thought I did)[ Go to top ]
- Posted by: Bing Wu
- Posted on: June 03 2004 15:56 EDT
- in response to George Coller
I had the exact same problem earlier. I ran ant from Cygwin. The script "ant" came with 1.6 release. It failed with those " Can't find/access AST Node typecom.puppycrawl.tools.checkstyle.api.DetailAST " messages.
Then I manually invoked ant: java -classpath "$ant_home/lib/ant.jar;$ant_home/lib/ant-launcher.jar" org....AntLauncher my_target
It all worked fine. Then I looked at the "ant" script that I used earlier. It was almost the same except it didn't include ant.jar in -classpath switch.
Don't know why. I have a really strange environment here: couple of ant versions plus Eclipse's own. So didn't try debug any further. Hope this helps though.
Bing