Checkstyle 3.4 released

Discussions

News: Checkstyle 3.4 released

Bookmark and Share Get thread feed

  1. Checkstyle 3.4 released (27 messages)

    • Posted by: Oliver Burn
    • Posted on: May 18 2004 08:53 EDT
    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! :-)
    Reply to this

    Threaded Messages (27)

  2. Checkstyle 3.4 released[ Go to top ]

    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.
    Reply to this Reply to original

  3. Filtering errors[ Go to top ]

    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
    Reply to this Reply to original

  4. Filtering errors[ Go to top ]

    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;
    Reply to this Reply to original

  5. Filtering errors[ Go to top ]

    It's an open source project. If it doesn't do what you want, feel free to write your own improved version.
    Reply to this Reply to original

  6. Filtering errors[ Go to top ]

    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.
    Reply to this Reply to original

  7. Filtering errors[ Go to top ]

    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.
    Reply to this Reply to original

  8. Filtering errors[ Go to top ]

    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.
    Reply to this Reply to original

  9. XDoclet? (Was: Filtering errors)[ Go to top ]

    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?
    Reply to this Reply to original

  10. XDoclet? (Was: Filtering errors)[ Go to top ]

    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.
    Reply to this Reply to original

  11. Filtering errors[ Go to top ]

    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.
    Reply to this Reply to original

  12. Filtering errors[ Go to top ]

    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.
    Reply to this Reply to original

  13. Custom Check - re filtering results[ Go to top ]

    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.
    Reply to this Reply to original

  14. Thanks ;)[ Go to top ]

    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.).
    Reply to this Reply to original

  15. Theoretical basis for the metrics[ Go to top ]

    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
    Reply to this Reply to original

  16. Theoretical basis for the metrics[ Go to top ]

    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.
    Reply to this Reply to original

  17. Checkstyle 3.4 released[ Go to top ]

    This should be compulsory, if you've got a coding standard, use this, it's a must!

    Works a treat with Maven too.

    -John-
    Reply to this Reply to original

  18. Is it similar to hammurapi?[ Go to top ]

    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
    Reply to this Reply to original

  19. Checkstyle 3.4 released - Ant task bombs with Ant 1.6.[ Go to top ]

    There may be incompatibility with using the checkstyle ant task and ant 1.6's new import feature.

    I get a
    Can't find/access AST Node typecom.puppycrawl.tools.checkstyle.api.DetailAST
    with a matching
    0: 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.
    Reply to this Reply to original

  20. Checkstyle 3.4 released - Ant task bombs with Ant 1.6. More[ Go to top ]

    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.
    Reply to this Reply to original

  21. Checkstyle 3.4 released - Ant task bombs with Ant 1.6. More[ Go to top ]

    Have you actually tried it? We use Checkstyle 3.4 successfully at work with Ant 1.6.1 and IBM JDK 1.3.1.
    Reply to this Reply to original

  22. Ant task bombs with Ant 1.6. Fixed, thank you.[ Go to top ]

    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.
    Reply to this Reply to original

  23. Checkstyle 3.4 released - Ant task bombs with Ant 1.6.[ Go to top ]

    George, we use Checkstyle with Ant 1.6.1 and have no problems with it.
    Reply to this Reply to original

  24. Checkstyle 3.4 released - Ant task bombs with Ant 1.6.[ Go to top ]

    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.
    Reply to this Reply to original

  25. Checkstyle 3.4 released - Ant task bombs with Ant 1.6.[ Go to top ]

    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.
    Reply to this Reply to original

  26. Categorizing of deviations[ Go to top ]

    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.
    Reply to this Reply to original

  27. We use it with Ant 1.6.1 as well...[ Go to top ]

    ... no problems, but we don't use import yet. The ANTLR on the classpath sounds like a good thing to check ;)
    Reply to this Reply to original

  28. How I fixed it (at least I thought I did)[ Go to top ]

    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
    Reply to this Reply to original