Top TEN Tips for code reusability, maintainability, and flexibility

Top TEN Tips for code reusability, maintainability, and flexibility

Writing a product is not an overnight job. It is the practice of implementing combination of the identified requirements in field and interest of field in future. Successfull product needs several processes, which are enforced from the one liner requirement to the completion of the product. The process are evolved and fine-tuned to improvise the quality and user experience. Product developers has to focus on the best practices in coding which avoid surprises in customer environment.

Development time – An individual has to love, to write more code. Optimization (Code coverage) time - An individual has to hate the code written already.

Reusability, Maintainability, and Flexibility are the major key factors to keep the product stable and long-lived.

1. If happened to type same set of lines again , please move them to new method.

2. If same set of lines exist already in a method, wanted to reuse it, please move that piece of code to new method. And , existing piece of lines has to be removed and new method has to be get called.

3. If found new method may be used by other classes, and found as utility API, then it has to be moved to necessary class with 'public static' access.

4. If Double quoted string needs to be used in the code and found it may be required to capture in other classes too, then create a class field(constant)with 'public static final' access. Where field name keeping in UPPERCASE would be good.

5. Writing method with approx 1000 lines with hundreds of local variable , will perform slower than splitting into 10 to 15 methods with hundreds of local variable. In addition, it helps to improve the code readability and reusability. Methods needs to be very precise to do particular task as per name of the method. For instance, method name is purge(), then collecting or filtering purgeable data logic has to be placed in other methods. In this method, only purge logic such as API calls to purge or transaction API calls can be written.

6. JUNIT testcases has to be added to test negative usecase where incorrect values for the argument get passed, and positive test has to be done by passing possible values. This helps to cover and confirm , possible values for the arguments. And, regression bugs will be avoided more than 99 percentage.

7. In J2EE application, maintaining the actual business implementation away from the EJB methods would be good. EJB methods has to act like deligate method and calls the method which has actual implementation in other class. This business implementation may be reused in WS, JMS and/or other J2EE technology.

8. In an application, a JAVA Class has to be introduced to keep only rt.jar based utilities ( public APIs). These APIs can be used by application , or developer for testing dirctly without associating any other jars from the dependency components.

9. Utility methods needs to have JAVA Doc comments with @author . Whenever the method gets modified by other developer, it is easy to cross check with the developer.

10. Dependency component's jar/classes has to be accessed through a single class(Wrapper around the component). If depedency component usage is more then a package can be introduced to deal with that component.