Guidelines to be followed by a Java Developer
Every java developer has to follow some standards to develop a good quality-software. In the Coding standards Oracle(Sun) has given some set of rules in java and the developers must follow.Standards lead to consistency and help software engineers avoid common problems. A development environment that uses Java standards has the following advantages:
Rule 1 Always place the public class or interface in a file as the first class.
Rule 2 Always use explicit import statement.
Rule 3 Do not use numbers as words in names.
Rule 4 Do not capitalize any letter other than the first for all words in a name.
Rule 5 Use full English descriptors that accurately describe the variable/field/class/interface. For example, use names like firstName, grandTotal, or CorporateCustomer.
Rule 6 Do not remove letters from words, except to create standard short forms.
Rule 7 Do not use the long form of a word when a standard short form exists.
Rule 8 Always include units in a name when the name refers to an entity with units.
Rule 9 Do not use acronyms in names unless the acronym is industry-standard or is defined in user documentation.
Rule 10 Always treat acronyms as words when applying other naming rules.
Rule 11 Always capitalize the first letter of class name.
Rule 12 Do not include any prefix or suffix to indicate that a name is for any specific type.
Rule 13 Do not include anything in a name to indicate that the name is for a class.
Rule 14 Do not include underscores in names, except after a member’s prefix.
Rule 15 Do not pluralize type names except collections.
Rule 16 Use abbreviations sparingly, but if you do so then use then intelligently and document it
For example, to use a short form for the word “number”, choose one of nbr, no or num.
Rule 17 Always start a method name with a lowercase letter.
Rule 18 Always start method names with a verb.
Rule 19 Always use the following verb opposite pairs when methods perform opposite actions.
Rule 20 Always use the method caller as the frame of reference.
Rule 21 Always include a prefix on field names.
Rule 22 Always ensure that the first letter after a field’s prefix is in lowercase.
Rule 23 Always include white space between a keyword and an open bracket when the keyword occurs first.
Rule 24 Always include white space before and after binary arithmetic, equality, relational, logical, assignment, and bitwise operators.
Rule 25 Do not include white space between a unary operator and its operand.
Rule 26 Do not include white space before the open bracket in a method declaration, method call, open array subscript, or indexer.
Rule 27 Always include white space after a comma.
Rule 28 Always include white space after a semicolon in loop control statements.
Rule 29 Always indent new scope three additional spaces.
Rule 30 Do not use tabs.
Rule 31 Do not ignore checked Exceptions
Rule 32 Always indent the second line and subsequent lines of a multi-line statement an additional six spaces from the first line.
Rule 33 Always break each line of a multi-line statement immediately following a comparison operator.
Rule 34 Always put braces around statement blocks of control statements even if the block is empty or a single line.
Rule 35 Always align an opening brace immediately under the first character of the corresponding keyword.
Rule 36 Always align braces vertically.
Rule 37 Do not nest if/else statements more than 3 levels deep
Rule 38 Do not include more than one statement per line.
Rule 39 Do not include more than one variable declaration per line.
Rule 40 Do not use brackets when a return statement returns a simple value.
Rule 41 Always put every element in an enum definition on a separate line.
Rule 42 Always include a comma after the last value in an enumerated type declaration.
Rule 43 Always indent the case keyword three additional spaces from the corresponding switch statement.
Rule 44 Always comment intentional fall throughs.
Rule 45 Always indent comments at the same level of indentation as the software being documented.
Rule 46 Do not use end-of-line comments.
Rule 47 Always indent end of line comments 3 characters beyond the last character in a statement.
Rule 48 Do not vertically align end-of-line comments.
Rule 49 Do not create methods with more than seven parameters.
Rule 50 Always document restrictions on method parameters
Rule 51 Always check parameters for validity.
Rule 52 Always use exceptions when an invalid parameter is found in a non-private method.
Rule 53 Always use assertions with information expressions to check for invalid parameters private methods.
Rule 54 Do not place a return statement anywhere except as the last line of a method.
Rule 55 Do not use a return statement in a method that returns void.
Rule 56 Do not use a method's return value to indicate that an unexpected error occurred in the method.
Rule 57 Do not make any member variables public.
Rule 58 Always declare fields before methods or constructors in a class
Rule 59 Always order field declarations based on their access specifier
Rule 60 Always declare constructors before any other method, starting with the default constructor if applicable.
Rule 61 Always use an initializer when a member variable is always initialized to the same value.
Rule 62 Always override Object.toString() in a user-defined class.
Rule 63 Do not overload operators unless it is completely obvious what the operator does to the class.
Rule 64 Always override hashCode when you override equals
Rule 65 Do not compare boolean values to true or false to create Boolean expressions.
Rule 66 Do not hardcode strings that are presented to end users.
Rule 67 Always use the form: Type[] name to define an array
Rule 68 Do not use interfaces to define a “constant interface”.
Rule 69 Always comment when a cast is used to convert between value types.
Rule 70 Always use the method equals to compare objects for equality.
Rule 71 Always use enhanced for loop for simple loop implementations
Rule 72 Always postpone variable definitions as long as possible.
Rule 73 Do not use the same variable for multiple purposes.
Rule 74 Do not modify a loop index variable inside a for loop.
Rule 75 Do not create more than one main method in a single package
Rule 76 Every switch statement should include a default case. The break in the default case is redundant, but it prevents a fall-through error if later another case is added.
Rule 77 Always make members, local variables and parameters final when possible.
Rule 78 Do not use literals.
Rule 79 Do not modify a variable on the same line it is used as a condition or array subscript.
Rule 80 Avoid local declarations that hide declarations at higher levels. For example, do not declare the same variable name in an inner block.
Rule 81 Comments should add to the clarity of code. Avoid decoration, i.e., do not use banner-like comments and use single line comment and multiline comments.Document why something is being done, not just what.
Rule 82 Always write Javadoc comments for packages, interfaces, classes, methods, return values, exceptions that are thrown.
Rule 83 Always document the circumstances under which each exception can be thrown using the Javadoc @throws clause.
Rule 84 Always add the "Exception" suffix to the name of types derived from java.lang.Exception.
Rule 85 Always declare each checked exception that can be thrown individually
Rule 86 Always throw unchecked Exceptions if the error is not recoverable by the caller.
Rule 87 Always include failure information in an Exception detail message that contains the values for all parameters and fields that contributed to the exception.
Rule 88 Do not use assertions in non-private methods.
If you found any mistake or wrong statement from the above, please comment below to correct it.
Reference Books:
- Developers can view any Java software and quickly figure out what is going on.
- Developers new to Java are spared the need to develop a personal style.
- Developers make fewer mistakes in consistent environments.
- Discussions about the appropriateness of a language feature are reduced at code reviews.
Rule 1 Always place the public class or interface in a file as the first class.
Rule 2 Always use explicit import statement.
Rule 3 Do not use numbers as words in names.
Rule 4 Do not capitalize any letter other than the first for all words in a name.
Rule 5 Use full English descriptors that accurately describe the variable/field/class/interface. For example, use names like firstName, grandTotal, or CorporateCustomer.
Rule 6 Do not remove letters from words, except to create standard short forms.
Rule 7 Do not use the long form of a word when a standard short form exists.
Rule 8 Always include units in a name when the name refers to an entity with units.
Rule 9 Do not use acronyms in names unless the acronym is industry-standard or is defined in user documentation.
Rule 10 Always treat acronyms as words when applying other naming rules.
Rule 11 Always capitalize the first letter of class name.
Rule 12 Do not include any prefix or suffix to indicate that a name is for any specific type.
Rule 13 Do not include anything in a name to indicate that the name is for a class.
Rule 14 Do not include underscores in names, except after a member’s prefix.
Rule 15 Do not pluralize type names except collections.
Rule 16 Use abbreviations sparingly, but if you do so then use then intelligently and document it
For example, to use a short form for the word “number”, choose one of nbr, no or num.
Rule 17 Always start a method name with a lowercase letter.
Rule 18 Always start method names with a verb.
Rule 19 Always use the following verb opposite pairs when methods perform opposite actions.
Rule 20 Always use the method caller as the frame of reference.
Rule 21 Always include a prefix on field names.
Rule 22 Always ensure that the first letter after a field’s prefix is in lowercase.
Rule 23 Always include white space between a keyword and an open bracket when the keyword occurs first.
Rule 24 Always include white space before and after binary arithmetic, equality, relational, logical, assignment, and bitwise operators.
Rule 25 Do not include white space between a unary operator and its operand.
Rule 26 Do not include white space before the open bracket in a method declaration, method call, open array subscript, or indexer.
Rule 27 Always include white space after a comma.
Rule 28 Always include white space after a semicolon in loop control statements.
Rule 29 Always indent new scope three additional spaces.
Rule 30 Do not use tabs.
Rule 31 Do not ignore checked Exceptions
Rule 32 Always indent the second line and subsequent lines of a multi-line statement an additional six spaces from the first line.
Rule 33 Always break each line of a multi-line statement immediately following a comparison operator.
Rule 34 Always put braces around statement blocks of control statements even if the block is empty or a single line.
Rule 35 Always align an opening brace immediately under the first character of the corresponding keyword.
Rule 36 Always align braces vertically.
Rule 37 Do not nest if/else statements more than 3 levels deep
Rule 38 Do not include more than one statement per line.
Rule 39 Do not include more than one variable declaration per line.
Rule 40 Do not use brackets when a return statement returns a simple value.
Rule 41 Always put every element in an enum definition on a separate line.
Rule 42 Always include a comma after the last value in an enumerated type declaration.
Rule 43 Always indent the case keyword three additional spaces from the corresponding switch statement.
Rule 44 Always comment intentional fall throughs.
Rule 45 Always indent comments at the same level of indentation as the software being documented.
Rule 46 Do not use end-of-line comments.
Rule 47 Always indent end of line comments 3 characters beyond the last character in a statement.
Rule 48 Do not vertically align end-of-line comments.
Rule 49 Do not create methods with more than seven parameters.
Rule 50 Always document restrictions on method parameters
Rule 51 Always check parameters for validity.
Rule 52 Always use exceptions when an invalid parameter is found in a non-private method.
Rule 53 Always use assertions with information expressions to check for invalid parameters private methods.
Rule 54 Do not place a return statement anywhere except as the last line of a method.
Rule 55 Do not use a return statement in a method that returns void.
Rule 56 Do not use a method's return value to indicate that an unexpected error occurred in the method.
Rule 57 Do not make any member variables public.
Rule 58 Always declare fields before methods or constructors in a class
Rule 59 Always order field declarations based on their access specifier
Rule 60 Always declare constructors before any other method, starting with the default constructor if applicable.
Rule 61 Always use an initializer when a member variable is always initialized to the same value.
Rule 62 Always override Object.toString() in a user-defined class.
Rule 63 Do not overload operators unless it is completely obvious what the operator does to the class.
Rule 64 Always override hashCode when you override equals
Rule 65 Do not compare boolean values to true or false to create Boolean expressions.
Rule 66 Do not hardcode strings that are presented to end users.
Rule 67 Always use the form: Type[] name to define an array
Rule 68 Do not use interfaces to define a “constant interface”.
Rule 69 Always comment when a cast is used to convert between value types.
Rule 70 Always use the method equals to compare objects for equality.
Rule 71 Always use enhanced for loop for simple loop implementations
Rule 72 Always postpone variable definitions as long as possible.
Rule 73 Do not use the same variable for multiple purposes.
Rule 74 Do not modify a loop index variable inside a for loop.
Rule 75 Do not create more than one main method in a single package
Rule 76 Every switch statement should include a default case. The break in the default case is redundant, but it prevents a fall-through error if later another case is added.
Rule 77 Always make members, local variables and parameters final when possible.
Rule 78 Do not use literals.
Rule 79 Do not modify a variable on the same line it is used as a condition or array subscript.
Rule 80 Avoid local declarations that hide declarations at higher levels. For example, do not declare the same variable name in an inner block.
Rule 81 Comments should add to the clarity of code. Avoid decoration, i.e., do not use banner-like comments and use single line comment and multiline comments.Document why something is being done, not just what.
Rule 82 Always write Javadoc comments for packages, interfaces, classes, methods, return values, exceptions that are thrown.
Rule 83 Always document the circumstances under which each exception can be thrown using the Javadoc @throws clause.
Rule 84 Always add the "Exception" suffix to the name of types derived from java.lang.Exception.
Rule 85 Always declare each checked exception that can be thrown individually
Rule 86 Always throw unchecked Exceptions if the error is not recoverable by the caller.
Rule 87 Always include failure information in an Exception detail message that contains the values for all parameters and fields that contributed to the exception.
Rule 88 Do not use assertions in non-private methods.
If you found any mistake or wrong statement from the above, please comment below to correct it.
Reference Books:
