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:
1. Developers can view any Java software and quickly figure out what is going on.
2. Developers new to Java are spared the need to develop a personal style.
3. Developers make fewer mistakes in consistent environments.
Discussions about the appropriateness of a language feature are reduced at code reviews.
The List of Guidelines given below:
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 starts 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 5: 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
1. Developers can view any Java software and quickly figure out what is going on.
2. Developers new to Java are spared the need to develop a personal style.
3. Developers make fewer mistakes in consistent environments.
Discussions about the appropriateness of a language feature are reduced at code reviews.
The List of Guidelines given below:
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 starts 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 5: 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
No comments:
Post a Comment