... | ... | @@ -198,48 +198,48 @@ Note: each E# corresponds to the epic below. |
|
|
### Code Inspection Criteria
|
|
|
|
|
|
|
|
|
1. Completeness(of reflection by code of requirements)
|
|
|
1. Each such method has appropriate parameters
|
|
|
2. Consistency (of layout, name choice, and code organization)
|
|
|
2. Placement of braces ({ and }) done consistently throughout.
|
|
|
3. Indentation is used, consistently, to indicate block structure within braces.
|
|
|
4. Block comments precede the code they describe.
|
|
|
5. The same names or abbreviations are used consistently for the same concept (_e.g. _not next, nextNode, and nxtn in three places in the same class).
|
|
|
3. Coding Style
|
|
|
6. Correct function declarations
|
|
|
7. Semicolons after each line of code
|
|
|
8. Let instead of var
|
|
|
9. Single property single line object property declarations
|
|
|
4. Efficient Processing (using as little processing time as is reasonable)
|
|
|
10. Loops contain complex code, or other loops, only when necessary.
|
|
|
11. Array processing (especially search) contains loop exit code to execute when the condition is found.
|
|
|
5. Efficient Storage
|
|
|
12. All local and instance variables are actually used somewhere.
|
|
|
13. limited global variables
|
|
|
6. Simplicity
|
|
|
14. No redundant code, extract to a function
|
|
|
15. Math expressions, control expressions (in ifs, whiles, fors, and switches) are as simple as possible.
|
|
|
16. Standard JS usage.
|
|
|
17. Variables declared as close as possible to where they are used
|
|
|
7. Self-Description
|
|
|
18. Comments are provided whenever the purpose or reason for doing something in the code is obscure.
|
|
|
19. Comments are provided to describe every method, however briefly.
|
|
|
20. Comments are provided to describe the purpose, restrictions, and relationships between all instance variables in a class.
|
|
|
21. All names are chosen well and consistently to reflect their usage and purpose.
|
|
|
22. Constants (static final) are used instead of magic numbers. (_e.g. _Don't write 42, write static final ULT_ANS = 42; and then use ULT_ANS instead.)
|
|
|
23. Booleans are not compared to boolean constants. (_e.g. _if (!found) is preferred to if (found == false)).
|
|
|
8. Reusability
|
|
|
24. Public methods are as general-purpose as is consistent with the design.
|
|
|
25. Public method headers do not reveal the known usage of the class by code outside the class.
|
|
|
9. Modularity
|
|
|
26. Instance variables are not public.
|
|
|
27. Variables are declared as locally as possible.
|
|
|
28. Public method headers don't reveal the internal design of the class.
|
|
|
29. System.exit is not called directly.
|
|
|
10. Extra
|
|
|
30. Generated files should not be in git repo
|
|
|
31. Old uncommented code should be removed
|
|
|
32. Coding should be done in a way to increase cohesion and decrease coupling
|
|
|
1. Completeness(of reflection by code of requirements)
|
|
|
1. Each such method has appropriate parameters
|
|
|
2. Consistency (of layout, name choice, and code organization)
|
|
|
1. Placement of braces ({ and }) done consistently throughout.
|
|
|
2. Indentation is used, consistently, to indicate block structure within braces.
|
|
|
3. Block comments precede the code they describe.
|
|
|
4. The same names or abbreviations are used consistently for the same concept (_e.g. _not next, nextNode, and nxtn in three places in the same class).
|
|
|
3. Coding Style
|
|
|
1. Correct function declarations
|
|
|
2. Semicolons after each line of code
|
|
|
3. Let instead of var
|
|
|
4. Single property single line object property declarations
|
|
|
4. Efficient Processing (using as little processing time as is reasonable)
|
|
|
1. Loops contain complex code, or other loops, only when necessary.
|
|
|
2. Array processing (especially search) contains loop exit code to execute when the condition is found.
|
|
|
5. Efficient Storage
|
|
|
1. All local and instance variables are actually used somewhere.
|
|
|
2. limited global variables
|
|
|
6. Simplicity
|
|
|
1. No redundant code, extract to a function
|
|
|
2. Math expressions, control expressions (in ifs, whiles, fors, and switches) are as simple as possible.
|
|
|
3. Standard JS usage.
|
|
|
4. Variables declared as close as possible to where they are used
|
|
|
7. Self-Description
|
|
|
1. Comments are provided whenever the purpose or reason for doing something in the code is obscure.
|
|
|
2. Comments are provided to describe every method, however briefly.
|
|
|
3. Comments are provided to describe the purpose, restrictions, and relationships between all instance variables in a class.
|
|
|
1. All names are chosen well and consistently to reflect their usage and purpose.
|
|
|
2. Constants (static final) are used instead of magic numbers. (_e.g. _Don't write 42, write static final ULT_ANS = 42; and then use ULT_ANS instead.)
|
|
|
3. Booleans are not compared to boolean constants. (_e.g. _if (!found) is preferred to if (found == false)).
|
|
|
8. Reusability
|
|
|
1. Public methods are as general-purpose as is consistent with the design.
|
|
|
2. Public method headers do not reveal the known usage of the class by code outside the class.
|
|
|
9. Modularity
|
|
|
1. Instance variables are not public.
|
|
|
2. Variables are declared as locally as possible.
|
|
|
3. Public method headers don't reveal the internal design of the class.
|
|
|
4. System.exit is not called directly.
|
|
|
10. Extra
|
|
|
1. Generated files should not be in git repo
|
|
|
2. Old uncommented code should be removed
|
|
|
3. Coding should be done in a way to increase cohesion and decrease coupling
|
|
|
|
|
|
### Project Board
|
|
|
|
... | ... | |