[
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.
