Best Practices In

Enterprise Applications

Prepared

By

Chandra Sekhar

GOALTo Implement Best Practices in the End to End processes of the Software Development Life Cycle (SDLC).

Hierarchical Classification

Performance Tuning Follow an Iterative, Data driven and Top-

Down Methodological Approach. Identifying System level, Application Level

and Machine (Middle Layer, Platform Layer) Level.

Identifying Resource leaks, memory misuse, aggressive caches, and improperly scoped user data

Process Level Classification

Best PracticesBest Practices

Coding Coding DesignDesign ArchitectureArchitectureApplication

Server Management

Application Server

ManagementMethodologyMethodology

Best Practices in Coding

General Guide Lines.. Web Layer.. (JSP, Servlets, Configuration of the

various Frameworks..) Business Layer..(EJB, Business Components,

POJOs, Spring..) Data Access Layer.. (DAOs, Hibernate

Framework, ORM Models ) ASP and its Associate Components.

General Guide Lines-I Avoid writing very long methods. A method should

typically have 1~25 lines of code. (For more than 25 lines refactor into separate methods ).

Method Name and Signature should tell its Usage and scope. Avoid Misleading method names.

Look at the method as micro operations . A method should do only one job. Do not combine more than one job in a single method, even if those jobs are very small.

Always watch for unexpected values while making certain validations with conditional operators..

General Guide Lines-2 Avoid Hard Coding Constants. Declare constants in a config

file or an interface and make them private static and final variables.

Avoid Hard coding Strings. Use them from Application Resources( which is a *.properties file).

Avoid sharing the class variables between various methods as it would be unknown where it got changed. Use instance variables and return them appropriately.

Do not make the member ( class) variables public or protected. Keep them private and expose public/protected Properties.

General Guide Lines-3 The event handler should not contain the code to perform

the required action. Rather call another method from the event handler. (ASP.NET, STRUTS solves the problem)

Never hardcode a path or drive name in code. Get the application path programmatically and use relative path.

In the application start up, do some kind of "self check" and ensure all required files and dependencies are available in the expected locations.

Check for database connection in start up, if required. Give a friendly message to the user in case of any problems.

General Guide Lines-4 Error Messages should be user friendly, which makes the

user understand to take next step. There should be a Guide line in the Error Message Thrown.

Do not have more than one class in a single file. (Avoid Inner Classes - Applies to the Business Components only and not to the Framework Components).

Avoid having very large files. If a single file has more than 1000 lines of code, it is a good candidate for refactoring. Split them logically into two or more classes. (Eases the Class Loading Principle..)

Avoid passing too many parameters. Try for a collection object ,class or structure if it requires so.

General Guide Lines-5 Allow returning a Empty Collection Instead of Returning

null from a method. It eases checking for the count. Use the AssemblyInfo (Declaration Comments) file to fill

information like version number, description, company name, copyright notice etc.

Proper Organization of the Folder Structure . By maintaining at least a 2 fold Hierarchy.

Code to ensure Proper Logging mechanism, which shows you exception messages, traces with date and time Identification.

General Guide Lines-6 Better Usage Of Regular Expressions (java.util.regex ) will

enable you to Avoid Iteration on Characters of the String.. This avoids Memory Leaks also..

Code to identify the expression and evaluate to validate the Input.( E.g.: e-mail, panNo, A/c Number, Any kind of Pattern which have Numbers, Special Characters and Characters)

Do not write comments for every line of code and every variable declared.

Use Check Style Component for having a proper Indentation, proper declaration.

Avoid code Synchronization if not necessary, this may lock the Objects under the monitor Control.

General Guide Lines-7 Use try-catch in your data layer to catch all database

exceptions. This exception handler should record all exceptions from the database include the name of the command being executed, stored proc name, parameters, connection string used etc.

Never do a 'catch exception and do nothing'. Always try to avoid exceptions by checking all the error conditions programmatically.

Avoid coding large try catch blocks which, split the code into small try catch blocks, if there are multiple exceptions at a specific place in the code.

Code your own Custom Exceptions for the framework. Do not derive Custom Exceptions from Base Exception. Instead Inherit from Application Exception.

Indentation And Spacing-1 Use TAB for indentation. Do not use SPACES. Define the

Tab size as 4. Comments should be in the same level as the code (use the

same level of indentation). // Format a message and display

string fullMessage = "Hello " + name;

DateTime currentTime = DateTime.Now;

string message = fullMessage + ", the time is : " + currentTime.ToShortTimeString();

messageBox.Show ( message );

Curly braces ( {} ) should be in the same level as the code outside the braces.

Use one blank line to separate logical groups of code.

Indentation And Spacing-2 There should be one and only one single blank line between

each method inside the class. The curly braces should be on a separate line and not in the

same line as if, for etc. Use a single space before and after each operator and

brackets. Grouping the related code Will help you read the methods as

per their Signatures.

General Guide Lines-8

Code Reviews

Code Reviews

Peer Review Architect Review Group Review

Code Reviews-2 Peer Review: Adhering to

Standards and best Practices in Coding, another Team Member can review the code. Also Includes Unit-Testing cases.

Architect Review: Core Modules of the Project should be reviewed by the Architect to ensure that they adhere to the design

Group Review : • Randomly pick up a file• Distribute them to the team and

read them for 30 min• Go through every section of the

code and get the suggestions from the team for better way of coding..

• Do not Forget to Appreciate the Developer While Doing So

Architect Review

Group Review

Peer Review

ConclusionThis Presentation pertains to the General Coding

Guide Lines for all Technologies.