Sunday, September 14, 2008

CodeRuller Review

Objective

  • to provide you with practice in identifying violations of our Java coding and documentation standards
  • to give you a chance to look at another person"s CodeRuler implementation

Overview

I was assigned to tackle the code done by the 'lau-sanchez' group. After downloading, compiling, and running the application, I was able to test it against several of the prebuilt AI that came with the application. The Ruler was actually implemented surprisingly well, after testing it against multiple opponents, they won all their battles. The in class demonstration against the Smart Split and the Gang Up was successful as it made a come back and won the game! Even the programmer, Phillip Lau, was surprised that they won.


Dissecting the written code was somewhat of a different story. First, looking at someone else's code, you want to feel that you can pick it up and have it be at a level of consistency where you don't have to pull your hairs out to figure out what is going on. Fortunately, this code was easy to read through and follow in the aspect of: class use and structure, function calls, and strategy of this Ruler. Even the logic of each method preformed the tasks with noticeable efficiency. On the contrary, I could note that there was almost no uniformity in the JavaDoc of the different functions throughout the class. Problems vary from having extra indentation spaces, made up "@tag" names, capitalization, and extra tailing asterisks(*). Inconsistency was prevalent throughout the functions as well, there was one function with almost no indentation across for-if nested loop, while other for-loops had a three-space indentation. Many would agree that this just really reduces the readability of the code, luckily they are really easy fixes.

Below are the specifics with respect to the ICS Java coding standards and the Elements of Java Style rules.


Lines noted with an asterisk(*) represents more lines that what has been stated.
FileLinesViolationComments
MyRuler.java*ICS-SE-Java-1Code is not within the package hierarchy "edu.hawaii"
MyRuler.java4ICS-SE-Java-2Do not use the wild card "*" in pimport statements
MyRuler.java7,8,9,*ICS-SE-Java-6Made up JavaDoc statements? (@date, @course, etc...)
MyRuler.java11,15ICS-SE-Java-6Supposed to be one continuous JavaDoc statement
MyRuler.java15,16,17,*ICS-SE-Java-6Indentation is incorrect and extra (*) in the closing comment
MyRuler.java42,54ICS-SE-Java-6No JavaDoc
MyRuler.java83,87,90ICS-SE-Eclipse-2Spacing is at 3 instead of 2
MyRuler.java96,97,98,*ICS-SE-Eclipse-2No indentation here
MyRuler.java101,102EJS-2Use curly brackets for clarity and readability
MyRuler.java111,133,142,*ICS-SE-Java-6Capitalize the beginning of these sentences
MyRuler.java159EJS-9There is no indication of what 25 and 3 represent and why they are used
MyRuler.java86,117,124EJS-7Space between the close parenthesis and open curly bracket



A majority of this list could have been avoided if they took the 2 seconds to have eclipse format the code...

Conclusion

Its not always an easy task to pick up someone else's code and trace it,(no brainer). When a programmer formulates ideas and flowcharts in their brain, most of the ideas are convoluted when it translates from a thought to text on a computer screen. The coding standards/conventions have helped ease the pain over the years. After the encountering the problems and difficulties in this assignments, I feel that these constraints are imperative to the coding society, even if it takes something as stupid of a rule as "Use meaningful names." to be published in a book. Saves us a lot of time, and ultimately-- money.

No comments: