Java Coding Standards

This document outlines the Java coding standards to be followed in all development projects. These guidelines are based on the Google Java Style Guide and aim to ensure readability, maintainability, and consistency across codebases.

---

1. File and Class Organization

• File Naming:

  • Each top-level class must be in its own file.
  • File name must match the class name (e.g., MyClass.java).

• Class Naming:

  • Use UpperCamelCase for class and interface names.

  • Example:

    public class CustomerOrder { ... }

• Package Naming:

  • Use all lowercase letters.
  • Avoid underscores.
  • Example: com.example.project.module

• Order of Members:

  • Constants → Fields → Constructors → Methods → Inner Classes

---

2. Formatting

• Indentation:

  • 2 spaces per indentation level.
  • Do not use tabs.

• Line Length:

  • Maximum 100 characters per line.

• Braces:

  • Always use braces for if, else, for, while, and do.

  • Opening brace goes on the same line as the statement.

  • Example:

    if (condition) {
      doSomething();
    } else {
      doSomethingElse();
    }

• Whitespace:

  • Single space after keywords like if, for, while.
  • No space between method name and parentheses when invoking or declaring.

---

3. Identifiers

• Variables and Methods:

  • Use lowerCamelCase.
  • Example: int totalCount; or void calculateTotal() { ... }

• Constants:

  • Use UPPER_SNAKE_CASE.
  • Example: static final int MAX_SIZE = 100;

---

4. Comments

• Javadoc Comments:

  • Use for all public classes, methods, and fields.

  • Format:

    /**
     * Calculates the total order amount.
     *
     * @param quantity Number of items
     * @param price    Price per item
     * @return Total cost
     */
    public double calculateTotal(int quantity, double price) { ... }

• Inline and Block Comments:

  • Use // for short explanations.
  • Use /* ... */ for longer, multi-line comments.
  • Keep comments up to date; remove obsolete comments.

---

5. Programming Practices

• Use final when possible:

  • Mark fields, parameters, and local variables as final when they should not change.

• Avoid magic numbers:

  • Replace with named constants.

• Prefer standard library methods:

  • Avoid reinventing the wheel; use Collections, Streams, Optional, etc.

• Exceptions:

  • Catch the most specific exception possible.
  • Do not catch Exception unless absolutely necessary.

• Null handling:

  • Minimize use of null; prefer Optional for return values that may be absent.

---

6. Testing

• Write unit tests for all public methods.
• Use descriptive names for test methods, e.g., calculateTotal_givenValidInput_returnsCorrectSum().
• Follow Arrange-Act-Assert (AAA) pattern for test clarity.

---

7. Annotations

• Use @Override when overriding methods.
• Use @Deprecated with a comment indicating replacement.
• Use @SuppressWarnings only when absolutely necessary and document why.

---

8. Version Control Practices

• Use meaningful commit messages, e.g., Fix null pointer in calculateTotal.
• Keep commits small and focused.
• Merge feature branches only after passing code review and tests.

---

Reference

• Google Java Style Guide