Google Java Style Checklist

Source: Google Java Style Guide, https://google.github.io/styleguide/javaguide.html

Use this checklist when generating, editing, formatting, or reviewing Java code. It summarizes the enforceable rules most likely to affect Codex output; consult the source guide for edge cases.

Source Files

• Name ordinary source files after the single top-level class plus .java.
• Encode source files as UTF-8.
• Use ASCII horizontal space as the only whitespace character outside literals; do not use tab indentation.
• Structure ordinary files in this order: license or copyright, package declaration, imports, exactly one top-level class.
• Separate present file sections with exactly one blank line.
• Include a package declaration in every ordinary source file; do not line-wrap package declarations.
• Do not apply the ordinary package declaration rule to module-info.java.

Imports

• Do not use wildcard imports.
• Do not use module imports.
• Do not line-wrap import statements.
• Put static imports first, then non-static imports.
• Separate static and non-static import groups with one blank line when both exist.
• Do not add other blank lines within import groups.
• Sort imported names in ASCII order within each group.
• Do not use static import for static nested classes; import them normally.

Class Contents

• Keep methods or constructors with the same name in one contiguous overload group.
• Choose a logical member order that a maintainer could explain.
• Do not append new members only by chronology when a better logical grouping exists.

Braces, Indentation, and Lines

• Use braces with if, else, for, do, and while, even for empty or single-statement bodies.
• Use K&R braces for nonempty blocks: opening brace on the same line, line break after it, line break before closing brace.
• For empty blocks, either use {} or normal block form, except do not use concise empty blocks in multi-block statements such as try/catch or if/else.
• Increase indentation by 2 spaces for each block or block-like construct.
• Put one statement on each line.
• Keep Java code within 100 columns except for package/import lines, text block contents, long URLs, copyable command lines in comments, impossible-to-wrap lines, and rare long identifiers.
• When wrapping, prefer breaking at a higher syntactic level.
• Break before non-assignment operators, including ., ::, & in type bounds, and | in catch alternatives.
• Assignment operators may be broken before or after, but usually after.
• Keep a method, constructor, or record-class name attached to its following (.
• Keep commas attached to the preceding token.
• Do not break adjacent to a lambda or switch arrow except immediately after the arrow when followed by one unbraced expression.
• Indent continuation lines at least 4 spaces beyond the original line.

Whitespace

• Use one blank line between consecutive class members or initializers, except consecutive fields may omit blank lines when logically grouped.
• Use blank lines sparingly to group logical subsections; multiple consecutive blank lines are permitted but discouraged.
• Use one ASCII space where required by Java syntax and Google style, including:
  • between keywords such as if, for, and catch and a following (;
  • between else or catch and a preceding };
  • before {, except in annotation array values and compact array initializers;
  • around binary and ternary operators, lambda arrows, switch arrows, enhanced-for colons, type-bound &, and catch alternative |;
  • after ,, :, ;, and a cast closing parenthesis;
  • between a declaration type and identifier.
• Do not add spaces around . or ::.
• Horizontal alignment with extra spaces is permitted but never required; do not churn nearby lines just to preserve alignment.
• Use grouping parentheses when they improve readability; omit them only when misreading is unlikely.

Specific Constructs

• Enum constants may be one per line, grouped with blank lines as needed, or compact for simple undocumented enums with no methods.
• Declare one variable per field or local declaration; multiple variables are allowed only in a for loop header.
• Declare local variables close to first use and initialize them promptly when practical.
• Use String[] args, not String args[].
• Indent switch labels 2 spaces inside the switch block.
• Make every switch exhaustive, even if Java does not require it; add default when needed.
• Use new-style arrow switches for switch expressions.
• In old-style switches, comment intentional fall-through at the end of the statement group, commonly // fall through.
• Place type-use annotations immediately before the annotated type.
• Put class, package, module, method, and constructor annotations after Javadoc, one per line, except a single parameterless method or constructor annotation may share the signature line.
• Field annotations may share a line.
• Use block comments at the same indentation as surrounding code; do not draw boxed comments.
• Format TODO comments as TODO: <tracked-context> - <explanation> when a TODO is necessary.
• Put modifiers in Java Language Specification order: public protected private abstract default static final sealed non-sealed transient volatile synchronized native strictfp.
• Use uppercase L for long literals.
• Put text block opening and closing triple quotes on their own lines.

Naming

• Use identifier names made from ASCII letters and digits, with underscores only in allowed cases.
• Do not use special prefixes or suffixes such as mName, s_name, name_, or kName.
• Package and module names use lowercase letters and digits only, with words concatenated.
• Class, record, enum, interface, and annotation type names use UpperCamelCase; test class names end in Test.
• Method names use lowerCamelCase; JUnit test methods may use underscores between logical name parts.
• Constant names use UPPER_SNAKE_CASE.
• Treat only deeply immutable static final fields as constants. Mutable collections, mutable elements, arrays with mutable contents, loggers, and non-static finals are not constants.
• Non-constant field names, parameter names, and local variable names use lowerCamelCase.
• Avoid one-character parameter names in public methods.
• Type variable names are either a single capital letter optionally followed by one numeral, or UpperCamelCase followed by T.
• When converting acronyms to camel case, lowercase the acronym as part of the word: XmlHttpRequest, newCustomerId, supportsIpv6OnIos.

Programming Practices

• Add @Override whenever legal, except it may be omitted when the parent method is deprecated.
• Do not silently ignore caught exceptions. Log, rethrow, handle, or explain a truly intentional no-op in a comment.
• Qualify static member references with the class name, not an instance or expression.
• Do not override Object.finalize.

Javadoc

• Use standard Javadoc blocks or a single-line Javadoc only when the whole block fits on one line and has no block tags.
• Separate Javadoc paragraphs with one blank * line.
• Put <p> immediately before the first word of every paragraph after the first.
• Order standard block tags as @param, @return, @throws, @deprecated.
• Do not leave block tag descriptions empty.
• Indent wrapped block tag continuation lines at least 4 spaces from the @.
• Start each Javadoc block with a brief summary fragment, capitalized and punctuated.
• Provide Javadoc for every visible public/protected class, member, or record component unless it is a truly simple and obvious member or an override where inherited Javadoc is sufficient.
• Use Javadoc, not an implementation comment, when documenting the overall purpose or behavior of a class or member.