- It is a good practice to declare a variable close to the point of its possible use. This not only enhances readability of the code but also makes debugging simpler.
- Do not use the same name for local variables as the class member variables.
- If possible keep method parameters final.
- Keep in mind Boxing and Unboxing of primitive data types.
- Use StringBuffer and/or StringBuilder where needed instead of just using String.
- Use Proper Naming Conventions: Follow naming conventions for classes, interfaces, variables, constants, methods, annotations, packages, enums.
- One should always use classes, methods, interfaces, enums, and annotations from the Java standard library as much as possible instead of blindly using the third-party libraries or frameworks.
- If possible design your classes to be immutable. This saves you from any trouble from concurrent modifications.
- Include unit testing as part of your development/coding. Follow TDD, BDD approach.
- Don't make any instance or class variable public without good reason.
- Numerical constants (literals) should not be coded directly, except for -1, 0, and 1, which can appear in a for loop as counter values.
- Avoid using an object to access a class (static) variable or method. Use a class name instead.
- It is generally a good idea to use parentheses liberally in expressions involving mixed operators to avoid operator precedence problems.
- Special Comments: Use XXX in a comment to flag something that is bogus but works. Use FIXME to flag something that is bogus and broken.
- Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
- Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
- One blank line should always be used in between the local variables in a method and its first statement.
- Comment your code.
- Use Underscores in lengthy Numeric Literals.
- Use Enums where possible. private enum Answer { YES { @Override public String toString() { return "yes"; } },
NO,
MAYBE
}
- Use Type-use annotations. Example - final @Nullable String name;
- Numeric Literals: long-valued integer literals use an uppercase L suffix, never lowercase (to avoid confusion with the digit 1). For example, 3000000000L rather than 3000000000l
- Use of optional braces: Braces are used with if, else, for, do and while statements, even when the body is empty or contains only a single statement. Other optional braces, such as those in a lambda expression, remain optional.
- No wildcard imports: Wildcard imports, static or otherwise, are not used.
-
Every class should be preceded with a descriptive comment using the "JavaDoc" notational convention.
Example:
/**- Stores the first, middle, and last names for a president. */ class President { //code... }
Open braces (i.e. "{") do not start a new line.
Close braces (i.e. "}") do start a new line, and are indented with the code they close.
Example:
for (int i=0; i < args.length; i = i + 1) {
vals.insertElementAt(new Float (args[i]), i);
// Transmogrify is incremental and more efficient inside the loop.
vals.transmogrify();
}Lines of code should be kept short, generally less than 80 or 100 characters wide.
Documentation Comments?
Never leave a Catch Blocks empty.
Use enhanced for loops instead of for loops with counter.
Return Empty Collections instead of returning Null elements.
References: https://www.oracle.com/java/technologies/javase/codeconventions-programmingpractices.html
Credits:
https://unsplash.com/photos/SyvsTmuuZyM
Top comments (0)