Java: Coding Guidelines
By admin on Sep 16, 2008 in Java, Programming
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
- common and well-established idiom
- less CPU overhead: loggers are retrieved and assigned only once, at hosting class initialization
- less memory overhead: logger declaration will consume one reference per class
Disadvantages for declaring loggers as static
- 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.
- not IOC-friendly
Advantages for declaring loggers as instance variables
- 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.
- IOC-friendly
Disadvantages for declaring loggers as instance variables
- Less common idiom than declaring loggers as static variables
- higher CPU overhead: loggers are retrieved and assigned for each instance of the hosting class
- higher memory overhead: logger declaration will consume one reference per instance of the hosting class
Popularity: 1% [?]
