- Classes and Interfaces: Use PascalCase, starting with uppercase, e.g.,
MyClass
. - Methods and Variables: Use camelCase, starting with lowercase, e.g.,
myVariable
. - Constants: Use all uppercase with underscores, e.g.,
MY_CONSTANT
. - Packages: Use lowercase, avoiding underscores if possible, e.g.,
mypackage
.
- Braces: Use the "K&R style" for braces, where opening braces are at the end of the line and closing braces start on a new line aligned with the start of the line that opened them.
- Indentation: Use spaces (commonly 4) instead of tabs for indentation.
- One Statement per Line: Avoid multiple statements on a single line.
- Line Length: Keep lines to 80-100 characters long, if possible, for readability.
- Spacing and Blank Lines: Use spaces around operators and after commas for clarity. Use blank lines to separate logical blocks of code.
- Use Javadoc Standard Comments for classes, interfaces, methods, and fields.
- Inline Comments: Use them sparingly to explain "why" not "what".
- TODO Comments: Mark sections of the code that need enhancements or fixes with
// TODO:
comments.
- Visibility: Use the least visibility necessary for classes, methods, and members.
- Final Classes and Methods: Use
final
on methods and classes that are not designed for extension or overriding. - Static Methods: Prefer static methods if no access to instance fields is required.
- Immutable Objects: Strive for immutability in classes wherever practical.
- Parameter Passing: Prefer passing interfaces or supertypes instead of concrete classes.
- Return Types: Prefer returning interfaces or supertypes for flexibility.
- Overloading With Caution: Only overload methods for significantly different behaviors.
- Exceptions: Prefer unchecked (runtime) exceptions unless you expect the caller to recover.
- Catch Blocks: Handle exceptions as close to the source as possible, providing meaningful responses or logging.
- Usage: Use generics for type safety and to avoid casts.
- Naming Conventions: Use single uppercase letters for generic type parameters, e.g.,
E
for element,K
for key,V
for value.
- Usage: Prefer enums over constants for fixed sets of constants, such as days of the week.
- Implementing Interfaces: Use enums to implement interfaces for added utility and flexibility.
- Separation of Concerns: Separate code into different classes and methods based on functionality.
- Use of Packages: Organize classes into packages that represent different layers or features of your application.
- Unit Testing: Follow naming conventions for tests, usually reflecting the method name with a
Test
suffix, e.g.,methodNameTest
. - Assertive Testing: Use assertive language in test case names, like
shouldReturnXYZWhenABC
.
- Commit Messages: Use informative and concise commit messages that describe changes clearly.
- Branching Strategy: Adopt a consistent branching strategy like GitFlow or feature branching.