GTU Guidelines for Project on JAVA

Friday,October4,2013TOPSTechnologies-JavaTutorial
1 TOPS Technologies – Java Introductory
Tutorial
http://www.tops-int.com/
GTU
GUIDELINE
S FOR
PROJECT
ON JAVA

WHY CODING STANDARDS ARE
IMPORTANT??
• Coding standards for Java are important because they lead to
greater consistency within code of all developers. Consistency leads
to code that is easier to understand, which in turn results in a code,
which is easier to develop and maintain. Code that is difficult to
understand and maintain runs the risk of being scrapped and
rewritten.
• The Prime Directive
• A project requirement may vary from the standards mentioned in this
document. When going against the standards, projects should make
sure to document it.
Friday,October4,2013
2
TOPSTechnologies-JavaTutorial

1. NAMING CONVENTION
• Use full English descriptors that accurately describe the
variable/field/class/interface
• For example, use names like firstName, grandTotal, or
CorporateCustomer.
• Use terminology applicable to the domain
• If the users of the system refer to their clients as Customer,
then use the term Customer for the class, not client.
 Use mixed case to make names readable
 Use abbreviations sparingly, but if you do so then use then
intelligently and document it
 For example, to use a short form for the word “number”,
choose one of nbr, no or num.
 Avoid long names (<15 characters is a good tradeoff)
 Avoid names that are similar or differ only in case
3

2. DOCUMENTATION
• Comments should add to the clarity of code.
• Avoid decoration, i.e., do not use banner-like
comments
• Document why something is being done, not just
what.
• Java Comments
4

JAVA COMMENTS
Comment Type Usage Example
Documentation
Starts with /** and
ends with */
Used before
declarations of
interfaces, classes,
member functions,
and fields to
document them.
/**
* Customer – a
person or
* organization
*/
C style
Starts with /* and
ends with */
Used to document
out lines of code that
are no longer
applicable. It is
helpful in debugging.
/*
This code was
commented out by
Ashish Sarin
*/
Single line
Starts with // and go
until the end of the
line
Used internally within
member functions to
document business
logic, sections of
code, and
declarations of
temporary variables.
// If the amount is
greater
// than 10 multiply by
100
5

3. STANDARDS FOR MEMBER
FUNCTIONS
• 1 Naming member functions
• Member functions should be named using a full English
description, using mixed case with the first letter of any non-
initial word capitalized. The first word of the member function
should be a verb.
• Examples
• openAccount()
• printMailingList()
• save()
• delete()
• This results in member functions whose purpose can be
determined just by looking at its name.
6

3.1.1 NAMING ACCESSOR MEMBER
FUNCTIONS
• 3.1.1.1 Getters: member functions that return the
value of a field / attribute / property of an object.
• Use prefix “get” to the name of the field / attribute /
property if the field in not boolean
• Use prefix “is” to the name of the field / attribute /
property if the field is Boolean
• A viable alternative is to use the prefix ‘has’ or ‘can’
instead of ‘is’ for boolean getters.
• Examples
• getFirstName()
• isPersistent()
7

• 3.1.1.2 Setters: member functions that modify
the values of a field.
• Use prefix ‘set’ to the name of the field.
• Examples
• setFirstName()
• 3.1.1.3 Constructors: member functions that
perform any necessary initialization when an
object is created. Constructors are always given
the same name as their class.
• Examples
• Customer()
• SavingsAccount()
8

3.2 MEMBER FUNCTION VISIBILITY
• A good design requires minimum coupling between
the classes. The general rule is to be as restrictive
as possible when setting the visibility of a member
function. If member function doesn’t have to be
public then make it protected, and if it doesn’t have
to be protected than make it private.
9

• Techniques for Writing Clean Code:
• Document the code Already discussed above
• Paragraph/Indent the code: Any code between the { and } should be properly
indented
• Paragraph and punctuate multi-line statements
• Example
• Line 1 BankAccount newPersonalAccount =
AccountFactory
• Line 2 createBankAccountFor(currentCustomer, startDate,
• Line 3 initialDeposit, branch)
• Lines 2 & 3 have been indented by one unit (horizontal tab)
• Use white space
• A few blank lines or spaces can help make the code more readable.
• Single blank lines to separate logical groups of code, such as control
structures
• Two blank lines to separate member function definitions
• Specify the order of Operations: Use extra parenthesis to increase the
readability of the code using AND and OR comparisons. This facilitates in
identifying the exact order of operations in the code
• Write short, single command lines Code should do one operation per line So
only one statement should be there per line
10

