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. Don’t 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 =< 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. 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” Don’t: 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”

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 = arr[index]; } catch (ArrayIndexOutOfBoundsException) { // do something } Good: if (index = arr.size()) { // do something } else { obj = arr[index]; }

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 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

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 >= arr.size || index < 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 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.

24. Favor Immutability If your objects don’t 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 don’t use the variable before it’s 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 don’t 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