Code Ruler Review

Today's assignment is Code Ruler Review. I'm reviewing the code of Shaoxuan Zhang.

---

Overall Impressions

A little dense in places, but generally well written. The strategy was clear and sensibly implemented.

I noticed that English does not seem to be Shaoxuan's first language. I had no problem understanding the comments, but the type of grammar tweaking that the rules insist on seemed rather pointless. I think maybe those rules should be relaxed in this case (but I listed them anyway).

The number of things to fix was surprisingly low, considering it was written before we got the rules.

Standards Check

Entries in the "Lines" column refer to the MyRuler.java file.

Lines	Rule	Rule Description
	ICS-SE-Java-0	Follow EJS standards.
1	ICS-SE-Java-1	All code is within the package hierarchy "edu.hawaii".
1	ICS-SE-Java-2	Do not use the wildcard "*" in import statements.
	ICS-SE-Java-3	Only one Java statement per line.
	ICS-SE-Java-4	Do not include // comments at the top of the file.
	ICS-SE-Java-5	Rewrite default Eclipse template JavaDocs to be useful.
	ICS-SE-Java-6	Format JavaDoc summary lines correctly
	ICS-SE-Java-7	Do not use Vector and Hashtable classes.
	ICS-SE-Java-8	Do not use "raw" Collections classes
	ICS-SE-Java-9	Prefer the for-each control structure to the for control structure.
	ICS-SE-Java-10	Use the @Override annotation when overriding equals() and hashCode
	ICS-SE-Eclipse-1	Use Eclipse Europa 3.3
*	ICS-SE-Eclipse-2	Import and use the Eclipse Java Code formatting template.
	ICS-SE-Eclipse-3	Configure Text Editor.
	EJS-1	Adhere to the style of the original.
	EJS-2	Adhere to the Principle of Least Astonishment.
	EJS-3	Do it right the first time.
	EJS-4	Document any deviations.
	EJS-5	Indent nested code.
	EJS-6	Break up long lines.
	EJS-7	Include whitespace
22,23,24,*	EJS-8	Do not use "hard" tabs
	EJS-9	Use meaningful names.
	EJS-10	Use familiar names.
	EJS-11	Question excessively long names.
	EJS-12	Join the vowel generation.
	EJS-13	Capitalize only the first letter in acronyms.
	EJS-14	Do not use names that differ only in case.
	EJS-15	Use the reversed, lowercase name of your organization's Internet domain name as the root qualifier for your package names.
	EJS-16	Use a single, lowercase word as the root name of each package.
	EJS-17	NOT USED
	EJS-18	Capitalize the first letter of each word that appears in a class or interface name.
	EJS-19	Use nouns when naming classes.
	EJS-20	Pluralize the names of classes that group related attributes, static services or constants.
	EJS-21	Use nouns or adjectives when naming interfaces.
	EJS-22	Use lowercase for the first word and capitalize only the first letter of each subsequent word that appears in a method name.
157	EJS-23	Use verbs when naming methods.
	EJS-24	Follow the JavaBeans™ conventions for naming property and accessor methods.
	EJS-25	Use lowercase for the first word and capitalize only the first letter of each subsequent word that appears in a variable name.
	EJS-26	Use nouns to name fields.
	EJS-27	Pluralize the names of collection references.
	EJS-28	Establish and use a set of names for trivial "throwaway" variables.
92,96,100,*	EJS-29	Qualify field names with "this" to distinguish them from local variables.
	EJS-30	When a constructor or "set" assigns a parameter to a field, give that parameter the same name as the field.
	EJS-31	Use uppercase letters for each word and separate each pair of words with an underscore when naming constants.
	EJS-32	Write documentation for those who must use your code and those who must maintain it.
	EJS-33	Keep comments and code in sync.
12	EJS-34	Use the active voice and omit needless words.
22,28	EJS-35	Use documentation comments to describe the programming interface.
	EJS-36	Use standard comments to hide code without removing it.
32,36,40,*	EJS-37	Use one-line comments to explain implementation details.
	EJS-38	Describe the programming interface before you write the code.
