Software development best practices & coding guidelines. How to write maintainable, readable code. Following coding standards

1. Software Development Best Practices
----
Coding Standards & Maintainable Code
Ankur Goyal
Email: ankur.fbd@gmail.com

2. for(j=0; j<array_len; j+ =8)
{
total += array[j+0 ];
total += array[j+1 ];
total += array[j+2 ]; /* Main body of
total += array[j+3]; * loop is unrolled
total += array[j+4]; * for greater speed.
total += array[j+5]; */
total += array[j+6 ];
total += array[j+7 ];
}
Warm up

3. for(j=0; j<array_len; j+ =8)
{
total += array[j+0 ];
total += array[j+1 ];
total += array[j+2 ];
/*
Main body of loop is unrolled for greater speed
total += array[j+3];
total += array[j+4];
total += array[j+5];
*/
total += array[j+6 ];
total += array[j+7 ];
}
Isn’t it better ?

4. What is it you expect, to get out of this Session?
Participant’s Expectations

5. Setting Expectations Right
• What this session is about?
– Identify & appreciate the importance of Coding
Standards
– Few examples
– Introduction to standard supporting tools
• What this session is not about?
– Coding Tutorial
– Details on coding standards

6. Maintainability
• Maintainability is the ease with which a product
can be modified in order to:
– correct defects or their cause
– meet new requirements
– cope with a changed environment
– e.g. iOS 5 to iOS 6, windows 7 to windows 8
Write simple, self-documenting code that is pleasant to revisit
even after months.

7. Coding Standards
• Coding standards are guidelines for code style
and documentation.
• The purpose is that any developer familiar with
the guidelines can work on any code that
followed them.
• We need to write code that minimizes the time it
would take someone else to understand it ---
even if that someone else is you.

8. Why Have Coding Standards?
• Reducing the cost of
software maintenance is the
most often cited reason for
following coding standards.
• ~80% of the lifetime cost of
a piece of software goes to
maintenance.

9. Is this really necessary ?
• YES. To all programmers, even if there is only one
developer on the project.
• Because:
– Most of the time software is not maintained by
the original author.
– If everyone follows the standards, you feel
comfortable using your colleague's code,
because it seems like your own code.

10. hmmm really ?
– Estimations are approved considering an average
programmer who follows coding standards.
– Not following coding standards will lead to review
comments & thereby rework, which in turn will lead to
effort variation.
– Since most of the time client delivery dates are fixed
hence it all leads to extra hours spent in office -> more
time -> more money.
– It’s a vicious circle, only way out is following coding
standards.

11. FEW
EXAMPLES

12. Using constants on LHS
• Constants should always be used on left hand
side of equality operator
• Avoids invalid assignment
• Avoids null pointer exceptions

13. Using constants on LHS
T h i s c o d e c a n c a u s e
N u l l P o i n t e r E x c e p t i o n
i f p a s s e d a r g u m e n t
‘ i n p u t ’ i s n u l l
R i g h t A p p r o a c h

14. Indentation
• Gives an indication of scope though doesn’t
affect program
• Must for maintainability & readability of code

15. Example
Compare
- Easier to Read
- Easier to Understand
- Easier to maintain
To
Pressing “Ctrl+shift+f” in eclipse formats source file
(set up your formatting style in Window|preferences | java | code style | formatter)

16. Commenting Code
• Document WHY & WHAT along with HOW.
• Comments should
- Clearly demonstrate the function of the code,
both to yourself and to other developers
• Comments should NOT be
- Too long
- Overcomplicated

17. Example
Compare

18. Example
To
 Comments are not about how much you write
 Comments should add illustration to the code for maintainability

19. Naming Variables
• Variable names are often thought to be less
important but they are vital to understanding
certain pieces of code.
• In the majority of programming languages,
variables can be assigned almost any name.

20. Example
Compare following:
To:
Trade off is generally between meaningfulness & shortness, rule of thumb is, always give
priority to meaningfulness.

21. Instance Creation
• Do not create instances as far as possible.
• creation of new instance is avoided in the
internal part of loop.

22. Example
Compare
Instance creation in loop, this may lead
to out of memory error…
To

23. Instance Creation
• Use valueOf() instead of new().
• valueOf() provides value from cache while
new() creates new instance.

24. Example
use
instead of

25. Cast
• As much as possible cast must be enclosed in
condition statement of instanceof.
Use instanceof()
This may lead to classcastexception
Use instanceof to avoid
classcastexception

26. Unreadable Code
• Write a code that can be understood by any
average programmer.
• This helps in maintainability & readability of
code.
• Helpful in understanding time critical projects

27. Example
Compare
To
Programmer’s expertise is not in writing complex code, expertise
is to write a code which is easy to understand & maintain.

28. String Concatenation
• Use StringBuffer and StringBuilder for String
concatenation operations.
• String is immutable hence creates new objects
whenever the value is changed
• Use StringBuffer if application is multithreaded &
synchronization is required
• Use StringBuilder elsewhere.

29. Example
Instead of
Use
Or
String object is
immutable whereas
StringBuffer/
StringBuilder
objects are mutable

30. REPOSITORY COMMENTS
• Often it is observed that repository comments do
not get the attention they deserve.
• Repository comments should convey the changes
committed along with applicable references e.g
– If bug is fixed mention fixed bug ID
– If any CR is implemented mention CR number/name
– If review comments are fixed mention review plan id

31. Example
Following are some of the real svn repo comments:
SVN repo comments serve purpose of maintaining code revision history, pay
respect to this fact & spend some time to write useful comments

32. Coding Standard & Best Practices
Tools
• CheckStyle
– makes sure that everyone in the team write code in a
similar manner
– is the glue that enables people to work together and to
free up their creativity instead of spending time and
energy at understanding inconsistent code.
• PMD
– reminds you of bad practices such as:
• Catching an exception without doing anything
• Suboptimal code - wasteful String/StringBuffer usage
• Duplicate code - copied/pasted code means copied/pasted bugs

33. Recap
• The purpose is that any developer familiar with the
guidelines can work on any code that followed them.
• Following coding standards saves both time and
money.
• Standardize early - the effort to bring your old work
into the standard will be too great otherwise.
• Document every time you violate a standard.
• Industry Standards > organizational standards >
project standards > no standards.

34. THANKS !!!
 Guidelines & practices mentioned in this slide were just a
tip of iceberg, there is no hard & fast rule regarding
guideline & they generally differ on basis of domain,
technology used & clients’ requirement etc.
Purpose of this presentation was to encourage habit of
following standards by identifying importance of the same.
Finally, following guidelines & adhering to standards is
responsibility of each individual.
Conclusion