java tutorial- do's and don'ts of java programming

Post on 26-May-2015

1.601 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Whether you program regularly in Java, and know it like the back of your hand, or whether you’re new to the language or a casual programmer, you’ll make mistakes. The purpose of this webinar is to talk about some Do's and Don'ts of Java programming. The webinar 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- Q&A Key learnings from this webinar: - It will benefit both junior and senior java professionals so that they don’t make common errors- Clarity of concepts of Java- Better awareness of best practices of Java

TRANSCRIPT

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

Top Ten Errors Java Programmers Make

SATYARTH GAURsatyarthgaur@gmail.com

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 ); } }

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 ); }}

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.

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.

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") ) { ..... }

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.

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

Writing blank exception handlers public static void main(String args[])

{    try {

// Your code goes here..    }    catch (Exception e)    {

System.out.println ("Err - " + e );    }

}

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

Example Contd.. // Create an array of three stringsString[] strArray = new String[3]; // First element's index is actually 0strArray[0] = "First string"; // Second element's index is actually 1strArray[1] = "Second string"; // Final element's index is actually 2strArray[2] = "Third and final string";

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.

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

}

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

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

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.

Java Best Practices

Java Fundamentals &Java Fundamentals &Object-Oriented ProgrammingObject-Oriented Programming

Dr Java Boot Camp – Satyarth GaurDr Java Boot Camp – Satyarth Gaur

Bad PracticesBad Practices

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!

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.

Using Magic Numbers

Magic numbers are not readablefor (int i = 1; i =< 52; i++) {

j = i + randomInt(53 - i) – 1swapEntries(i, j)

} Replace with constants.

final int DECKSIZE = 52;for (int i = 1; i =< DECKSIZE; i++) {

j = i + randomInt(DECKSIZE + 1 - i) – 1swapEntries(i, j)

}

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 stuffreturn x;

}

int method() {int x = 0;... // do some stuffreturn x;

}

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 for currency calculations. ...using the constructor that

takes a String as a parameter.

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…?”

Alternatives: Prefer interface inheritance. Prefer composition over

inheritance.

Empty Catch Block

No indication that an exception has occurred!

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];}

Excessive Use of Switches

Use of “if” and “switch” statements usually a sign of a breach of the “One Responsibility Rule”.

Consider polymorphism instead.

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

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.

System.exit

Only use in stand-alone applications.

For server applications, this might shut down the whole application container!

Good PracticesGood Practices

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”);

} …}

Create Defensive Copies

Create local copies, to prevent corruption.

void myMethod (List listParameter) {List listCopy = new ArrayList(listParameter);

listCopy.add(somevar);...

}

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.

Favor Immutability

If your objects don’t change… easier to debug.

Fields are private and final. No setters, only getters.

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.

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’t use the variable before it’s ready for use.

Follow Code Conventions

Improves readability For other programmers. For yourself.

Readability means… …less bugs. …easier to debug.

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

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

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.

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.

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.

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

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 bubbled-up to presentation layer…

Show a popup? Show an error page? Show a commandline message? Just log to an error log?

Best Sites for Java Examples,Code Samples,Tutorials and Interview Preparation www.roseindia.net

www.vaannila.com

www.java2s.com

www.javaprepare.com SCJP

Contd.. www.techinterviews.com http://www.jguru.com

www.coderanch.com

SCJP 5 /6 By Kathy Sierra -- E book http://javapractices.com

top related