CS 173/174 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, a portion of the grade will depend on adhering to these rules

NOTE: Most of the examples below are in Java, but they apply similarly to C++.

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

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.

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").

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

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.

5. Documentation: Methods

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

1. Method summary
2. Parameter descriptions
3. Return value descriptions

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.

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.

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

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:

Example 2:

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

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.

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.

15. Capitalizing Final Variables

All final variables must be in all caps.

16. Methods Returning At The End

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

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.

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.

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.

21. Keep Your Main Method Small

The main method should be kept as a staging area for other code (e.g. startup, input, run, exit), and you should encapsulate any code not related to this in methods and classes. As a rule of thumb, the length of your main should be minimized.