Sonar - Effective code Reviewer

• What is Code Analysis ?
• Benefits
• Introduction to Sonar
• Sonar Dashboard
• Features
• Unit tests inspection
• Quality Profiles
• Issues Drilldown
• Application Lifecycle Management
• Time Machine

Well we all know that code analysis is a very basic and important part of software development process .  It doesn't matter how much experience we have in software development , we usually end up in a code that contains some bugs ( though it is not our intention ) . 

Though we use tools like debugger or profiler to ensure the code quality , the use of such tools comes late in the development process . I believe that code quality analysis should be done right after you write the source code , even without executing it . Such work can be done effectively by static code analysis tools . One should not take it as an alternate to code review process but can think it as an add-on to improve the code quality. 

What is Code Analysis ?

Code analysis is analyzing the source code without executing it . The purpose is  to find bugs or ensure conformance to coding guidelines . For example - Compiler showing lexical, syntactic and even semantic mistakes . 

The code analysis is either done by the code reviewer or a static code analysis tool . I would say that both are equally important but this post is dedicated to the latter . The tool we are going to discuss here is Sonar.

Benefits
There are various benefits of code quality analysis . Some of them are :

• Code becomes more readable
• Less error prone
• More reliable

Introduction to Sonar
Sonar is an open source code quality analysis tool that analyzes the source code , gather metrics about code quality and put them in a dashboard . Apart from analyzing the code , it also provides some tips to make the code better .

According to SonarQube , it covers seven axis of code quality :

• Architecture and Design
• Complexity
• Potential bugs
• Code Duplication
• Unit tests
• Comments
• Coding rules

Sonar can be downloaded from http://www.sonarqube.org/downloads/


Sonar Dashboard

Sonar provide a comprehensive dashboard that provides high level metrics of a project .


Features
The sonar comes with a lot of features but all can't be discussed here . But we can have a look at some basic features :

Unit tests inspection
Sonar inspects and validates the unit tests and provides the metrics on the dashboard .
Sonar also identifies the line coverage along with the uncovered conditional statements.

Quality Profiles
Can create quality profiles with different quality objectives on projects.

Issues Drilldown
Sonar provides a feature to drilldown the individual classes and identifying the problematic area . Sonar does a rule based defect identification and all the defects have a severity ( for example Blocker , Major ).

Application Lifecycle Management
Sonar integates easily with the Application Lifecycle Management tools like Maven , Jenkins , Eclipse and enables faster development.

For example-
Build Integration : Maven
Continuous Integration : Jenkins
IDE integration : Eclipse
Version Control : SVN 
JIRA integration 


Time Machine
Examine progress of the code using Time Machine . Motion Chart and Timeline and all these components can be dynamically customized . 

Sonar supports numerous other features and to see all of them , click here.

Dependency Injection Vs. Factory pattern.

Dependency Injection ( DI ) and Factory pattern might look related to each other but there is a difference between them . Factory take the responsibility of creating an object while DI inverse the process of how an object obtains the dependencies . DI gives the responsibility of injecting dependencies to an external entity.

Example : 

1. While using a factory , the dependent class  Foo is responsible for creating the instance of its dependency Bar  . In the below example we can see that Foo is calling the static method ( getInstance() )  of class BarFactory for instantiating Bar. 

public class Foo {
    private Bar bar = BarFactory.getInstance();

    public void doStuff() {
          bar.doSomething();
    }
}

2. With DI , Foo is no more responsible for resolving the dependencies by its own . An external entity , for example spring container is responsible for instantiating and injecting the instance Bar in Foo class . 

public class Foo {
  private Bar bar;

 /**
  * DI container uses the constructor to inject 
  * the dependency in Foo class.
  */
  public Foo(Bar bar) {
     this.bar = bar;
  }

  public void doStuff() {
      bar.doSomething();
  }
}

Advantages of DI :

1. Better decoupling of classes . 
2. Better Unit testing . Now it is easier to inject mock implementation of the services into the object being tested.

Dependency Injection with Spring framework

• What is Dependency Injection ( DI ) ?
• Types of DI.
• Advantages.
• DI with Spring framework.
• Constructor based DI or Setter based DI

What is Dependency Injection ( DI ) ?

Dependency Injection means inversion of responsibilities with regard to how an object obtains references to collaborating objects. When applying DI , objects are given their dependencies at creation time by some external entity that coordinates with each object in the system.

As you can see,  this process is inverse of what happens without DI .  The object itself is responsible for instantiating or locating the dependencies by using direct construction of classes  or a service locator .

Types of DI

Interface injection 

In Interface injection , class provides an interface that its users implements to get the dependencies at runtime .                                                                                      

Setter injection  

In setter injection , setter method of the dependent class is used by a framework to inject the dependencies .                                                                                                  

Constructor injection 

In this , the constructor of the dependent class is invoked by the framework to inject the dependencies . 

Advantages

1. Cleaner code / better decoupling :

The code is cleaner and  decoupling is more effective  between the classes . With DI , the objects are no more responsible for acquiring their dependencies by their own .

2. Efficient Unit testing :

With DI , it is easier to inject mock implementations of a service into the object being tested.

I did a google search and found some interesting links that describes the benefits of DI :

From  : http://en.wikipedia.org

http://en.wikipedia.org/wiki/Dependency_injection#Benefits

From : http://tutorials.jenkov.com

http://tutorials.jenkov.com/dependency-injection/dependency-injection-benefits.html

DI with Spring framework.                            

In Spring DI exists in two variants :

1. Constructor-based DI.

2. Setter-based DI.

1. Constructor-based DI.

In constructor-based DI , the constructor of the dependent class is invoked by the spring container . Each argument of the constructor represents the dependency. 

public class Foo {
 private final Bar bar;

 public Foo(Bar bar) {
  this.bar = bar;
 }

}

For injecting Bar into Foo's constructor , we need to define their dependency in a configuration file as given below :

<beans>
 <bean id="bar" class="com.springdi.Bar"/>
 <bean id="foo" class="com.springdi.Foo">
  <constructor-arg ref="bar"/>
 </bean> 
</beans>

2. Setter-based DI.

In setter-based DI , container calls the setter methods on the bean . Container  invokes the no argument constructor or no argument static factory method to instantiate the bean .

public class Foo {
 private Bar bar;

 /**
 Bean contains a setter method that will be invoked by the container
 to inject the dependency.
 */
 public void setBar(Bar bar) {
  this.bar = bar;
 }
}

In the configuration file , we will define the dependency using the tag "property" and not "constructor-arg".

<beans>
 <bean id="bar" class="com.springdi.Bar"/>
 <bean id="foo" class="com.springdi.Foo">
  <property name="bar" ref="bar"/>
 </bean> 
</beans>

Constructor-based DI or Setter-based DI 
For mandatory dependencies , use constructor-based DI and  for optional dependencies , use setter-based DI .  

NOTE :
If we use @Required annotation with a setter , it becomes a required dependency .