MELJUN CORTES Java Lecture Best Practices

349 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
349
On SlideShare
0
From Embeds
0
Number of Embeds
1
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

×