| 176 | | * code |
| 177 | | * The code style is correct to our convention. |
| 178 | | * The code is easily readable. |
| 179 | | * There are no fake !JavaDocs (!JavaDocs without useful information). |
| 180 | | * The java-doc is complete enough. |
| 181 | | * For each element, the !JavaDoc should describe clearly what is it (if this is not easy, then probably the design is bad) |
| 182 | | * It causes 0 errors. |
| 183 | | * It causes 0 warnings. |
| 184 | | * The @!SuppressWarnings annotation is used only if really needed: |
| 185 | | * unused, when something is used only by reflection |
| 186 | | * synthetic-access, when you want to touch something internal with inner class (although in many cases this may be avoided) |
| 187 | | * unchecked, when you are doing something complex with generic (note that this is also avoidable in many cases) |
| 188 | | * No inaccurate, or unclear XXX and TODO tags |
| 189 | | * It should not break other code (ensured by their tests). |
| 190 | | * There some bad code examples here - [wiki:CODE_SMELLS] |
| 191 | | |
| 192 | | |
| 193 | | * design |
| 194 | | * It is documented |
| 195 | | * (not only in the code). |
| 196 | | * It is simple and understandable. |
| 197 | | * It is easy to use. |
| 198 | | * (using it requires less work / small code) |
| 199 | | * It is error proof (hard to use it in a wrong way) |
| 200 | | * The compiler prevents most errors. |
| 201 | | * (it is better to have an abstract getKind() instead of forcing implementors to call setKind at construction) |
| 202 | | * (final may also help) |
| 203 | | * Most of other errors cause an exception |
| 204 | | * (defensive programming helps here) |
| 205 | | * When a library is used, it is used correctly. |
| 206 | | * There are no representation exposures. |
| 207 | | * There are no GOD (very long) methods. |
| 208 | | * There are no GOD (very long) classes. |
| 209 | | * The coupling is low. |
| 210 | | * No magic numbers (and strings) |
| 211 | | * No array members. |
| 212 | | * (unless there is really a reason) |
| 213 | | * No public instance fields. |
| 214 | | * No public non final fields |
| 215 | | * It has high cohesion. |
| 216 | | * (see http://en.wikipedia.org/wiki/Cohesion_(computer_science) ) |
| 217 | | * It has low coupling. |
| 218 | | * (see http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 ) |
| 219 | | * It is possible to state in one sentence what every class or member is/does. |
| 220 | | * Classes and members are named correctly. |
| 221 | | * Every class (or attribute) is self responsible and self complete. |
| 222 | | * No code duplication (copy paste). |
| 223 | | * It is easily testable. |
| 224 | | * (when not, testing helpers are provided to make it such). |
| 225 | | * No other kind of smells. |
| 226 | | * It has good package structure. |
| 227 | | * It is logging correctly. |
| 228 | | * It has adequate error handling. |
| 229 | | * No premature optimization. |
| 230 | | * No premature abstraction. |
| 231 | | |
| 232 | | * tests |
| 233 | | * It has automatic use case tests, before implementing. |
| 234 | | * (they are very good to demonstrate the design for a library) |
| 235 | | * If it has demos, the demos are actually tests with main method. |
| 236 | | * (demos should be done at design time!) |
| 237 | | * It has enough unit tests to ensure its correctness |
| 238 | | * (listed at design time, passing at implementation time) |
| 239 | | * It has enough integration tests |
| 240 | | * (listed at design time, passing at implementation time) |
| 241 | | * It has enough system tests |
| 242 | | * (listed at design time, passing at implementation time) |
| 243 | | * It has written scenarios for manual testing |
| 244 | | * (when it is an external feature or a bug) |
| 245 | | * The tests had code coverage |
| 246 | | * (good code coverage does not mean good tests, but bad code coverage means bad tests) |
| 247 | | |
