Best Practices

1
Best Practices

2
Contents

• Bad Practices
• Good Practices

3
Bad Practices
4
Duplicate Code!

• Every time you need to make a change in the
  routine, you need to edit it in several places.
• Called Shotgun Surgery.
• Follow the Once and Only Once rule.
• Dont copy-paste code!

5
Accessible Fields

• Fields should always be private except for
  constants.
• Accessible fields cause tight coupling.
• Accessible fields are corruptible.
• If a field needs to be accessed, use get and
  set convention.

6
Using Magic Numbers

• Magic numbers are not readable, and can lead to
  Shotgun Surgery.
• for (int i 1 i lt 52 i)
• j i randomInt(53 - i) 1
• swapEntries(i, j)
• Replace with constants.
• final int DECKSIZE 52
• for (int i 1 i lt DECKSIZE i)
• j i randomInt(DECKSIZE 1 - i) 1
• swapEntries(i, j)

7
Temporary Fields

• If a variable need not be shared across methods,
  make it local.
• private int x
• int method()
• x 0 // if you forget to initialize, you're
  dead
• ... // do some stuff
• return x
• int method()
• int x 0
• ... // do some stuff
• return x

8
Initializing Strings with new

• Dont
• String str new String(This is bad.)
• Do
• String str This is good.

9
Using floats and doubles for currency calculations

• Binary numbers cannot exactly represent decimals.
• Use BigDecimal for currency calculations.
• ...using the constructor that takes a String as a
  parameter.

10
Returning null

• Causes NullPointerExceptions.
• Instead, return
• empty objects
• custom-made Null Objects

11
(No Transcript)
12
(No Transcript)
13
Subclassing for Functionality

• Implementation inheritance is difficult to debug.
• Ask yourself Is this a kind of?
• Alternatives
• Prefer interface inheritance.
• Prefer composition over inheritance.

14
Empty Catch Block

• No indication that an exception has occurred!

15
Using Exceptions Unexceptionally

• Use exceptions only for exceptional conditions.
• Bad
• try
• obj arrindex
• catch (ArrayIndexOutOfBoundsException)
• // do something
• Good
• if (index lt 0 index gt arr.size())
• // do something
• else
• obj arrindex

16
Excessive Use of Switches

• Use of if and switch statements usually a
  sign of a breach of the One Responsibility
  Rule.
• Consider polymorphism instead.

17
instanceof

• If youre using instanceof often, it probably
  means bad design.
• Consider adding an overridden method in
  supertype.
• instanceof should only be used
• as validation prior to casting
• when you have to used a poorly-written library

18
Static Methods

• Static methods are..
• ...procedural
• They break encapsulation - the method should be
  part of the object that needs it
• ...not polymorphic
• You can't have substitution/pluggability.
• You can't override a static method because the
  implementation is tied to the class it's defined
  in.
• Makes your code rigid, difficult to test.

19
System.exit

• Only use in stand-alone applications.
• For server applications, this might shut down the
  whole application container!

20
Good Practices
21
Validate Your Parameters

• The first lines of code in a method should check
  if the parameters are valid
• void myMethod(String str, int index, Object
  arr)
• if (str null)
• throw new IllegalArgumentException(str
  cannot be null)
• if (index gt arr.size index lt 0)
• throw new IllegalArgumentException(index
  exceeds
• bounds of array)

22
Create Defensive Copies

• Create local copies, to prevent corruption.
• void myMethod (List listParameter)
• List listCopy new ArrayList(listParameter)
• listCopy.add(somevar)
• ...

23
Modify Strings with StringBuilder

• String objects are immutable.
• You may think youre changing a String, but
  youre actually creating a new object.
• Danger of OutOfMemoryErrors.
• Poor peformance.
• StringBuilder is mutable.
• All changes are to the same object.

24
Favor Immutability

• If your objects dont change easier to debug.
• Fields are private and final.
• No setters, only getters.

25
Prefer final for Variables

• Usually, variables / parameters do not need to
  change.
• Get into the habit of using final by default, and
  make a variable not final only when necessary.

26
Declare Variable Just Before Use

• Easier to read and refactor.

27
Initialize Variables Whenever Possible

• Helpful in debugging, makes it clear what initial
  value is.
• Makes sure you dont use the variable before its
  ready for use.

28
Follow Code Conventions

• Improves readability
• For other programmers.
• For yourself.
• Readability means
• less bugs.
• easier to debug.

29
Refer to Objects by Interfaces

• Maintainability - changes in implementation need
  only be done at a single point in code
• Polymorphism implementation can be set at
  runtime.
• // bad
• ArrayList list new ArrayList()
• list.add(somevar)
• // good
• List list new ArrayList()
• list.add(somevar)

30
Consider Using Enums instead of Constants

• Constants
• Not typesafe
• No namespace
• You often need to prefix constants to avoid
  collisions
• Brittleness
• When you change the order, you need to change a
  lot of code.
• Printed values are uninformative

31
Buffer I/O Streams

• Requesting OS for I/O resources is expensive.
• Buffering provides significant increase in
  performance.

32
Close Your I/O Streams

• If you dont close, other applications may not be
  able to use the resource.
• Close using the finally block in a try-catch.

33
Design Close to Domain

• Code is easily traceable if it is close to the
  business it is working for.
• If possible, name and group your packages
  according to the use cases.
• Easy to tell client completion of feature.
• If user reports a bug, easier to find where it is.

34
If You Override equals() Override hashcode()

• Always make sure that when equals() returns true,
  the two object have the same hashcode.
• Otherwise, data structures like Sets and Maps may
  not work.
• There are many IDE plug-ins and external
  libraries that can help you with this.

35
Write Self-Documenting Code

• Comments are important, but
• even without comments your code should be easily
  readable.
• Ask yourself If I removed my comments, can
  someone else still understand my code?

36
Use Javadoc Liberally

• Provide as much documentation about your code as
  possible.

37
Bubble-Up Exceptions

• If code is not part of the user interface, it
  should not handle its own exceptions.
• It should be bubbled-up to presentation layer
• Show a popup?
• Show an error page?
• Show a commandline message?
• Just log to an error log?

38
References

• Effective Java by Joshua Bloch
• Refactoring by Martin Fowler
• http//javapractices.com