1. Best Practices
In
Enterprise Applications
Prepared
By
Chandra Sekhar

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

3. Hierarchical Classification

4. 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

5. Process Level Classification
Best Practices
Best Practices
Application
Application
Coding
Coding Design
Design Architecture
Architecture Server
Server Methodology
Methodology
Management
Management

6. 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.

7. 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..

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. General Guide Lines-8

17. Code Reviews
Code Reviews
Peer Review Architect Review Group Review

18. 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 Peer Architect
the Project should be reviewed by Review Review
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 Group
from the team for better way of Review
coding..
• Do not Forget to Appreciate the
Developer While Doing So

19. Conclusion
This Presentation pertains to the General Coding
Guide Lines for all Technologies.