click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Stan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CLK-671) Upgrade to Checkstyle 5.1
Date Tue, 25 May 2010 09:34:24 GMT

    [ https://issues.apache.org/jira/browse/CLK-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871067#action_12871067
] 

George Stan commented on CLK-671:
---------------------------------

> what exact checks do you have in mind to make use of, besides the actual used ones?
1. Annotations:
       http://checkstyle.sourceforge.net/config_annotation.html
    - Click is using java 5.
2. Empty Block:
      http://checkstyle.sourceforge.net/config_blocks.html#EmptyBlock
3. Headers:
      http://checkstyle.sourceforge.net/config_header.html
   - to enforce the Apache header from checkstyle, but also to ensure it's consistency.
4. Coding:
     http://checkstyle.sourceforge.net/config_coding.html
   - to use quite a few from coding (too many to enumerate them here.
5. Duplicate Code:
   http://checkstyle.sourceforge.net/config_duplicates.html

6. More from Javadoc:
   http://checkstyle.sourceforge.net/config_javadoc.html
  - not just the JavadocPackage check

The main point would be that since Click is using Checkstyle, than why not make use of it's
entire power (now it looks like it's using only a small percentage of it).

This might be a separate issue:
=========================
I'm not an expert of Checkstyle, but even this would be a fantastic improvement: http://checkstyle.sourceforge.net/extending.html
- to make some custom extended checks 
   1 - Click specific  
   2 - Click based webapp specific 
   3 -  to enforce best practices

1. These might be for the Click developers (and Click component developers) to have extra
checks not covered by Checkstyle, but to enforce  conventions: e.g. the first Control constructor
parameter is the name of the control, etc.

2. Click catches allot of problems and it's doing allot of checks at runtime, but they consume
quite a few cycles.
What if those checks would be "configurable"/ optional at runtime (so would consume no resources/cycles
at all if turned off), but instead they would be as Checkstyle based tasks, that the user
can perform at build time?
In performance intensive installations this could be a fantastic improvement.

3. This would allow to enforce some of the best practices described in click docs.

> Upgrade to Checkstyle 5.1
> -------------------------
>
>                 Key: CLK-671
>                 URL: https://issues.apache.org/jira/browse/CLK-671
>             Project: Click
>          Issue Type: Improvement
>            Reporter: George Stan
>            Assignee: Adrian A.
>
> Upgrade to Checkstyle 5.1. 
> It has quite a few fixes and also support for Java 5. Since Click is using Java 5 now
this version would be more useful.
> Checkstyle 5.1 (but 5.0 too) also contains many checks not used by Click - /build/checkstyle-checks.xml
 is using just a few of them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message