CS 173 Style Guide

As we've discussed an experienced, it's possible to write code that works, but which is completely unreadable and difficult to debug as a result. Furthermore, we want to get you into the habit of writing good code that is easy for others to read and which is hence easier to maintain. In practice, if people can't read your code, they'll just do it over from scratch their own way. It would be a shame for all of your hard work to go to waste!

Below are some rules to help keep you on the rails as you design (they have been adapted from Professor Schilling). On many assignments, 10% of the grade will depend on adhering to these rules

All rules:

  1. Indentation/Brackets
  2. Naming Conventions
  3. Documentation: Overview
  4. Documentation: Inline Code
  5. Documentation: Methods
  6. Appropriate Loop Choices
  7. Exiting Appropriately
  8. The Break Command
  9. The GOTO Command
  10. Positive Boolean Variable Names
  11. Boolean Variable Comparisons
  12. Breaking Up Long Boolean Statements
  13. Robustness
  14. No Magic Numbers!
  15. Capitalizing Final Variables
  16. Methods Returning At The End
  17. Efficiently Written Code
  18. Avoid Compound Method Calls
  19. Text Input Prompts
  20. Variable Scoping

1. Indentation / Brackets

All code must follow proper indentation and bracket conventions. This includes, but is not limited to, conditionals, loops, and methods. Brackets should be at the end of each if statement, even if the body contains only one line. You should get into the habit of setting up your brackets and tabbing when you first complete a method, loop, or conditional statement, but before you type anything in it. If you go completely off the rails, Netbeans can save you if you click Source->Format

Bad Code

First of all, this code is missing brackets around the if statement. This makes it easy to have a bug if you decide to add the line, because only the first line is considered to be in the body of the if statement. Second of all, the tabbing is all over the place. This makes it easy to miss a closing brace somewhere, which can be very difficult to resolve for multiply nested blocks.

Good Code

Here's a better version of the above example, in which brackets are applied and aligned properly

2. Naming Conventions

  • Variable and method names should be in camel case; that is, the first letter should be in lower case, and each new word should be capitalized, with no spaces or underscores in between the words.
  • Variables and methods should be descriptive of what the variable holds.
  • For loop counters should be something short such as i, j, or k. You may also use a descriptive, but still short, name for a for loop counter such as row or col

  • Method names should start with a verb (this includes boolean methods that start with the verb "is").

Bad Code

The names of the variables are not descriptive, and the method is not written as a verb or in camel case.

Good Code

The method is now a verb that describes what it does, and its name and all variables are written in camel case (assuming "halfstep" is one word) and in descriptive language.

3. Documentation: Overview

All files must have comments near the top of the main program’s file containing the following information: Author’s name, Assignment name, Date, Class, Short description of the project. For complete information on writing Java documentation, visit this link or this link. As an example, here's a comment at the top of a file

4. Documentation: Inline code

All variables (except for loop counters) must be documented. Do not state the obvious. This clutters up your code and does not convey any information to the reader.

Bad Code

Good Code

5. Documentation: Methods

All methods will have documentation including, but not limited to:

  1. Method summary
  2. Parameter descriptions
  3. Return value descriptions
These comments should appear above the method name in a particular format, which makes it easy to automatically generate web pages describing the code (for instance, see documentation for the audio code we've been using, which was generated this way). In NetBeans, if you type out the definition of the method and then type /** followed by ENTER, it will automatically generate a correctly formatted comment, which you can fill in with details. Below is an example (courtesy of Professor Schilling) of what it should look like:

6. Appropriate Loop Choices

Code will be graded on appropriate loop choice. Using a while where a for loop is more appropriate will result in a deduction. You should use a do while loop where appropriate. Breaking out of a loop for any condition aside from the loop control will result in a deduction.

Bad Code

Since the loop below starts at 0 and stops at 9, a for loop is much more appropriate. Furthermore, the code uses a break statement, which can be confusing.

Good Code

Bad Code

Since the loop below starts at 0 and stops at 9, a for loop is much more appropriate. Furthermore, the code uses a break statement, which can be confusing.

As another example, the code below would be better stylistically in a do while loop

Good Code

7. Exiting Appropriately

Ending the program anywhere except for the last line of the main will result in a deduction. (In other words, no exit(0) in the middle of your code)

8. The Break Command

The break command should only appear in a switch statement, and not in a loop.

9. The GOTO Command

Do not use goto anywhere in your code! It is an artifact from older programming languages and leads to spaghetti code.

10. Positive Boolean Variable Names

To avoid confusion, boolean variable names should convey the positive case. In other words isReady, isValid, isProperTime are good Boolean variable names. Some not so good names are readyCheck, notValid, checkTime.

11. Boolean Variable Comparisons

Conditional checks must not compare booleans to true or false

Example 1:

Bad Code

Good Code

Example 2:

Bad Code

Good Code

12. Breaking Up Long Boolean Statements

Long conditionals should not appear as while or if conditions. Use a boolean variables for readability and self-documentation

Bad Code

Good Code

13. Robustness

All input must be checked. Bad input must be handled gracefully; code must not crash on any inputs. Bad input must not be handled silently. If the user gives bad input, they must be notified and given a choice to re-enter or quit the program.

Bad Code

Good Code

14. No Magic Numbers!

A "magic number" is a number in the program that should be defined as a final constant, especially if it's used more than once, since the programmer only has to update it in one place to change all instances.

Bad Code

Good Code

15. Capitalizing Final Variables

All final variables must be in all caps.

Bad Code

public static final int secondsInDay = 24*3600;

Good Code

public static final int SECONDS_IN_DAY = 24*3600;

16. Methods Returning At The End

Methods may only return at the end of the method, not in the middle

Bad Code

Good Code

17. Efficiently Written Code

Code must be efficient as possible without sacrificing readability. This includes, but is not limited to chaining your if statements, using the least amount of variable declarations as possible, and using the smallest data type necessary. For instance, if the user is to answer 1,2,3,4 as a response, use an int, not a double.

18. Avoid Compound Method calls

Compounding methods and parameters makes your code difficult to read and debug, so split up method calls using variables when appropriate.

Bad Code

Good Code

19. Text Input Prompts

Prompts must be meaningful and input must appear on the same line as the prompt. There must be a space between the prompt and the input the user gives.

Bad Code

Good Code

20. Variable Scoping

All variable declarations must be within the scope of a method unless the professor gives permission to put a variable within the class scope.

Bad Code

Good Code