Based on the previous article, we will continue to analyze the comments of openwnn.
1. Comment for Annotation
Severity: Medium
Annotations are used to rewrite the name of a method or variable. This kind of work is a waste of time and does not need to be spent.
/**Current key-Mode*/Protected IntMcurrentkeymode;
This situation is particularly common in openwnn.
2. Comment
Severity: low
You can write comments in a short time, but you need to write long comments. The result is not helpful to your understanding because of the write length.
This is rare in openwnn.
3. Step by step comments
Severity: Medium
In this caseCodeSpacing, making the Code no longer smooth.
This is also rare in openwnn.
4. Missing comments
Severity: heavy
Not all codes need annotations, and not all classes need annotations. We advocate that the Code should be self-expressed and should not be annotated, however, if you do not write comments for hard-to-understand content, it is undoubtedly a challenge for readers (including the author himself a few months later.
The data storage method of the composing class and the relationship between the cursor and the composing in edittext are also hard to understand from tracking data without corresponding design orders. This type of data storage method should be annotated, but not annotated. That is why it is hard to understand some of them.Algorithm.
5. Incorrect comments
Severity: heavy
The content of the comment itself is incorrect, misleading the reader. Such annotations are not as good as none. Of course, the effects vary depending on the degree of content errors.
/**Thread for updating the candidates view*/Private VoidUpdateprediction (){
This code is not processed by any separate thread.
6. Improper javadoc comments
KanaconverterThe copyright statement in the class annotation is a redundant javadoc annotation.