Home
Resources
Grading
Weekly Schedule
Syllabus
Homework
Exams

Bulletin Board
Staff

Coding Convensions

Why are Coding Conventions Important?

• 80% of the lifetime cost of a piece of software goes to maintenance.
• Hardly any software is maintained for its whole life by the original author.
• Coding conventions make code easier to read, debug, and modify (both for the author and for others).
• If you you ship code as a product, it should be clean and "well engineered".

Coding Style Guidelines

• Avoid "The Blob".
  "The Blob" is what happens when a lot of complex code is put into one class, potentially all within one method. If code is complex, break up it up into several classes and/or methods.
• Use comments.
  Put a comment above every class and non-trivial method. Ideally, javadoc comments (beginning with /** and ending with */) should be used for all classes, methods, and variables that are not private.
• Use the DRY principle: Don't Repeat Yourself.
  If you find yourself writing the same or similar code two or more times, consider whether it could be put into a separate method.
• Organize variables and methods within a class as recommended by Sun:
  First static variables, then dynamic/instance variables, then constructors, then methods grouped by functionality.
• Make methods short, preferably fitting on a screen/page.

• If there is a "primary" method, make it "short & sweet".
  For example, the main method in a simulation should only be a few lines long - a few initialization steps, a loop with some method calls, and some method calls to wrap things up.
• Indent properly and keep the length of all lines <= 80 characters
  Any statements contained within another statement should be indented. Indentation should consist of 2-4 spaces (3 or 4 is usually best), and should be consistent throughout.

  The line length should not exceed 80 characters; other developers may find your code annoying to work with if it does.

Be aware that if an editor other than DrJava is used, using tabs may be problematic. An editor (e.g. NotePad) may replace tabs with 8 spaces. If a tab is replaced with more than 4 spaces your code may be hard to read and difficult for another developer to work with. Check your editor/IDE to see if tab behavior is a configurable option.

• Give classes names that are capitalized nouns
  For multiword names, each new word should be capitalized. Examples: Counter, Ticket, DormRoom .
• Give variables names that are nouns.
  The first noun should begin with a lowercase letter; for multiword names, each new word should be capitalized. Examples: limit, totalCost, firstName.
• Give methods names that are verbs.
  The first word should begin with a lowercase letter. For multiword names, each new word should be capitalized. Examples: display(...), computeTotal(...).
• Give constants (variables marked as final) names that are fully capitalized, with underscores between multiple words.
  Examples: PI, MAXIMUM_SIZE.
• Use meaningful names.
  (Exception: temporary variables such as integer counters are often named i, j, and k.)
• Do not use abbreviations. (Exception: common abbreviations, such as max, min, temp.)
• Choose a style for curly braces and stick to it within a source file/package.
  The two most common ways of using curly braces are:

  	if (x == y) {
  	   statements
  	}
   
   	if (x == y)
  	{
  	   statements
  	}
  	

  Although either style is acceptable, the first is used by the professors of this course and the textbook, and is recommended by Sun in their Coding Conventions document (see below).
• Other style rules may be mentioned throughout the course.

"Official" Java Coding Conventions from Sun

• Java Coding Conventions

Acknowledgments: This file is a modified version of Coding Syle Guidelines from UPenn's CSE1xxx course.