Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1.Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 3. Classes and interfaces: Use nouns, in mixed case with first letter of each word capitalized. The code self-documenting with appropriate 4.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0 ratings0% found this document useful (0 votes)
43 views41 pages
Java Code Conventions Quick Reference
Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1.Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 3. Classes and interfaces: Use nouns, in mixed case with first letter of each word capitalized. The code self-documenting with appropriate 4.
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. Return statements while statements switch statements
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. 1. Do not enclose the return value in parentheses Use the following format: Use the following format:
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. unless they make the return value more while (condition) { switch (condition) {
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. obvious in some way. statements; case ABC:
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. 2. Make the structure of your code match its } statements;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. intent: /* falls through */
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. Replace this if-else statement: for statements
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. if (booleanExpression) { Use the following format: case DEF:
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. return true; for (initialization; condition; update) { statements;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. } else { statements; break;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. return false; }
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. } Declare the loop control variable inside for-loop: default:
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. with a return statement: for (int i = 0; i < size; ++i) { statements;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. return booleanExpression; statements; break;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. Replace this code fragment: } }
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. if (condition) { 1. Always include default case.
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. return x; do-while statements 2.Use the comment line /* falls through
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. } Use the following format: */ when the case label does not have
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. return y; do { a break statement.
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. with a return statement: statements;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. return (condition ? x : y); } while (condition); try-catch blocks
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. Use the following format:
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. Ternary statements if-else statements try {
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. The following formats are acceptable: Use the following formats: statements;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. a = condition ? b : c; if (condition) { } catch (ExceptionClass e) {
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. a = condition ? b statements; statements;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. : c; } }
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. a = condition if (condition) {
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. ? b statements; Line wrapping for if-statements
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. : c; } else { Use 8 space rule (2 tabs) when wrapping
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. 1. Parentheses around condition are optional. statements; an if-statement so body is easier to see:
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. 2. Use parentheses when the condition is a binary } if ((a && b)
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. expression: if (condition) { || (c && d)
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. absoluteValue = (x >= 0) ? x : -x; statements; || (e && f)) {
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. 3. Avoid nested ternary statements. } else if (condition) { statements;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. 4. Use conditional operator, not if-else statement, statements; }
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. when assigning a value to a variable: } else {
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. a = condition ? b : c; statements;
Indentation Implementation comments Naming conventions 1. Use four spaces as the unit of indentation. 1.Do not add comments that state the obvious. 1. Names should be words or word phrases. Keep 2. Use tabs or spaces to indent, not a mixture of 2. A blank line should precede a comment. names short but descriptive. Avoid abbreviations. the two. (Exception: A mixture can be used 3. Minimize the need for comments by making 2. Classes and interfaces: Use nouns, in mixed when wrapping lines). the code self-documenting with appropriate case with first letter of each word capitalized. 3. Do not indent top-level classes and interfaces. name choices and an explicit logical structure. Examples: TextField and MouseListener 4. Indent variables, methods, and named inner 4. Comments should provide additional 3. Methods: Use verbs, in mixed case with first classes one level. information that is not readily apparent in the letter lowercase and first letter of each internal 5. Indent the body of a method one level. code itself. Comments that present an word capitalized. Example: setBackground overview of a code block can be useful. 4. Variables: Use nouns, in mixed case with first Braces for methods, classes, and interfaces // single-line comment letter lowercase and first letter of each internal 1. Put opening brace on same line as declaration. /* single-line comment */ word capitalized. Example: fontSize 2. Put closing brace on new line and indent it to /* 5. Constants: All uppercase with words separated the level of the matching declaration. * block comment by underscores. Example: EXIT_ON_CLOSE class Example { */ statement; // trailing comment Blank lines private void doTask() { Use one blank line: Javadoc comments: 1. Before a comment statements; 1. Use to document classes, interfaces, 2. Between methods } methods, and variables (with class-scope). 3. After a method header } 2.Should describe the entity being documented 4. After a block of local variable declarations from an implementation-free perspective. 5. Between logical sections of code so that logically- Miscellaneous /** related statements are grouped 1. Avoid lines longer than 80 characters. * Javadoc comment 2. One statement per line. */ Spaces 3. One declaration per line. /** Javadoc comment */ Use a space: 4. Initialize variables when they are declared 1. Between a keyword and a left parenthesis except when the initial value is unknown. Wrapping lines 2. After commas in argument and parameter lists 5. If a control structure—like an if-statement or a When a statement will not fit on a single line: 3. To separate a binary operator from its operands for-loop—contains a single statement, the 1. Break after a comma (see exception below) single statement should be enclosed in braces. 4. To separate a ternary operator from its operands. 6. Use the class name, not a reference, to access 2.Break before a binary operator 5. Between initialization, expression, and update static methods and variables. 3. Prefer high-level breaks to low-level breaks parts of a for-loop 7. Use parenthesis to clarify the order of 4. Align new line with beginning of expression 6. After a cast evaluation in complex expressions. (or argument list) on previous line: a = b * (c + d – e) Do not use a space: 8. Avoid coding literal constants directly. Use a 1. Between the dot operator ( . ) and its operands + (f / g); well-named symbolic constant instead. 2. Between a unary operator and its operand x = getValue(a + b + c, (Exception: 0, 1, and –1 are acceptable.) 3. Between a method name and a left parenthesis d + e + f); 5. If these rules lead to confusing code or code that’s jammed up against the right margin, indent 8 spaces (2 tabs) instead. }