Here is a list of abbreviations I will use in the code reviews I write in order to reduce the amount of typing I have to do:
| Code | Meaning |
| ATH | Actual Type Hidden: this private variable is declared with one type (e.g., List), but it is always assigned a specific subclass (e.g., ArrayList). For a private variable, this is a bad idea because it obscures the actual type of the variable. Presumably you chose the particular subclass for a reason, and the implementation might be able to take advantage of features of the subclass. Hiding the subclass might possibly make sense for a public variable (though I'm not sure it adds much value even then). |
| CCN | Code Comments Needed: it would be helpful to have a few short comments in here describing at a high level what each major block of code does (e.g., "Process headers in the HTTP request"). |
| CDC | Comment Duplicates Code: most or all of the information in the comment is obvious from the code that follows. One example is method/class documentation consisting exclusively of words that form part of the method or class name. |
| DBE | Documentation Belongs Elsewhere: for example, class-level documentation describes constructor parameters. |
| DM | Documentation Missing: need a precise description of this variable/parameter/method/return value. |
| DOOD | Documentation Out Of Date: this documentation doesn't appear to be correct: is it stale? |
| DPD | Duplicates Parameter Documentation: this material should be described in the documentation for individual parameters, not here. |
| DTV | Documentation Too Vague: this documentation isn't precise enough for me to get a good understanding of what it describes. |
| IIC | Interface-Implementation Confusion: this documentation should describe only the interface, but it also contains implementation details. |
| IL | Information Leakage: this code has knowledge of things it shouldn't need to know about, or its behavior is in some way dependent on some other code that really shouldn't depend on. |
| MCE | Must Check for Errors: errors or exceptional conditions can happen here, but you don't have any code to handle such occurrences. |
| MYS | Mysterious code. It's unclear what higher-level purpose this code is intended to carry out, or why it is needed. A short comment might solve this problem, but perhaps the real problem is that the code is too tricky. |
| NCD | Need Class Documentation: (almost?) every class should have overall documentation describing its purpose, key information that it hides, etc. |
| NEI | Not Enough Information: error message should include more specific info about what went wrong and what operation was being performed at the time. |
| NTG | Name Too Generic: this variable or method name is so vanilla that it doesn't convey much useful information. If someone saw this name in the absence of any other information, would they have some sense of what it represents? See if you can make the name more specific. |
| PDH | Parameter Documentation in Header: part of all of the documentation related to a parameter is in the header comment for the method, rather than in the @param section for that parameter. Concentrate all the parameter documentation in the @param section, so readers only have to look in one place. |
| RCP | Repeated Code Pattern: code very similar to the lines above gets repeated in many different places. Find a way to simplify this (e.g., define a higher-level API that hides the details, or find a more central place to do the actions so that this code is not needed here). |
| TC | Thin Class: this class doesn't provide much functionality and doesn't appear to hide a significant amount of information. Is it even worth having? |
| TM | Thin Method: this private method does almost nothing. Wouldn't it be simpler to copy its body inline rather than calling the method (especially if the method is only invoked once)? |
| TMLI | Too Many Levels of Indentation: deeply indented code
is hard to read. In most cases, code can be restructured to reduce the nesting
level. For example, instead of this:
for (...) {
if (A) {
if (B) {
if (C) {
do stuff...
}
}
}
}for (...) {
if (!A) {
continue;
}
if (!B) {
continue;
}
if (!C) {
continue;
}
do stuff...
} |
| UCB | Unexpected Code Behavior: this code doesn't behave in the normal way people would usually expect. One example is using toString to generate JSON. |