Java tutorial do's and don'ts of java programming.

  • 239 views
Uploaded on

Download this..its very useful especially for Java Developers.. :) …

Download this..its very useful especially for Java Developers.. :)

-SKC

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
239
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
14
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Dr Java Workshop – By Satyarth Gaur We will cover the following areas:  - Top 10 mistakes made by Java programmers – How to avoid them    - Core Java- Best Practices – This covers good and bad practices both - How to prepare for Java Interviews and Sun Java Exams
  • 2. Top Ten Errors Java Programmers Make SATYARTH GAUR [email_address]
  • 3. Accessing non-static member variables from static methods (such as main)
    • public class StaticDemo
    • {
    • public String my_member_variable = "somedata";
    • public static void main (String args[])
    • {
    • // Access a non-static member from static method
    • System.out.println ("This generates a compiler error" +
    • my_member_variable );
    • }
    • }
  • 4. Contd..
    • public class NonStaticDemo
    • {
    • public String my_member_variable = "somedata";
    •  
    • public static void main (String args[])
    • {
    • NonStaticDemo demo = new NonStaticDemo();
    •   // Access member variable of demo
    • System.out.println ("This WON'T generate an error" +
    • demo.my_member_variable );
    • }
    • }
  • 5. Mistyping the name of a method when overriding
    • If you mistype the name, you're no longer overriding a method - you're creating an entirely new method, but with the same parameter and return type.
  • 6. Comparison assignment (  = rather than == )
    • Fortunately, even if you don't spot this one by looking at code on the screen, your compiler will. Most commonly, it will report an error message like this : "Can't convert xxx to boolean", where xxx is a Java type that you're assigning instead of comparing.
  • 7. Comparing two objects ( == instead of .equals)
    • When we use the == operator, we are actually comparing two object references, to see if they point to the same object. We cannot compare, for example, two strings for equality, using the == operator. We must instead use the .equals method, which is a method inherited by all classes from java.lang.Object.
    • Ex. String Comparison
    • String abc = "abc"; String def = "def";
    •   // Bad way if ( (abc + def) == "abcdef" ) { ….. }
    • // Good way if ( (abc + def).equals("abcdef") ) { ..... }
  • 8. Confusion over passing by value, and passing by reference
    • When you pass a primitive data type, such as a char, int, float, or double, to a function then you are passing by value . That means that a copy of the data type is duplicated, and passed to the function. That means that a copy of the data type is duplicated, and passed to the function. If the function chooses to modify that value, it will be modifying the copy only.
  • 9. Contd..
    • When you pass a Java object, such as an array, a vector, or a string, to a function then you are passing by reference .So that means that if you pass an object to a function, you are passing a reference to it, not a duplicate. Any changes you make to the object's member variables will be permanent
  • 10. Writing blank exception handlers
    • public static void main(String args[])
    • {
    •     try {
    • // Your code goes here..
    •     }
    •     catch (Exception e)
    •     {
    • System.out.println ("Err - " + e );
    •     }
    • }
  • 11. Forgetting that Java is zero-indexed
    • If you've come from a C/C++ background, you may not find this quite as much a problem as those who have used other languages. In Java, arrays are zero-indexed, meaning that the first element's index is actually 0
  • 12. Example Contd..
    • // Create an array of three strings
    • String[] strArray = new String[3];
    •   // First element's index is actually 0
    • strArray[0] = "First string";
    •   // Second element's index is actually 1
    • strArray[1] = "Second string";
    •   // Final element's index is actually 2
    • strArray[2] = "Third and final string";
  • 13. Preventing concurrent access to shared variables by threads
    • The simplest method is to make your variables private (but you do that already,  right?) and to use synchronized accessor methods. Accessor methods allow access to private member variables, but in a controlled manner. Take the following accessor methods, which provide a safe way to change the value of a counter.
  • 14. Contd..
    • public class MyCounter{
    • private int count = 0; // count starts at zero
    •   public synchronized void setCount(int amount)
    • {
    • count = amount;
    • }
    • public synchronized int getCount()
    • {
    • return count;
    • }
    • }
  • 15. Capitalization errors
    • While there's no silver bullet for detecting this error, you can easily train yourself to make less of them. There's a very simple trick you can learn :-
    • all methods and member variables in the Java API begin with lowercase letters
    • all methods and member variables use capitalization where a new word begins e.g - getDoubleValue()
  • 16. Capitalization errors
    • While there's no silver bullet for detecting this error, you can easily train yourself to make less of them. There's a very simple trick you can learn :-
    • all methods and member variables in the Java API begin with lowercase letters
    • all methods and member variables use capitalization where a new word begins e.g - getDoubleValue()
  • 17. Null pointers
    • When an attempt to access an object is made, and the reference to that object is null, a NullPointerException will be thrown.
    • The cause of null pointers can be varied, but generally it means that either you haven't initialized an object, or you haven't checked the return value of a function.
  • 18. Java Best Practices Java Fundamentals & Object-Oriented Programming Dr Java Boot Camp – Satyarth Gaur
  • 19. Bad Practices
  • 20. Duplicate Code!
    • Every time you need to make a change in the routine, you need to edit it in several places.
    • Don’t copy-paste code!
  • 21. 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.
  • 22. Using Magic Numbers
    • Magic numbers are not readable
        • 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)
        • }
  • 23. 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;
        • }
  • 24. Initializing Strings with “new”
    • Don’t:
    • String str = new String(“This is bad.”);
    • Do:
      • String str = “This is good.”;
  • 25. 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.
  • 26. Returning null
    • Causes NullPointerExceptions.
    • Instead, return…
      • empty objects
      • custom-made “Null Objects”
  • 27.  
  • 28.  
  • 29. Subclassing for Functionality
    • Implementation inheritance is difficult to debug.
    • Ask yourself: “Is this a kind of…?”
    • Alternatives:
      • Prefer interface inheritance.
      • Prefer composition over inheritance.
  • 30. Empty Catch Block
    • No indication that an exception has occurred!
  • 31. 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];
      • }
  • 32. Excessive Use of Switches
    • Use of “if” and “switch” statements usually a sign of a breach of the “One Responsibility Rule”.
    • Consider polymorphism instead.
  • 33. 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
  • 34. 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.
  • 35. System.exit
    • Only use in stand-alone applications.
    • For server applications, this might shut down the whole application container!
  • 36. Good Practices
  • 37. 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”);
      • } …
      • }
  • 38. Create Defensive Copies
    • Create local copies, to prevent corruption.
      • void myMethod (List listParameter) {
        • List listCopy = new ArrayList(listParameter);
        • listCopy.add(somevar);
        • ...
      • }
  • 39. 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.
  • 40. Favor Immutability
    • If your objects don’t change… easier to debug.
    • Fields are private and final.
    • No setters, only getters.
  • 41. 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.
  • 42. Declare Variable Just Before Use
    • Easier to read and refactor.
  • 43. 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.
  • 44. Follow Code Conventions
    • Improves readability
      • For other programmers.
      • For yourself.
    • Readability means…
      • … less bugs.
      • … easier to debug.
  • 45. 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);
  • 46. 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
  • 47. 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.
  • 48. 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.
  • 49. 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.
  • 50. 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?”
  • 51. Use Javadoc Liberally
    • Provide as much documentation about your code as possible.
  • 52. 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?
  • 53. Best Sites for Java Examples,Code Samples,Tutorials and Interview Preparation
    • www. roseindia .net
    • www. vaannila .com
    • www. java2s .com
    • www. javaprepare .com SCJP
  • 54. Contd..
    • www. techinterviews .com
    • http://www.jguru.com
    • www.coderanch.com
    • SCJP 5 /6 By Kathy Sierra -- E book
    • http://javapractices.com