INFS1609/INFS2609 Coding Style and Design Page 1

Java Programming
Coding Style and Design Considerations
INFS1609 / INFS2609
1. Introdution

The article is to familiarize yourself with basic Java coding styles, which improves readability and
thereby the understanding and maintainability of your code. For a more complete explanation, please
refer to Oracle (un!"s Java coding conventions.

2. !y"ogra"#ial Style $ Program %ayout

2.1 &rgani'e t#e "arts o( your lasses )it# our INFS1609/2609 onvention
#mprove readability by ma$ing the location of each class element predictable. #n addition, include
a program description and the author"s identity in the header section of the main .%ava file.




INFS1609/2609 Lab 1, <program name>
@zNumber
INFS1609/INFS2609 Coding Style and Design Page 2

2.2 *aria+les s#ould +e delared )it# smallest so"e "ossi+le
&eeping the operations on a variable within a small scope, it is easier to control the effects and
side effects of the variables. Furthermore, when reading the program, referring to the type
declaration of the variable is also made easier.
For example,


'ariables should be declared at the point where they first become relevant(


)s another example, loop variables should be declared and initialized immediately before the
loop(


*here there are deeply nested bloc$s, variables which only apply to the inner bloc$(s! should be
declared within, for example(



INFS1609/INFS2609 Coding Style and Design Page 3

+ounter variables of for statements which are not used outside the loop should be declared
within the for statement


2., Delare related varia+les o( t#e same time in a ommon statement
For example,


)s opposed to


2.- .se named onstants /(inal0 (or magi num+ers
)void direct use of magic numbers for those literal constants of special meaning. +onstant
literals which have special meanings should be named and its named identifier should be used in
its place. The exception to this rule is the use of numeric constants in well,defined mathematical
formulas (for instance, -./01ath.2#0r0r!.

3xample(





INFS1609/INFS2609 Coding Style and Design Page 4

2.1 .se onsistent indentation to em"#asi'e +lo2 struture
+ode should be properly and neatly indented to emphasize the nested logical structure of the
program. Following un"s convention, an indentation of - spaces is recommended (4 is too wide
and 5 is too cramp!.

3very method bloc$ and statement bloc$ that follows a for, while, if.else, switch, do.while
statement must be indented from its enclosing bloc$.

+omments within a bloc$ should follow the indentation level of its enclosing bloc$.

For example,


2.6 Comment om"liated logi3 e4"ressions3 or algorit#ms
)n 6if7 bloc$ with a complex condition or an expression that"s hard to understand should have
explanatory comments. For example,


2.5 Comment instane and lass varia+les
#nstance and class variables whose purposes are not immediately clear should be trailed with a
brief comment at its point of declaration(


+ollection variables should have a trailing comment stating the common type of the elements of
the collection(



INFS1609/INFS2609 Coding Style and Design Page 5

2.6 7void su"er(luous omments
) comment such as(


erves no purpose, adds clutter to a program and does more harm than good.

,. !y"ogra"#ial Style $ Identi(iers

,.1 Classes must +e nouns and )ritten in mi4ed ase starting )it# u""erase


8aming convention by un and used by all Java core pac$ages. 9se typographic conventions to
distinguish identifier types.

,.2 8et#ods must +e ver+s and )ritten in mi4ed ase starting )it# lo)erase


8aming convention by un and used by all Java core pac$ages.

,., *aria+le names must +e in mi4ed ase starting )it# lo)erase


8aming convention by un and used by all Java core pac$ages.
,.- Final varia+les /onstants0 must +e all u""erase using undersore to
se"arate )ords


8aming convention by un and used by all Java core pac$ages.

,.1 *aria+les )it# large so"e s#ould #ave desri"tive names
The scope of class and instance variables spans all methods in the class. #t is best to use
descriptive names for them so that their meanings are immediately clear when they appear within
a method. For example, 68ode curr8ode:7 is an appropriate instance variable but not 68ode n:7.
The latter, however, is perfectly appropriate if it is a transient variable (see /.;!.
For a similar reason, class names should also have descriptive names (nouns!.

INFS1609/INFS2609 Coding Style and Design Page 6

,.6 *aria+les )it# s#ort so"e s#ould #ave s#ort names
#n contrast to the above (5.<!, transient variables such as loop counters, temporary references,
iterators etc, should have short and easy to recall names as their usage is fre=uent and their
purpose is usually clear.
For example,


#s much less readable than(


,.5 .se a 9get/set: "re(i4 (or diret aessors and mutators
For example,


,.6 .se a 9is/#as/an/s#ould: "re(i4 (or ;oolean varia+les and met#ods


,.9 7void negated varia+le or met#od names
8egated variables often results in hard,to,read double,negatives in an expression li$e >is8ot3rror.




INFS1609/INFS2609 Coding Style and Design Page 7

,.10 <4e"tion lasses s#ould +e su((i4ed +y <4e"tion
This convention is the standard in un"s Java core pac$ages.


-. Design Considerations

)s programs get more complex, program design becomes increasingly important. ?ecomposing a
complex program into smaller, more manageable units and the design of the interfaces between the
units are fundamental to good programming. @enerally, the constituents of a program unit should
be highly cohesive (-.A!, and the coupling between program units should be clean and minimal (-.5!.
)lgorithmic logic should be easy to understand (-./!. The program should also be easy to setup and
its usage should be intuitive.
-.1 ;uild "rogram units )#i# are #ig#ly o#esive
3ach method or class should consist of closely related elements. #f a class or method consists of a
mixed,bag of unrelated elements, it often indicates a need to modularize the code into further
cohesive program units.
)s a general rule, each function.method should do only one thing. This should be done so that the
conceptual unit can be understood easily. ometimes it will be convenient to do two things in a
function because youBre wor$ing on the same data. Try to resist this temptation. 1a$e two functions
if you reasonably can.
Often the naming of the method indicates its cohesiveness. ?oes the method only do what its name
says, or does it do more than thatC #f you find that a complete name for one of your method is li$e
open#nput)ndDead'ector)nd+omputeum(..!, it is time to brea$ the multitas$ed method into sub,
constituents.
egments of code which are repeated should be abstracted into a method. This not only results in
shorter programs but also ma$es it easier to maintain and read. The abstracted method then forms a
cohesive unit by itself.
-.2 7void tig#t ou"ling +et)een "rogram units
#f changing one class in your program re=uires changing another class, then a coupling exists
between the two classes. One indicator of program =uality is the amount of coupling between your
program units.
INFS1609/INFS2609 Coding Style and Design Page 8


+oupling indicates a dependency between source codes. Deducing this dependency improves the
=uality and maintainability of your program. #f your application consists of more than one class,
some coupling must exists:otherwise the ob%ects canBt communicate with one another. The rule of
thumb in building Java programs with multiple classes is for each class to provide a minimal and
well,defined set of public methods while limiting the accessibility of everything else (using the
private modifier!.
-., 7void .nneessarily om"liated logi
implicity is a virtue. *herever possible, your program should be sim"le3 om"at3 and easy to
read. For example, long chains of nested if.else statements can often be replaced with a more
compact form for evaluating the logic. #f you find that the logic in your code is getting very unwieldy,
rethin$ and rewrite it.
-.- .se o( ina""ro"riate synta4 or data ty"es
For instance, if all the inputs to a problem are integers, the program should refrain from introducing
any variables of floating,point type. imilarly, it should refrain from invo$ing any methods which
involve floating,point types.
Other examples including using while instead of for when the number of iterations is easily
determined before the loop.