Java
Best
Pr actices

MELJUN CORTES

Java Fundamentals &
Object-Oriented Programming
The Complete Java Boot Camp

MELJUN C...
Contents
 Bad Practices
 Good Practices
Bad
Practices
Duplicate Code!
• Every time you need to make a change in the
routine, you need to edit it in several places.

– Called “S...
Accessible Fields
 Fields should always be private except for

constants.

 Accessible fields cause tight coupling.
 Ac...
Using Magic Numbers
 Magic numbers are not readable, and can lead to

“Shotgun Surgery”.

for (int i = 1; i =< 52; i++) {...
Temporary Fields
 If a variable need not be shared across methods,

make it local.

private int x;
int method() {
x = 0;
...
Initializing Strings with “new”
 Don’t:

String str = new String(“This is bad.”);
 Do:

String str = “This is good.”;
Using floats and doubles for
currency calculations
 Binary numbers cannot exactly

represent decimals.

 Use BigDecimal ...
Returning null
 Causes NullPointerExceptions.
 Instead, return…
 empty

objects

 custom-made

“Null Objects”
Subclassing for Functionality
 Implementation inheritance is difficult

to debug.

 Ask yourself: “Is this a kind of…?”
...
Empty Catch Block

 No indication that an exception

has occurred!
Using Exceptions
Unexceptionally
 Use exceptions only for exceptional

conditions.

 Bad:
try {
obj = arr[index];
} catc...
Excessive Use of Switches

 Use of “if” and “switch” statements

usually a sign of a breach of the
“One Responsibility Ru...
instanceof
 If you’re using instanceof often, it

probably means bad design.
 Consider adding an overridden method in
su...
Static Methods
 Static methods are..
 ...procedural


They break encapsulation - the method
should be part of the objec...
System.exit
 Only use in stand-alone applications.
 For server applications, this might shut

down the whole application...
Good
Practices
Validate Your
Parameters
 The first lines of code in a method should check if

the parameters are valid:

void myMethod(S...
Create Defensive Copies
 Create local copies, to prevent

corruption.

void myMethod (List listParameter) {
List listCopy...
Modify Strings with
StringBuilder
 String objects are immutable.
 You may think you’re changing a
String, but you’re act...
Favor Immutability
 If your objects don’t change… easier

to debug.

 Fields are private and final.
 No setters, only g...
Prefer “final” for Variables
 Usually, variables / parameters do not

need to change.
 Get into the habit of using final...
Declare Variable Just
Before Use
 Easier to read and refactor.
Initialize Variables
Whenever Possible
 Helpful in debugging, makes it clear what

initial value is.
 Makes sure you don...
Follow Code Conventions
 Improves readability
 For

other programmers.

 For

yourself.

 Readability means…
 …less

...
Refer to Objects by Interfaces
 Maintainability - changes in implementation need

only be done at a single point in code
...
Consider Using Enums instead
of Constants
 Constants:
 Not typesafe
 No namespace


You often need to prefix constants...
Buffer I/O Streams
 Requesting OS for I/O resources is

expensive.
 Buffering provides significant increase in
performan...
Close Your I/O Streams
 If you don’t close, other applications may

not be able to use the resource.
 Close using the “f...
Design Close to Domain
 Code is easily traceable if it is close to the

business it is working for.
 If possible, name a...
If You Override equals()
Override hashcode()
 Always make sure that when equals()

returns true, the two object have the ...
Write Self-Documenting Code
 Comments are important, but…
 …even without comments your code

should be easily readable.
...
Use Javadoc Liberally
 Provide as much documentation about

your code as possible.
Bubble-Up Exceptions
 If code is not part of the user interface, it

should not handle its own exceptions.
 It should be...
References
 “Effective Java” by Joshua Bloch
 Refactoring by Martin Fowler
 http://javapractices.com
MELJUN CORTES Java Lecture Best Practices
MELJUN CORTES Java Lecture Best Practices
Upcoming SlideShare
Loading in …5
×

MELJUN CORTES Java Lecture Best Practices

290 views
187 views

Published on

MELJUN CORTES Java Lecture Best Practices

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
290
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

MELJUN CORTES Java Lecture Best Practices

  1. 1. Java Best Pr actices MELJUN CORTES Java Fundamentals & Object-Oriented Programming The Complete Java Boot Camp MELJUN CORTES
  2. 2. Contents  Bad Practices  Good Practices
  3. 3. Bad Practices
  4. 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. • Don’t copy-paste code!
  5. 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. 6. Using Magic Numbers  Magic numbers are not readable, and can lead to “Shotgun Surgery”. for (int i = 1; i =< 52; i++) { j = i + randomInt(53 - i) – 1 swapEntries(i, j) }  Replace with constants. final int DECKSIZE = 52; for (int i = 1; i =< DECKSIZE; i++) { j = i + randomInt(DECKSIZE + 1 - i) – 1 swapEntries(i, j) }
  7. 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. 8. Initializing Strings with “new”  Don’t: String str = new String(“This is bad.”);  Do: String str = “This is good.”;
  9. 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. 10. Returning null  Causes NullPointerExceptions.  Instead, return…  empty objects  custom-made “Null Objects”
  11. 11. Subclassing for Functionality  Implementation inheritance is difficult to debug.  Ask yourself: “Is this a kind of…?”  Alternatives:  Prefer interface inheritance.  Prefer composition over inheritance.
  12. 12. Empty Catch Block  No indication that an exception has occurred!
  13. 13. Using Exceptions Unexceptionally  Use exceptions only for exceptional conditions.  Bad: try { obj = arr[index]; } catch (ArrayIndexOutOfBoundsException) { // do something }  Good: if (index < 0 || index >= arr.size()) { // do something } else { obj = arr[index]; }
  14. 14. Excessive Use of Switches  Use of “if” and “switch” statements usually a sign of a breach of the “One Responsibility Rule”.  Consider polymorphism instead.
  15. 15. instanceof  If you’re 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 
  16. 16. 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.
  17. 17. System.exit  Only use in stand-alone applications.  For server applications, this might shut down the whole application container!
  18. 18. Good Practices
  19. 19. 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 >= arr.size || index < 0) { throw new IllegalArgumentException(“index exceeds bounds of array”); } … }
  20. 20. Create Defensive Copies  Create local copies, to prevent corruption. void myMethod (List listParameter) { List listCopy = new ArrayList(listParameter); listCopy.add(somevar); ... }
  21. 21. Modify Strings with StringBuilder  String objects are immutable.  You may think you’re changing a String, but you’re actually creating a new object.  Danger of OutOfMemoryErrors.  Poor peformance.  StringBuilder is mutable.  All changes are to the same object.
  22. 22. Favor Immutability  If your objects don’t change… easier to debug.  Fields are private and final.  No setters, only getters.
  23. 23. 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.
  24. 24. Declare Variable Just Before Use  Easier to read and refactor.
  25. 25. Initialize Variables Whenever Possible  Helpful in debugging, makes it clear what initial value is.  Makes sure you don’t use the variable before it’s ready for use.
  26. 26. Follow Code Conventions  Improves readability  For other programmers.  For yourself.  Readability means…  …less bugs.  …easier to debug.
  27. 27. 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);
  28. 28. 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
  29. 29. Buffer I/O Streams  Requesting OS for I/O resources is expensive.  Buffering provides significant increase in performance.
  30. 30. Close Your I/O Streams  If you don’t close, other applications may not be able to use the resource.  Close using the “finally” block in a trycatch.
  31. 31. 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. 
  32. 32. 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.
  33. 33. 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?”
  34. 34. Use Javadoc Liberally  Provide as much documentation about your code as possible.
  35. 35. 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?
  36. 36. References  “Effective Java” by Joshua Bloch  Refactoring by Martin Fowler  http://javapractices.com

×