| The primary reason developers should write clean code is so that it can be read and understood easily. If the code is readable, the next person working on the code, including the original author at a later date, will be more efficient. This principle is similar to a well thought-out plan improving the result in all endeavors. When the code is clean, it acts as a mini-plan, illustrating the logic to an algorithm. If you can't simply read down the page without getting lost, the code is considered "dirty." In rare cases, dirty and clumsy code might work, but poorly styled code is most often a sign of poorly designed code, the bane of a developer shop.  | Whatever style and convention you choose, just be consistent. Don't change from class to class. |
Good style itself doesn't actually affect application performance directly. You can strip code of extra whitespace, and it will recompile fine and run at the same speed as before. In fact, it will compile faster (but not run faster). However, while having a standard filing system makes dealing with paperwork more efficient, using a standard style makes it easier to work with your code. Therefore, you should strive to use a standard style for your application code. The following short checklist helps ensure that your project submission looks clean and professional: -
Use one statement per line. -
Align related program parts . -
Be consistent with indenting and braces. -
Use enough vertical and horizontal whitespace. -
Don't use the tab character; use spaces instead. -
Comment empty body sections to avoid confusion. -
Use braces even when an if , for , or while loop has just one statement. -
Comments should have the same indenting as code. -
Comments should be spell checked. -
Eliminate obvious comments. -
Use one class per file (inner classes are okay). -
Use one exit from loops and methods . -
Don't repeat code; use a method instead. -
Avoid OS-dependent code, such as path delimiters and absolute paths (use relative paths). -
Don't use identifiers longer than 20 characters . -
Spell out the words in names ; do not use abbreviations. -
Use names different enough from one another to avoid confusion. -
Don't differ names by letter case alone. -
Use meaningful names, except for loop increments , for which single-letter names such as i or j are acceptable. -
The names of all instance methods and fields start with a lowercase letter, and subsequent words within the method or field name are capitalized. -
Capitalize class names. -
Package names must be all lowercase letters . -
Boolean method names should begin with is . -
Use nouns when naming classes and variables . -
Use verb phrases for methods. -
Restrict the visibility of variables and other identifiers. -
Use constants (final) instead of variables whenever possible. -
Use meaningful default values. -
Use getXXX() and setXXX() methods for getting/setting field values.  | Use the same style you'll find in the classes Sun supplies with the assignment download. |
|
