Skip to content

Course Coding Standards

This document consists of the java coding standards for the course. All project files must fully comply with these standards to be accepted for grading.

File Length

  • Java files of more than 2,000 lines of code should be avoided. Use more classes and files to split up long files.

Java Source Files

  • All Java source code files must have this general order. The details of each section are specified later in this document.
  • Package statement
  • Import statements
  • Class and Interface declarations

Package Statements

  • The first non-comment line of java source files is a package statement.

package java112.analyzer;

Import Statements

  • After the package statement comes all import statements.
import java.io.*;
import java.util.*;

Class and Interface Declarations

  • Class or Interface parts should appear in this order.
    1. Class or Interface javadoc comment
    2. The keyword public followed by the class or interface statement, including the name of the class or interface.
    3. Constants.
    4. Class (static) variables.
    5. Instance variables that are protected.
    6. Instance variables that are private.
    7. The empty class constructor.
    8. All other class constructors.
    9. Methods.

Indentation

  • Four space characters (not a tab character) should be used for indentation of nested code. Projects will not be accepted if any of your java source code files contain tab characters.
  • Most text editors allow you to set your editor such that a tab is 4 spaces. For example, in Atom: Edit >> Preferences >> Editor, 1) Check "Soft Tabs" 2) “Tab Length to 4. This is an acceptable practice.

Line Length

  • All lines of java must be 80 characters or less if at all possible. This is possible almost all the time.
  • All lines of javadoc or other comments must be 70 characters or less.

Line Wrapping

  • When a line of code needs to span more than one line, you should use these general principles:
    • Break after a comma.
    • Break before an operator.
    • Use higher-level breaks over lower-level breaks.
    • Indent all continuation lines by 8 spaces or more for clarity. Making the java statement clear is the goal.
  • Examples:
// Correct java code continuation
    function(longExpression1, longExpression2, longExpression3, 
             longExpression4, longExpression5);

    longName1 = longName2 * (longName3 + longName4 - longName5) 
                + 4 * longname6;


    //INDENT 8 SPACES TO AVOID VERY DEEP INDENTS 
    private static synchronized extremelyLongMethodName(int anArg, 
            Object anotherArg, String yetAnotherArg, 
            Object andStillAnother) { 
        ... 
    } 


    if ((condition1 && condition2) 
            || (condition3 && condition4) 
            ||!(condition5 && condition6)) { 
        doSomethingAboutIt(); 
    }

Comments in Java Source Code

  • Good javadoc comments are required before all:
    • class statements
    • interface statements
    • methods

Variable Declarations

  • All variables and constants must be declared on their own line.
  • Here is the required order for variables and constants.
    1. Constants
    2. Class variables
    3. Instance variables
  • All local variable must be declared at the top of a method.
  • Do not declare a local variable with the same name as a class or instance variable.
  • Local variables must be initialized when they are declared.

Compound Statements

  • Compound statements should look like the following examples. The left curly brace ({) should always be at the end of the beginning line of the statement.
// Compound statement examples

    // if statements
    if (condition) { 
        statements; 
    }

    if (condition) { 
        statements; 
    } else { 
        statements; 
    }

    if (condition) { 
        statements; 
    } else if (condition) { 
        statements; 
    } else if (condition) { 
        statements; 
    } else { 
        statements; 
    }

    //for statements
    for (initialization; condition; update) { 
        statements; 
    }

    //while statements
    while (condition) { 
        statements; 
    }

    //try/catch statements
    try { 
        statements; 
    } catch (ExceptionClass exception) { 
        statements; 
    }
  • All for and while loops must use curly braces.

Blank Spaces

  • A java keyword that is followed by a set of parentheses must have a space between the keyword and the left parentheses.
  • Within a set of parentheses, there should be no spaces after the left parentheses or before the right parentheses.
// Keyword spacing

    while (true) {
        ...
    }
  • All commas in lists must be followed by a space.
// Commas and spaces

    addThreeNumbers(5, 10, 15);
  • All binary operators except . (the period) must have space before and after the operator.
// Operators and spaces

    total = variableOne + variableTwo;

    total = (variableOne + variableTwo) / (variableThree * variableFour);

Naming Conventions

  • All class and interface names must start with an uppercase letter.
  • All variable names must start with a lowercase letter.
  • All method names must start with a lowercase letter.
  • All method names should start with a verb and contain more than one word.
  • No abbreviations are allowed in the names of classes, interfaces, variables, or methods. Use only full words for clarity.
  • No one or two character variable names are allowed.
  • Use the “camel case” convention for names that have more than one word. Each word in a name (except for the first word of variables and methods) will start with an uppercase letter. All other letters in the name will be lowercase.
  • Constants must be all uppercase letters with a underscore separating them.

Variable Access

  • All instance variables must be declared private.
  • All instance variables that need to be used outside of a class need to have accessor methods using correct naming conventions as shown in class.

Annotations

Annotations communicate intent to the compiler and to other developers. Use them consistently.

@Override

  • Always add @Override when implementing a method from an interface or overriding a method from a superclass.
  • The compiler will produce an error if your method signature does not actually match the one being overridden, catching typos and signature drift before they become runtime bugs.
// Required: always annotate interface implementations
@Override
public String toString() {
    return name + ": " + value;
}

AI-Assisted Code

Using AI tools (such as Claude, GitHub Copilot, or ChatGPT) to help write code is permitted in this course, consistent with the AI Policy. The following standards apply to any code produced with AI assistance.

You must understand every line you submit. Code you cannot explain is code you do not own. During your code review you will be asked to walk through your code and answer questions about it. If you used AI to generate a block of code and cannot explain what it does or why, that is a problem — not just academically, but professionally.

Review AI-generated code before committing it. AI tools produce code that compiles but may contain subtle bugs, ignore course coding standards, or use patterns that are inappropriate for this project. Always read AI output critically:

  • Does it follow the naming conventions, indentation, and structure required by this document?
  • Does it handle exceptions properly rather than leaving catch blocks empty?
  • Does it actually solve the problem, or does it just look like it does?

Cite AI assistance in your code with a comment. When AI generates a non-trivial block of code — more than a few lines — add a comment identifying the tool and what you asked for. This is the same professional practice as citing any other external source.

// Generated with Claude: prompted for a method to count word frequencies
// from a List<String> using a HashMap. Reviewed and modified to match
// course naming conventions.
public Map<String, Integer> countWordFrequencies(List<String> words) {
    ...
}

Do not use AI to bypass understanding. AI is most useful for exploring options, explaining unfamiliar APIs, or checking your approach — not for producing code you paste in without reading. Use it as a thinking partner, not a shortcut.