1. Naming Files
2. Classes
3. Methods
4. Attributes/Variables
5. Line Length
6. Comments
7. Keys & Indent
8. Test
9. Exceptions
10. Asserts

In all project file's content must be named in english. The name of the files in Java must have the same name of the Class. Java establishes an order that must be used in the file:

• File Initial Comment
• Package
• Imports
• Class and it's methods

Betwen each set of imports must have one line blank.

Bad example:

Good example:

The name of classes must begin with Capital Letter in the singular, and must not be abbreviated. The following rules must be followed:

• Public classes must appear first #1 in the class. Private should be last.
• Names made by multiple letters must follow the standard UpperCameloCase, where each word will begin with a CapitalLetter.
• The name must not have any characters other than the letter of alphabet.

The functional order of components of the class are:

• Constants
• Attributes of the class
• Attributes of the instance
• Constructors
• Main methods
• Helper methods

Example:

Bad:

Good:

All methods will have their initial & final parameters without a space between the opening and closing of their parenthesis. Each aditional parameter will have a comma at the end of the following and a ' '(space) for the beginning of the new parameter.

• Methods must be named in lowerCammelCase.
• Methods needs a verb to describe the action he execute.

Example: Bad:

Good:

Error messages must start with upper case and finish with finish dot. follow the pattern:

---

Also parameters that are not modified during execution of method should be constant and defined "final" following the rules for constant declaration: NAME_NAME

Exemple:

The attributes must follow this formatting standard:

• Only one declaration in each line.
• The names must follow the standard lowerCamelCase.
• They can't be abbreviated.
• They can't have special characters.
• For constant names with two names, they need to be separated with the underscore and be written all with capital letters.
• Global variables should not be used, but if it must then it shall follow the java pattern: NAME_NAME
• Contantes should also follow the pattern: NAME_NAME

Example of variables:

Global variables examples:

Avoid lines longer than 80 characters. When a statement won't fill in a single line, it may be necessary to break it.

Comments should be used only when talking about context. The code should be self explanatory. Except in the beginning of classes and public methods, in which must be used java doc docummentation comments.

The comments must be initialized first with capital letter. At their end, it must be add a '.' (dot) to indicate it's end.

To document a public method, you must use the type '/** & */, and to start typing there must be a space. The comments also should include the tags @param for the parameters, @returns for the return value and @throws to explain the exception that the method throws.

Example of Class comment:

For single line comments, we use //. The // can be used inside methods, inside classes, and for short declaration comment.

Example of single line comment:

The /.../ single line comment is used only in if-else statements to show which one don't have an action.

If technical comments exceed one line they must be changed from '//' to /* & */, jumping a line to start and a line to finish.

Example of multiple lines comment:

When if / else statement have no action, leave a commentary like this.

Example 1:

Example 2:

All source files should begin with a c-style comment that contains the file name, file extension, and a brief description of the purpose of the program with two sentences max. The comment syntax should beggin with thirty * and end with * following the exemple:

All keys must be in the same line of command. The value of a tab must be equivalent to 4 spaces. Every if statement shall have your else . If the latter does not take any action should be a comment, as specified in statement comments.

The variable declarations and methods must be separated each by a blank line. Between the sentences package & import, must have a blank line. Between imports from different API's there must be a blank line.

Each attribution, with the operator '=' must be followed with an unitary space before & after. In the use of a comma, there must be an empty space after. There must be space between the closing of parenthesis and method keys. In logical & arithmetic operations, there must be a blank space between the operators and operands.

Instructions that break the line must be aligned with the operator '+' in the next line. In parameters, the line breaker (if necessary) must be after a comma.

Annotations should be written in previous line, see samples:

It should be used in any kind of annotation and any place.

The name of the test classes must have "Test" followed by the name of the tested class.

The name of the methods must sugest the funcionality witch is being tested.

When using resources for exception handling for the methods or logic & arithmetic expressions, these rules apply.

When you finish the 'try', must start in the same line with the 'catch' with a space of the end of one and the beginning of the other.

When using "Throws" to pass the exception on to the next function in order to treat it, the method should look like this:

When creating assert one must verify parameters to avoid GIGO (garbage in, garbage out). Follow the patterns of the example: