10 Most Useful Java Best Practice Quotes for Java Developers

Quote 1: Avoid creating unnecessary objects and always prefer to do Lazy Initialization

Object creation in Java is one of the most expensive operation in terms of memory utilization and performance impact. It is thus advisable to create or initialize an object only when it is required in the code.
public class Countries { private List countries; public List getCountries() { //initialize only when required if(null == countries) { countries = new ArrayList(); } return countries; } }
Code language: Java (java)

Quote 2: Never make an instance fields of class public

Making a class field public can cause lot of issues in a program. For instance you may have a class called MyCalender. This class contains an array of String weekdays. You may have assume that this array will always contain 7 names of weekdays. But as this array is public, it may be accessed by anyone. Someone by mistake also may change the value and insert a bug!
public class MyCalender { public String[] weekdays = {"Sun", "Mon", "Tue", "Thu", "Fri", "Sat", "Sun"}; //some code }
Code language: Java (java)
Best approach as many of you already know is to always make the field private and add a getter method to access the elements.
private String[] weekdays = {"Sun", "Mon", "Tue", "Thu", "Fri", "Sat", "Sun"}; public String[] getWeekdays() { return weekdays; }
Code language: Java (java)
But writing getter method does not exactly solve our problem. The array is still accessible. Best way to make it unmodifiable is to return a clone of array instead of array itself. Thus the getter method will be changed to.
public String[] getWeekdays() { return weekdays.clone(); }
Code language: Java (java)

Quote 3: Always try to minimize Mutability of a class

Making a class immutable is to make it unmodifiable. The information the class preserve will stay as it is through out the lifetime of the class. Immutable classes are simple, they are easy to manage. They are thread safe. They makes great building blocks for other objects. However creating immutable objects can hit performance of an app. So always choose wisely if you want your class to be immutable or not. Always try to make a small class with less fields immutable. To make a class immutable you can define its all constructors private and then create a public static method to initialize and object and return it.
public class Employee { private String firstName; private String lastName; //private default constructor private Employee(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } public static Employee valueOf (String firstName, String lastName) { return new Employee(firstName, lastName); } }
Code language: Java (java)

Quote 4: Try to prefer Interfaces instead of Abstract classes

First you can not inherit multiple classes in Java but you can definitely implements multiple interfaces. Its very easy to change the implementation of an existing class and add implementation of one more interface rather then changing full hierarchy of class. Again if you are 100% sure what methods an interface will have, then only start coding that interface. As it is very difficult to add a new method in an existing interface without breaking the code that has already implemented it. On contrary a new method can be easily added in Abstract class without breaking existing functionality.

Quote 5: Always try to limit the scope of Local variable

Local variables are great. But sometimes we may insert some bugs due to copy paste of old code. Minimizing the scope of a local variable makes code more readable, less error prone and also improves the maintainability of the code. Thus, declare a variable only when needed just before its use. Always initialize a local variable upon its declaration. If not possible at least make the local instance assigned null value.

Quote 6: Try to use standard library instead of writing your own from scratch

Writing code is fun. But “do not reinvent the wheel”. It is very advisable to use an existing standard library which is already tested, debugged and used by others. This not only improves the efficiency of programmer but also reduces chances of adding new bugs in your code. Also using a standard library makes code readable and maintainable. For instance Google has just released a new library Google Collections that can be used if you want to add advance collection functionality in your code.

Quote 7: Wherever possible try to use Primitive types instead of Wrapper classes

Wrapper classes are great. But at same time they are slow. Primitive types are just values, whereas Wrapper classes are stores information about complete class. Sometimes a programmer may add bug in the code by using wrapper due to oversight. For example, in below example:
int x = 10; int y = 10; Integer x1 = new Integer(10); Integer y1 = new Integer(10); System.out.println(x == y); System.out.println(x1 == y1);
Code language: Java (java)
The first sop will print true whereas the second one will print false. The problem is when comparing two wrapper class objects we cant use == operator. It will compare the reference of object and not its actual value. Also if you are using a wrapper class object then never forget to initialize it to a default value. As by default all wrapper class objects are initialized to null.
Boolean flag; if(flag == true) { System.out.println("Flag is set"); } else { System.out.println("Flag is not set"); }
Code language: Java (java)
The above code will give a NullPointerException as it tries to box the values before comparing with true and as its null.

Quote 8: Use Strings with utmost care.

Always carefully use Strings in your code. A simple concatenation of strings can reduce performance of program. For example if we concatenate strings using + operator in a for loop then everytime + is used, it creates a new String object. This will affect both memory usage and performance time. Also whenever you want to instantiate a String object, never use its constructor but always instantiate it directly. For example:
//slow instantiation String slow = new String("Yet another string object"); //fast instantiation String fast = "Yet another string object";
Code language: Java (java)

Quote 9: Always return empty Collections and Arrays instead of null

Whenever your method is returning a collection element or an array, always make sure you return empty array/collection and not null. This will save a lot of if else testing for null elements. For instance in below example we have a getter method that returns employee name. If the name is null it simply return blank string “”.
public String getEmployeeName() { return (null==employeeName ? "": employeeName); }
Code language: Java (java)

Quote 10: Defensive copies are savior

Defensive copies are the clone objects created to avoid mutation of an object. For example in below code we have defined a Student class which has a private field birth date that is initialized when the object is constructed.
public class Student { private Date birthDate; public Student(birthDate) { this.birthDate = birthDate; } public Date getBirthDate() { return this.birthDate; } }
Code language: Java (java)
Now we may have some other code that uses the Student object.
public static void main(String []arg) { Date birthDate = new Date(); Student student = new Student(birthDate); birthDate.setYear(2019); System.out.println(student.getBirthDate()); }
Code language: Java (java)
In above code we just created a Student object with some default birthdate. But then we changed the value of year of the birthdate. Thus when we print the birth date, its year was changed to 2019! To avoid such cases, we can use Defensive copies mechanism. Change the constructor of Student class to following.
public Student(birthDate) { this.birthDate = new Date(birthDate); }
Code language: Java (java)
This ensure we have another copy of birthdate that we use in Student class.

Two bonus quotes

Here are two bonus Java best practice quotes for you.

Quote 11: Never let exception come out of finally block

Finally blocks should never have code that throws exception. Always make sure finally clause does not throw exception. If you have some code in finally block that does throw exception, then log the exception properly and never let it come out :)

Quote 12: Never throw “Exception”

Never throw java.lang.Exception directly. It defeats the purpose of using checked Exceptions. Also there is no useful information getting conveyed in caller method.

More Quotes from Java Developers

Do you have a quote that is not included in above list? Well, feel free to add your Java best practice quote using comment below. Write your quote and explain it in 2-3 lines. I will add all those user generated quotes in this section.

Quote #13: Avoid floating point numbers

It is a bad idea to use floating point to try to represent exact quantities like monetary amounts. Using floating point for dollars-and-cents calculations is a recipe for disaster. Floating point numbers are best reserved for values such as measurements, whose values are fundamentally inexact to begin with. For calculations of monetary amounts it is better to use BigDecimal.

View Comments