91	EJS-39	Document public, protected, package, and private members.
	EJS-40	Provide a summary description and overview for each package.
	EJS-41	Provide a summary description and overview for each application or group of packages.
	EJS-42	Use a single consistent format and organization for all documentation comments.
	EJS-43	NOT USED
	EJS-44	Wrap code with <pre>...</pre> tags.
	EJS-45	Consider marking the first occurrence of an identifier with a {@link} tag.
	EJS-46	Establish and use a fixed ordering for Javadoc tags.
125,150,198,*	EJS-47	Write in the third-person narrative form.
8,124,149	EJS-48	Write summary descriptions that stand alone.
124,149	EJS-49	Omit the subject in summary descriptions of actions or services.
8	EJS-50	Omit the subject and the verb in summary descriptions of things.
10,152	EJS-51	Use "this" rather than "the" when referring to instances of the current class.
	EJS-52	Do not add parentheses to a method or constructor name unless you want to specify a particular signature.
	EJS-53	Provide a summary description for each class, interface, field and method.
91	EJS-54	Fully describe the signature of each method.
	EJS-55	Include examples.
	EJS-56	Document preconditions, postconditions, and invariant conditions.
	EJS-57	Document known defects and deficiencies.
	EJS-58	Document synchronization semantics.
	EJS-59	Add internal comments only if they will aid others in understanding your code.
	EJS-60	Describe why the code is doing what it does, not what the code is doing.
172,187,205,*	EJS-61	Avoid the use of end-line comments.
	EJS-62	Explain local variable creations with an end-line comment.
	EJS-63	Establish and use a set of keywords to flag unresolved issues.
	EJS-64	Label closing braces in highly nested control structures.
	EJS-65	Add a "fall-through" comment between two case labels, if no break statement separates those labels.
	EJS-66	Label empty statements.
	EJS-67	Consider declaring classes representing fundamental data types as final.
	EJS-68	Build concrete types from native types and other concrete types.
	EJS-69	Define small classes and methods.
	EJS-70	Define subclasses so they may be used anywhere there superclass may be used.
55,59,63,*	EJS-71	Make all fields private.
	EJS-72	Use polymorphism instead of instanceof.
	EJS-73	NOT USED?
	EJS-74	NOT USED
	EJS-75	Replace nontrivial expressions with equivalent methods.
105,109,132,*	EJS-76	Use block statements instead of expression statements in control flow constructs.
	EJS-77	Clarify the order of operations with parentheses.
	EJS-78	Always code a break statement in the last case of a switch statements.
	EJS-79	Use equals(), not ==, to test for equality of objects.
	EJS-80	Always construct objects in a valid state.
	EJS-81	Do not call nonfinal methods from within a constructor.
	EJS-82	Use nested constructors to eliminate redundant code.
	EJS-83	Use unchecked, run-time errors to report serious unexpected errors that may indicate an error in the program's logic.
	EJS-84	Use checked exceptions to report errors that may occur, however rarely, under normal program operation.
	EJS-85	Use return codes to report expected state changes.
	EJS-86	Only convert exceptions to add information.
	EJS-87	Do not silently absorb a run-time error exception.
	EJS-88	Use a finally block to release resources.
	EJS-89	Program by contract.
	EJS-90	NOT USED
	EJS-91	Use assertions to catch logic errors in your code.
	EJS-92	Use assertions to test pre- and post-conditions of a method.
	EJS-93	Use threads only where appropriate.
	EJS-94	Avoid synchronization.
	EJS-95	Use synchronized wrappers to provide synchronized interfaces.
	EJS-96	Do not synchronize an entire method if the method contains significant operations that do not need to be synchronized.
	EJS-97	Avoid unnecessary synchronization when reading or writing instance variables.
	EJS-98	Consider using notify() instead of notifyAll().
	EJS-99	Use the double-check pattern for synchronized initialization.
	EJS-100	Use lazy initialization.
	EJS-101	Avoid creating unnecessary objects.
	EJS-102	Reinitialize and reuse objects to avoid new object construction.
	EJS-103	Leave optimization for last.
	EJS-104	Place types that are commonly used, changed, and released together, or mutually dependent on each other into the same package.
	EJS-105	Isolate volatile classes and interfaces in a separates packages.
	EJS-106	Avoid making packages that are difficult to change dependent on packages that are easy to change.
	EJS-107	Maximize abstraction to maximize stability.
	EJS-108	Capture high-level design and architecture as stable abstractions organized into stable packages.