Content Analysis
AnEsh
OODP101_Week6.pptx
Object Oriented Design and Programming
Week 6
Emran Salahiddin, Chiatalia Samani, Anchal Shrestha (Sydney)
Hanspreet Kaur, Allan NG (Melbourne)
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
SLIDE TITLE
Farrell, J. (2017) Programming Logic and Design, Comprehensive (9th ed.) Cengage Learning
2
2
Programming Logic and Design Ninth Edition
Programming and coding standards
3
Introduction
To build reliable, scalable and maintainable Java applications :-
Development teams should adopt proven design techniques.
And should choose good coding standards.
Will result in code consistency, which makes it easier to understand, develop and maintain the application.
Programmer can make the code more efficient and performance effective
4
Standards
File organization Standards
Source code style guidelines
Declarations
Standards for Statements
Naming Convention standards
Variable Assignments
5
http://gccegov.org/documents/10179/276020/Java_standards_v1.0_%28NEAF%29.pdf/acd4a9dd-1ff4-4ba6-8b48-f6f5e953edd7
5
File organization Standards
Java source are named as *. java
The compiled Java byte code is named as *.class file
Each Java source file contains a single public class or interface.
Each class must be placed in a separate file.
Java classes should be packaged in a new java package for each self-contained project or group of related functionality.
6
File organization Standards
Java Source files should have the following ordering: Package and Import statements, beginning comments, Class and Interface Declarations.
There should not be any duplicate import statement.
Files longer than 2000 lines should be avoided.
7
Source code style guidelines
Beginning Comments
-All source files should begin with header as follows carrying the Title, Version, Date in mm/dd/yy format and the copyright information.
8
Source code style guidelines
Indentation
Four spaces should be used as the unit of indentation.
The indentation pattern should be consistently followed throughout.
9
Source code style guidelines
Left and Right braces
Both starting and ending braces should be on separate line and properly aligned
10
Source code style guidelines
Wrapping Lines
Lines longer than 80 characters should be avoided
When an expression will not fit on a single line, it should be broken according to these general principles:
1. Break after a comma.
2. Break after an operator.
3. Prefer higher-level breaks to lower-level breaks.
4. Align the new line with the beginning of the expression at the same level on the previous line.
11
Source code style guidelines
Wrapping Lines
5. If the above rules lead to confusing code or to code that's squished up against the right margin, just indent 4 spaces instead.
12
Source code style guidelines
White Space (Blank Lines)
Blank lines improve readability by setting of sections of code that are logically related.
One blank line should always be used in the following circumstances:
Between methods.
Between the local variables in a method and its first statement.
Before a block or single-line comment.
Between logical sections inside a method to improve readability.
Before and after comments
13
Source code style guidelines
Blank spaces should be used in the following circumstances:
A keyword followed by a parenthesis should be separated by a space. Example: while (true)
A blank space should appear after commas in argument lists.
All binary operators except a period ‘.’ should be separated from their operands by spaces.
Blank spaces should never separate unary operators such as unary minus, increment (“++”), and decrement (“--”) from their operands.
The expressions in a for statement should be separated by blank spaces. E.g. for (expr1; expr2; expr3)
14
Source code style guidelines
Implementation Comments
Java codes should have implementation comments delimited by /*...*/ or //
For commenting out code a double slash i.e. // is recommended.
For single line comment, /*….*/ is recommended.
For clarity in code, comments should be followed by a blank line.
For documentation comments, /**...*/
15
Declarations
One declaration per line is recommended.
The order and position of declaration should be as follows:
First public class variables, protected, package/default level i.e. with no access modifier and then the private.
Instance variables should be placed in the sequence: First public instance variables, protected, package level with no access modifier and then private.
16
Declarations
Next the class constructors should be declared.
Class methods should be grouped by functionality rather than by scope or accessibility to make reading and understanding the code easier.
Declarations for local variables should be only at the beginning of blocks
Local declarations that hide declarations at higher levels should be avoided. For example, same variable name in an inner block.
Numerical constants should not be coded directly except 1, 0, -1.
17
17
Standards for Statements
Each line should contain at most one statement.
Compound statements are statements that contain lists of statements enclosed in braces.
The opening brace should be at the end of the line that begins the compound statement. The closing brace should begin a line and be indented to the beginning of the compound statement. Such as a if-else or for statement.
18
18
Naming Convention standards
19
Naming Variables
Use a full English descriptor for variable names to make it obvious what the field represents.
Variable names should not start with an underscore _ or dollar sign $ characters
Should be short and meaningful
19
Naming Convention standards
20
Naming Constants
Constants, whose values that do not change, are typically implemented as static final fields of classes.
They should be represented with full English words, all in uppercase, with underscores between the words like FINAL_VALUE.
20
Naming Convention standards
21
Naming Collections
Fields, that are collections, such as arrays or vectors, should be given names that are plural to indicate that they represent multiple values.
Naming Streams
- When there is a single input and/or output stream being opened, used, and then closed within a method the common convention is to use ‘in’ and ‘out’ for the names of these streams, respectively.
21
Naming Convention standards
22
Variable Assignments
Assigning several variables to the same value in a single statement should be avoided, i.e., we should avoid constructs like var1 = var2 = var3 = 0;
Assignment operator should not be used in a place where it can be easily confused with the equality operator
22
Standards for classes
23
Standards for Classes
Class names should be simple full English descriptor nouns, in mixed case starting with the first letter capitalized and the first letter of each internal word also capitalized.
Whole words should be used instead of acronyms and abbreviations unless the abbreviation is more widely used than the long form
Each class should have an appropriate constructor and
The documentation comments for a class start with the header for class with filename, version, copyright and related information
23
Summary
24
Programmer can make the code more efficient and performance effective by following appropriate coding standards.
24
kent.edu.au Kent Institute Australia Pty. Ltd. ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
25
25
