RSS Feed for This PostCurrent Article

Java: Coding Guidelines

Here are some simple guidelines I followed for one of the system that I refactored.

Always Program Using the Interface

E.g.

       1: Map<String,String> obj = new HashMap<String,String> 
       2:  
       3: List<String,String obj> = new ArrayList<String,String> 

 

Prefer HashMap over Hashtable, ArrayList over Vector, StringBuilder over StringBuffer

If you really need synchronized access, e.g. for Map, use ConcurrentHashMap, or use the Collections.synchronizedXXX methods

 

Always Use For-Each for JDK1.5 and above

E.g. for Map<String,String> obj

   1: for (String val: obj) { 
   2:  
   3: } 
   4:  

 

Use Apache Commons Package, Don’t Reinvent

Use StringUtils, NumberUtils, DateUtils, etc… if possible.

 

Use Enum instead of Static Constants

With JDK 5, enum is now part of the language features that you make full use.

 

Always Do Unit Test

This one is obvious. Always test using JUnit, TestNG, etc…

 

If Possible, Decouple Business Logic from Technical Framework

This may not be possible all the time, but you should do your best here

 

Always comment on the logic of the program, not just what each line does

 

Always declare your Log object as static.

If your class is an inherited class, then use a single logger that is declared in the parent which is declared as protected

   1: // Logging object 
   2:  
   3: protected static final Log log = LogFactory.getLog(BaseClass.class); 
   4:  

If your class is single, then declared it as private static

   1: // Logging object 
   2:  
   3: private static final Log log = LogFactory.getLog(MyClass.class); 
   4:  

Quoted from SL4J FAQ,

Advantages for declaring loggers as static

  1. common and well-established idiom
  2. less CPU overhead: loggers are retrieved and assigned only once, at hosting class initialization
  3. less memory overhead: logger declaration will consume one reference per class

Disadvantages for declaring loggers as static

  1. For libraries shared between applications, not possible to take advantage of repository selectors. It should be noted that if the SLF4J binding and the underlying API ships with each application (not shared between applications), then each application will still have its own logging environment.
  2. not IOC-friendly

    Advantages for declaring loggers as instance variables

    1. Possible to take advantage of repository selectors even for libraries shared between applications. However, repository selectors only work if the underlying logging system is logback-classic. Repository selectors do not work for the SLF4J+log4j combination.
    2. IOC-friendly

    Disadvantages for declaring loggers as instance variables

    1. Less common idiom than declaring loggers as static variables
    2. higher CPU overhead: loggers are retrieved and assigned for each instance of the hosting class
    3. higher memory overhead: logger declaration will consume one reference per instance of the hosting class


      Trackback URL


      Sorry, comments for this entry are closed at this time.