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:

  • 0. Keep Your Main Method Small
    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

    0. 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. This is one of the main learning goals in CS 174

    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

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

    Problematic 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.

    Problematic 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.

    Problematic 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

    Problematic 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:

    Problematic Code

    Good Code

    Example 2:

    Problematic 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

    Problematic 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.

    Problematic 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.

    Problematic Code

    Good Code


    15. Capitalizing Final Variables

    All final variables must be in all caps.

    Problematic 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

    Problematic 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.

    Problematic 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.

    Problematic 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.

    Problematic Code

    Good Code