Powered by Blogger.

Guidelines to be followed by a Java Developer

>> Saturday, July 19, 2014

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:
Guidelines to be followed by a Java Developer_JavabynataraJ
  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.
  4. 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 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:

Related Posts Plugin for WordPress, Blogger...
© javabynataraj.blogspot.com from 2009 - 2014. All rights reserved.