'TIMER' Rule For Java Coding - Guidelines

'TIMER' rules for Coding

Poor coding has always been nightmare for the project managers and development managers who are wholly resoponsible for the code delivery and are owners of the same.for many years there has been attempts made to educate the developer to follow the coding standards etc, but practically the coding standards in almost 70% of companies still stand the same. I hereby try to present rules that can be easily remembered by a developer while the person is doing the coding and can eventually check his code before delivery.

T – Testable Code
Code should always be delivered in a way its easily testable. By Testable i mean is ,the code should be in written or best say should be fragmented in such a way that a small piece of code should deliver a specific functionality. Few points to remember for writing a good testable code are

• Avoid usage of numerous static variables in your application.
• Avoid usage of global variables which share the stage throughtout the application.
• Avoid heavy constructors ( constructors should always be light).
• Avoid too much functionality in one method. Always try and break it into meaningful methods.
• Use patterns like Value Objects, Service Objects etc to make the code easily testable.

I – Easily Integrated Code
Integration has alwasy been on cards for huge enterprise level application. So writing code that can be easily integrated in any application has been gaining priority over tightly coupled codes. Here are few points to remember while making you code easily integreable.

• Using well thought interfaces whenever possible,which will facilitate connection of other classes and subsystems
• try to avoid too many versions of code , repetitive code and tight coupling.
• Usage of software as a service concept whereever possible.

M – Maintainable & Manageable Code
Maintainablitly of code in an application is a very important apsect and cannot be overlooked. A well maintained and flexible code is heart of the application. Here are some points which everyone should consider using it.

• Usage of constants instead of hardcoding string literals etc
• Using a appropirate framework in accordance with your requirement, not heavliy loading you application with unwanted libraries etc.
• Importing only the packages that are used in the program and not importing everything for e.g. Importing Math.* class when you only want a Decimal.
• Usage of common design patterns which are not complex and easily understood.
• Always remember to destroy or garbage collect and object when its no more used.Always think in terms of 'objects' rather than 'classes'.
• Logging is always better to be used, but its generally not a good practice to log everything, I mean only log things that would help you to troubleshoot.

E – Extendable Code
Extensibility should not be understood as expandability. Extensiblitly essentially means changing the software / code with minimal or no changes to the existing codebase. Truly extendable code is difficult to be developed, but following points can be adopted for the same.

• Best example of extendable code is to use Factory and Bridge Patterns whereever applicable.
• By using Inversion of Control and Dependency Injection principles
• By Aspect Oriented Programming concepts.
• By using ORM Layer while designing applications
• By using Service Provide Interfaces whereever applicable.

R – Readable Code

By far, the most common requirement for coding is its readability. A fairly complex code with no readabiltiy features would create a sorry figure for the managers and new developers who will work on the same code in near future. Following point would minimize this risk.

• Properly formatted , indented code , generally all modern IDE's are equipped with this feature.
• Properly commented variables, methods and classes with 'to-the-point' descriptions of each would make developer's life easy.
• Following general coding standards would surely help, IDE's are at your help.
• Don't cut and paste another user's code without knowing your exact functionality
• judicious usage of return statments, omit unnecessary return statments
• always catch meaningful exceptions
• Coments are always good, but obvious comments should be ignored, for instance there should't be any comments for getter/setter's.
• Don't try and repeat the same code , try to reuse it by making it as a separate method etc.
• Folders/Packages should also have meaningful names and hierrachy.