TestClass.java
package test;
public class TestClass {
/**
* Description.
*
* @param p2
* Parameter 2 desc.
* @param p1
* Parameter 1 desc.
* @param <T>
* Parameter T desc.
* @param p3
* Parameter 3 desc.
*/
public <T> void test(String p1, String p2, T p3) {
}
}
config.xml
<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
"-//Puppy Crawl//DTD Check Configuration 1.3//EN"
"http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
<module name="Checker">
<property name="charset" value="ASCII" />
<property name="severity" value="error" />
<property name="fileExtensions" value="java" />
<module name="TreeWalker">
<module name="JavadocMethod">
<property name="scope" value="public" />
<property name="allowedAnnotations" value="Override" />
</module>
</module>
</module>
output from: java -jar checkstyle-6.14.1-all.jar -c config.xml TestClass.java
Starting audit...
Audit done.
To add less confusion between the javadoc order and the method when reading, I would like the at parameters to be validated in the javadoc so they both agree in terms of order. This will give new readers less headaches as they try to read and understand the method and what it's parameters mean.
With this new feature, I am expecting the javadocs for parameters 1 and T to produce errors that they are out of order in my example. If 2 and/or 3 produce errors that is fine, but I expect the main ones that go backwards in the list to definitely be there.
The preferred order, imo, should be T, 1, 2, 3 like they are defined in the method definition.
TestClass.java
config.xml
output from:
java -jar checkstyle-6.14.1-all.jar -c config.xml TestClass.javaTo add less confusion between the javadoc order and the method when reading, I would like the at parameters to be validated in the javadoc so they both agree in terms of order. This will give new readers less headaches as they try to read and understand the method and what it's parameters mean.
With this new feature, I am expecting the javadocs for parameters 1 and T to produce errors that they are out of order in my example. If 2 and/or 3 produce errors that is fine, but I expect the main ones that go backwards in the list to definitely be there.
The preferred order, imo, should be T, 1, 2, 3 like they are defined in the method definition.