Design & Coding Excellence Tutorial

I made a tutorial on design and coding excellence and thought of sharing with all software programmers. All of us write code however keeping certain best practices, principles, guidelines in mind while do so leads to greater design and coding. Most of the times, programmers tend not to worry about best practices while designing/coding but just complete the task in hand. This tutorial is an attempt to become better programmers. Takes less time to go through this but has lot of benefits in terms of how design and develop the software systems. Hope this tutorial on design and coding excellence benefits the readers.

Table Of Contents
                       

Ser.No	Topic	Description
1	Fundamental Design Principles	Talks about fundamental design principles namely, Fail Fast, TELL, DON’T ASK, Design By Contract, Minimizing the Impact of Change principles
2	Principles of Object Oriented Design	Talks about principles of class design (1) Single Responsibility Principle,(2) Open Close Principle, (3) Liskov Substitution Principle, (4) Dependency Inversion Principle, (5) Interface Segregation Principle and also covers principles of package design (1) Acyclic Dependency Principle (2) Stable Dependency Principle
3	Code Review Principles & Assumptions	Covers  types of code reviews, code review practices and assumptions (1) Explicit (2) Implicit assumptions
4	Handling Software Errors	Talks about types of software errors and best practices on how to handle them
5	Code Smells & Coding Standards	Covers what are code smells, how to eliminate code smells and guidelines on coding standards
6	Cyclomatic Complexity	Talks about what is code complexity and how to calculate the complexity and decrease the code complexity in legacy code
7	Refactoring	Covers best practices while refactoring the code.

Remember that there is no absolute truth in software. Some guidelines may be controversial. The practices, standards are usually customized to suite the type of the software development that is being carried out. In case of such arguments, we need to always look for the technical merits and demerits. For example some teams have file modification history on top of the source file and this is necessary if we do not have the version control system. In case of using version control systems, we can always differentiate between two sets of changes by comparing the revisions.
  

References

Fail Fast (http://martinfowler.com/ieeeSoftware/failFast.pdf)
Design By Contract (http://en.wikipedia.org/wiki/Design_by_contract)
Principles and Patterns (http://objectmentor.com/resources/articles/Principles_and_Patterns.pdf)
Single Responsibility Principle (http://objectmentor.com/resources/articles/srp.pdf)
Open Closed Principle (http://objectmentor.com/resources/articles/ocp.pdf)
Liskov Substitution Principle (http://objectmentor.com/resources/articles/lsp.pdf)
Dependency Inversion Principle(http://objectmentor.com/resources/articles/dip.pdf)
Interface Segregation Principle(http://objectmentor.com/resources/articles/isp.pdf)
Cyclomatic Complexity (http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html )
What was that story about the WinHelp pen-writing-in-book animation? By Remond Chen
http://blogs.msdn.com/b/oldnewthing/archive/2010/08/17/10050774.aspx
Documentaion/Naming conventions/ Functions
http://stackoverflow.com/questions/1585337/how-much-percentage-of-your-day-would-you-like-to-spend-on-writing-documentation
Clean Code (http://www.amazon.com/dp/0132350882/?tag=stackoverfl08-20)
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_sim_b_1
Refactoring (www.refactoring.com)

Cyclomatic Complexity

Cyclomatic complexity is about how complex the code is written. Too many conditional statements and lengthier methods add to the complexity of the method. Complexity is measured as an integer number. Lets say a method's code complexity is 8, there have to 8 unit test cases written for it.An 'if' condition leads to the complexity of 2. 1 for if statement and another for else case. Software code with high complexity is more difficult for a programmer to understand because programmer has to understand different pathways and results of those pathways. The changes of bugs are high in high complexity code. Also chances of regression bugs are high in high complexity modules. These conditional complexity is referred as Cyclomatic Complexity.

Complexity Levels

Complexity	The Risk Factor
01 - 10	Simple program without much risk
11 – 20	More complex, Moderate risk
21 – 59	Complex, high risk program
Greater than 50	Untestable Code

How to calculate the complexity?

Code complexity can be calculated manually. For example counting number of closed loops, 2 for if conditions, 1 for switch statements etc but it is tedious job. There are tools which can calculate the complexity. In eclipse IDE, metrics plugin can be downloaded and installed. Find the complete procedure for calculating and viewing the results in eclipse IDE at http://metrics.sourceforge.net/

One of the objectives of code review is to look for the code complexity. Having the first complexity level increases the code readability. Readability is important because in a software life time, 80% the code is 'read' and only 20% of the time code is written. When the software goes under maintenance phase, the code only read and very minimal changes are done on top of existing code. 'Write code as if you are writing a story' so that people reading the code can understand it in less time and go home early!

Legacy code complexity can be reduced by refactoring the code

You might be interested on this article. Code improvement through Cyclomatic Complexity.

Code Refactoring

Refactoring is restructuring existing code. Refactoring is carried out to remove code smells. Refactoring does  NOT fix bugs. Refactoring is done when there are robust unit test cases to test the code. These test cases are executed before and after refactoring the code and test case results must be the same before and after. This ensures there are no bugs introduced due to refactoring.

As a practical example, a software was supporting a protocol and requirements got changed and we wanted to support a second protocol, refactoring was done to extract the source code that stands common for both the protocols and protocol specific code was separated out and common interface was provided. The point is that sometimes refactoring becomes mandatory to incorporate new software requirements. Refactoring is also applied just to improve the code readability, better maintenance and extendability purposes.

1. Some refactors are controversial
2. Some are arguably not improving code quality
3. Refactoring can in fact be counter productive when applied blindly
4. Apply in combination and make sure refactoring is applied in productive manner.

Refactoring Methods

1. Extract Method: If your method is too long and is performing multiple tasks, the code snippet that is doing a unique task that main method name does imply, that code snippet is extracted into a method.
2. Replace temp with query: This is about assigning a query result into a variable and then using that variable, instead the query result can directly be used. This is controversial anyway.
3. Replace type code with state/strategy: You have a type code that affects the behavior of a class, but you cannot use subclassing.
4. Replace conditional with polymorphism : You have a conditional that chooses different behavior depending on the type of an object.
5. Form template method: You have two methods in subclasses that perform similar steps in the same order, yet the steps are different.
6. Replace Magic Numbers with symbolic constant: You have a literal number with a particular meaning