  • Hey great list...
    Here is one from me.
    Quote #13 Avoid floating point numbers
    It is a bad idea to use floating point to try to represent exact quantities like monetary amounts. Using floating point for dollars-and-cents calculations is a recipe for disaster. Floating point numbers are best reserved for values such as measurements, whose values are fundamentally inexact to begin with. For calculations of monetary amounts it is better to use BigDecimal.

  • I like this list: it might seem simple at first, but it can actually save a lot of troubles down the road.

    Nice work!

    p.s. I think there is a typo in the first sentence of quote 3: I think you meant to say "Making a class immutable is to make it unmodifiable

  • Item 2.

    A better solution would be to return an unmodifiable list rather than an array.

    You have also made some statements about performance re primitive types and strings that might not always be relevant. The JVM and Hotspot does some amazing things these days and as a result some of these statements should be backed up by statistics.

    On our large enterprise project we use concatenation and wrapper objects a lot and they are rarely the source of performance issues. We have used the Netbeans profiler to test them.

    Poor design is by far the biggest problem, for instance; returning primitive types for keys leads to lockin that you may well regret later.

    One more tip is the use of final. We use this where possible on member variables and on all parameters. This has quashed more bugs than anything - especially in the area of cut n paste!

  • >>> Do you have a quote that is not included in above list?
    I think it is done already, e.g. Effective Java Second Edition by by Joshua Bloch or Implementation Patterns by Kent Beck.
    BTW about tips #1 - Lazy Initialization is very bad approach in case of concurrency, you have to synchronize getter for getCountries() while object creation is not so expensive, look at http://www.ibm.com/developerworks/java/library/j-jtp04223.html "The performance impact of object creation, while certainly real, is not as significant in most programs as it once was or is still widely believed to be."

  • Felt motivated reading this. I am a Java developer and i am very eager to create some new, innovative application some day. That is why i am going to attend Sun Tech Days 2010 conference in Hyderabad. Experts are going to share ideas on new technologies there. lets see what happens.

  • Quote 7:
    Why using "Integer x1 = new Integer(10);" anyway... it's the old way, it's slow and it creates a new instance.
    Instead: use "Integer x1 = Integer.valueOf(10);" or use the automatic boxing/unboxing with "Integer x1 = 10;".

    Quote 9:
    The "always" is simply not neccessary.
    Sometimes there is no collection I want return, e.g. in case of error.
    I don't need an exception here nor want I know, why this Collection is null: there was an error and I don't want to work on this list, not even on an empty list.
    Sure, returning null on error needs to be documented in some way. Other way round, always returning a collection/array (even if empty) needs to be documented either.
    I suppose better: "Quote 9: Prefer to return empty Collections and Arrays instead of null"

    "Quote 3" and "Quote 10" correspond to each other, don't they? I think, they describe the same principle on another level.

    "Quote 11": maybe a reference to "apache-commons-io" and "apache-commons-db" would be helpful, since they introduce "DbUtils.closeQuietly(conn/rs/stmt);" and "IOUtils.closeQuietly(reader/stream/etc.);"

Share
Published by
Viral Patel
Tags: Java java class file Java design pattern JVM

Recent Posts

  • Java

Java URL Encoder/Decoder Example

Java URL Encoder/Decoder Example - In this tutorial we will see how to URL encode/decode…

5 years ago
  • General

How to Show Multiple Examples in OpenAPI Spec

Show Multiple Examples in OpenAPI - OpenAPI (aka Swagger) Specifications has become a defecto standard…

5 years ago
  • General

How to Run Local WordPress using Docker

Local WordPress using Docker - Running a local WordPress development environment is crucial for testing…

5 years ago
  • Java

Create and Validate JWT Token in Java using JJWT

1. JWT Token Overview JSON Web Token (JWT) is an open standard defines a compact…

5 years ago
  • Spring Boot

Spring Boot GraphQL Subscription Realtime API

GraphQL Subscription provides a great way of building real-time API. In this tutorial we will…

5 years ago
  • Spring Boot

Spring Boot DynamoDB Integration Test using Testcontainers

1. Overview Spring Boot Webflux DynamoDB Integration tests - In this tutorial we will see…

5 years ago