> what exact checks do you have in mind to make use of, besides the actual used ones?
6. More from Javadoc:
- 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.