- 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.
File | Lines | Violation | Comments |
MyRuler.java | * | ICS-SE-Java-1 | Code is not within the package hierarchy "edu.hawaii" |
MyRuler.java | 4 | ICS-SE-Java-2 | Do not use the wild card "*" in pimport statements |
MyRuler.java | 7,8,9,* | ICS-SE-Java-6 | Made up JavaDoc statements? (@date, @course, etc...) |
MyRuler.java | 11,15 | ICS-SE-Java-6 | Supposed to be one continuous JavaDoc statement |
MyRuler.java | 15,16,17,* | ICS-SE-Java-6 | Indentation is incorrect and extra (*) in the closing comment |
MyRuler.java | 42,54 | ICS-SE-Java-6 | No JavaDoc |
MyRuler.java | 83,87,90 | ICS-SE-Eclipse-2 | Spacing is at 3 instead of 2 |
MyRuler.java | 96,97,98,* | ICS-SE-Eclipse-2 | No indentation here |
MyRuler.java | 101,102 | EJS-2 | Use curly brackets for clarity and readability |
MyRuler.java | 111,133,142,* | ICS-SE-Java-6 | Capitalize the beginning of these sentences |
MyRuler.java | 159 | EJS-9 | There is no indication of what 25 and 3 represent and why they are used |
MyRuler.java | 86,117,124 | EJS-7 | Space 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:
Post a Comment