Professional Documents
Culture Documents
Best Coding Practices
Best Coding Practices
File Organization
Java source are named as *. java while 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. This also
applies to non public classes too.
If a file consists of sections, they should be separated by blank lines and an optional comment, identifying
each section. Files longer than 2000 lines should be avoided.
Java classes should be packaged in a new java package for each self contained project or group of related
functionality.
Preferably there should be an html document file in each directory briefly outlining the purpose and structure
of the package.
Java Source files should have the following ordering: Package and Import statements, beginning comments,
Class and Interface Declarations.
2
File Organization
There should not be any duplicate import statement. There should not be any hard coded values in code.
3
Coding comments
/************************************************
*
* Author Assignment Class Approved by Modified Date
<Your name> <Assignment name> <CSI class name> <Managers name> <date of modification/creation>
<Your name> <Assignment name> <CSI class name> <Managers name> <date of modification/creation>
*
*
************************************************/
Add JavaDoc to all of your code, including classes, methods, etc. Before submission make sure that you can
run the JavaDoc export without any errors or warnings.
4
Coding comments
/**
* Adds two ints (a+b) and returns the result
*
* @param a first integer to add
* @param b second integer to add
*
* @returns the sum of a+b
* @throws OverflowException
* if a+b exceeds the value representable by int
*/
5
CR coding comments
When working on CR’s for specific clients, add comments above the lines of logic being written
/************************************************
*
* Author CR No. Class Approved by Modified Date
<Your name> <CR No.> <CSI class name> <Managers name> <date of modification/creation>
<Your name> <CR No.> <CSI class name> <Managers name> <date of modification/creation>
*
*
************************************************/
When the line of CR logic has been completed, add end comments
/* End of <CR No.>*/
6
Coding comments
Properly (but reasonably) comment your code. A developer should be able to get a general idea of what’s
going on by just reading comments (and no code).
7
Indentation
Spaces should be used as the unit of indentation. The indentation pattern should be consistently followed
throughout.
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:
Prefer higher level breaks to lower level breaks. (in other words avoid breaking nested expressions).
Align the new line with the beginning of the expression at the same level on the previous line.
If the above rules lead to confusing code or to code that's squished up against the right margin, just indent 4
spaces instead.
Example:
count = number.calculate(bytes, offset, length,
value, 0, estimatedCount);
long value = ((totalValue < plannedValue ) ?
totalValue : plannedValue );
White Space and Blank lines improve readability by setting of sections of code that are logically related.
9
Indentation
10
Naming conversions
Avoid using non ASCII characters and words from local language.
A class name should be noun (Employee,) and method names should start with verb (get, set,).
11
Naming conversions
12
Declarations
Try to use standard library instead of writing your own from scratch.
13
Use Strings with utmost care.
Rule of 30
– Methods should not have more than an average of 30 code lines (not counting line spaces and
comments).
– A class should contain an average of less than 30 methods, resulting in up to 900 lines of code.
– A package shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines.
– Application with more than 30 packages should be avoided. Such a subsystem would count up to 900
classes with up to 810,000 lines of code.
Our goal is to keep our overall system small while we are also keeping our functions and classes small.
Remember however that this rule is the lowest priority of the four rules of Simple Design. So, although it’s
important to keep class and function count low, it’s more important to have tests, eliminate duplication, and
express yourself. 14
SQL Usage
• Hikari CP
HikariDataSource dataSource = new HikariDataSource(config);
Connection conn = dataSource.getConnection();
15
SQL Usage
//Wrong Usage
for(int id=1; id<100; id++)
stmt.executeQuery(“SELECT * FROM CUSTOMER WHERE CUST_ID=” + id);
//Correct Usage
stmt = conn.prepareStatement(“SELECT * FROM CUSTOMER WHERE CUST_ID=?”);
for(int id=1; id<100; id++) {
stmt.setInt(1, id); stmt.executeQuery();
}
16
SQL Usage
• SQL Injection
//Wrong Usage
SELECT * FROM CUSTOMER WHERE CUST_ID=” + id); //Hard Parsing
SELECT * FROM CUSTOMER WHERE CUST_ID=” + (1234 + “ OR 1=1) // SQL Injection
//Correct Usage
stmt = conn.prepareStatement(“SELECT * FROM CUSTOMER WHERE CUST_ID=?”);
id=1234 + “ OR 1=1”
stmt.setInt(1, id); stmt.executeQuery();
17
Memory Handling
• Static data (fields and members) are loaded into memory on class loading and remain until the
class is unloaded from memory (typically on JVM termination).
18
Memory Handling
19
Library Usage
• Selecting library
Use only active libraries
Check for library updates
Do Regression testing
• Using library
Don’t prefer download jar method
Use build tools like Maven(https://maven.apache.org/), Graddle (https://gradle.org/)
20
Tools
21
DIGITAL BUSINESS
DEMANDS NEW
ARCHITECTURE
MAKE
Corporate Headquarters
THE
LEAP!
Intense Technologies Limited
A1, Vikrampuri
Secunderabad – 5000 09. Telangana, INDIA
Tel: +91-40-44558585 / 27849019 / 27844551
Fax: +91-40-27819040
e-mail: internationalsales@in10stech.com
Branches
UK | USA | SINGAPORE | UAE
22