@@ -201,45 +201,45 @@ Note: each E# corresponds to the epic below.
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).
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
6. Correct function declarations
7. Semicolons after each line of code
8. Let instead of var
9. Single property single line object property declarations
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)
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.
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
12. All local and instance variables are actually used somewhere.
13. limited global variables
1. All local and instance variables are actually used somewhere.
2. 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
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
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)).
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
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.
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
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.
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
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. 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