6.0 STANDARDS FOR LOCAL
VARIABLES
• 6.1 Naming Local Variables
• 6.1.1 Naming Streams
• 6.1.2 Naming Loop Counters
• 6.1.3 Naming Exception Objects
• 6.2 Declaring and Documenting Local Variables
• Note
• Reusing local variables is more efficient because
less memory needs to be allocated, but reusing
local variables decreases the maintainability of
code and makes it more fragile
11

7.0 STANDARDS FOR PARAMETERS
(ARGUMENTS) TO MEMBER
FUNCTIONS
 7.1 Naming Parameters
 Parameters should be named following the exact
same conventions as for local variable
 7.2 Documenting Parameters
 Parameters to a member function are documented
in the header documentation for the member
function using the javadoc @param tag. It should
describe:
 What it should be used for
 Any restrictions or preconditions
12

• 8.0 Standards for Classes
• 8.1 Class Visibility
• Use package visibility for classes internal to a
component
• Use public visibility for the façade of components
• 8.2 Naming classes
• Use full English descriptor starting with the first
letter capitalized using mixed case for the rest of
the name
• 8.3 Documenting a Class
13
[1]
Java Coding Standards

Packages The prefix of a unique package name
is always written in all-lowercase
ASCII letters and should be one of the
top-level domain names, currently
com, edu, gov, mil, net, org, or one of
the English two-letter codes
identifying countries as specified in
ISO Standard 3166, 1981.
Subsequent components of the
package name vary according to an
organization's own internal naming
conventions. Such conventions might
specify that certain directory name
components be division, department,
project, machine, or login names.
com.sun.eng
com.apple.quicktim
e.v2
edu.cmu.cs.bovik.c
heese
Classes Class names should be nouns, in mixed
case with the first letter of each internal
word capitalized. Try to keep your class
names simple and descriptive. Use whole
words-avoid acronyms and abbreviations
(unless the abbreviation is much more
widely used than the long form, such as
URL or HTML).
class Raster;
class ImageSprite;
14

Identifier Type Rules for Naming Examples
Interfaces Interface names should
be capitalized like class
names.
interface
RasterDelegate;
interface Storing;
Methods Methods should be
verbs, in mixed case
with the first letter
lowercase, with the first
letter of each internal
word capitalized.
run();
runFast();
getBackground();
15

class constants are in mixed case with a
lowercase first letter. Internal words start with
capital letters. Variable names should not start
with underscore _ or dollar sign $ characters,
even though both are allowed.
Variable names should be short yet meaningful.
The choice of a variable name should be
mnemonic- that is, designed to indicate to the
casual observer the intent of its use. One-
character variable names should be avoided
except for temporary "throwaway" variables.
Common names for temporary variables are i, j,
k, m, and n for integers; c, d, and e for
characters.
char c;
float
myWidth;
Constants The names of variables declared class constants
and of ANSI constants should be all uppercase with
words separated by underscores ("_"). (ANSI
constants should be avoided, for ease of
debugging.)
static final int
MIN_WIDTH =
4;
static final int
MAX_WIDTH =
999;
static final int
GET_THE_CPU
= 1;
16

AND MORE QUESTION ANSWER AND
INTERVIEW TRAINING AND PRACTICE AT
TOPS TECHNOLOGIES
 BIO:
 http://www.tops-int.com/
 http://www.tops-int.com/java-training-course.html
 Visit nearest center of your city
 TOPS Technologies Mehsana
 30, Rajendra estate,
Opp. Gayatri temple, Highway,
Mehsana.
76000 09613
17

18

GTU Guidelines for Project on JAVA

More Related Content

What's hot (20)

Similar to GTU Guidelines for Project on JAVA (20)

More from TOPS Technologies (20)

Recently uploaded (20)

GTU Guidelines for Project on JAVA