Today I checked in some improvements on Pflection.
Athe previous article about Pflection I realized that the names of elements are not sorted by name, so I fixed this tiny issue :) .

Other thing that I build-in, is an index of Event Listeners.
Event listeners are just special functions but I think they deserve a separate entry in Pflection Metrics view.

The PlugIn can be downloaded as always on FDT-OS Google Code website

Lately I was asked to write a few words about Pflection. So I decided two write a new Blog Post.

What is Pflection?
Pflection is FDT View used for code review.

The view is separated in three columns.

First column contains information collected by FDT on elements you selected. Pflection reacts on selections made in Project or Outline View. Multi selection is also supported.

As you can see there are two kinds of collected data.
1. A list of a certain elements with a quantity
2. A list of OO and functional characteristics with absolute quantity and average distribution.

On metric selection in first column, second column will show the compound items.

In case of certain elements list user gets a quick view on names of elements and can open the element in source editor by double click. This way user may find poorly named elements.

When a characteristic item is selected, user will see the distribution list in second column and the elements compound in the distribution if one is selected in second column.

So how does Pflection help me to improve my design?

As already mentioned, you can improve the naming of your elements by browsing through element lists.
You can lookup the distribution of interface implementations and class inheritance depth.
I suggest deep class inheritance is not always a good solution and an interface should be implemented more than one time.
You also can lookup coupling of elements through Incoming/Outgoing Reference ratio.

Complexity of functions may be monitored by:
- number of method lines of code,
- number of parameters you may use to call this function
- number of blocks in a function
- number of conditions / branches introduced in function btw. this number correlates with number of test you need to get a 100% code coverage
- number of flow terminations

Thank you for your time and have fun with Pflection.

PS: I used funk-as3 for demonstration / screenshot creation.

Shame on me!

I disappeared for a month but now I am back with some of topic stuff.
I will continue to work on MockitoViz as soon as I can, but now I want to write about some other pet project of mine.

Pflection is a view for FDT that shows some Software development metrics for selected project, package or what ever you selected in your project/outline view.
At the moment I implemented Pflection I was not aware of Sonar, but in my opinion the two projects has also different field of use. Sonar is a CI tool, Pflection other wise is development tool. The feedback cycle of Pflection is much shorter.

So what does Pflection can?

It watches you selecting elements(multi selections enabled) in Project or Outline View and shows aggregated data about selected items. For example if you are selecting a project it will aggregate the data about all the containing elements (libraries, source folders, packages etc..)

What data (metrics) we are talking about?

Metrics can be divided in following groups:
Source Containers:
- Number of Libraries (SWC)
- … source folders
- … packages
Compilation Units (Master Elements – representing the file):
- … classes
- … interfaces
- … functions
- … variables
- … constants
- … namespaces
Nested (hidden/local) Elements:
- … classes
- … interfaces
- … functions
- … variables
- … constants
- … namespaces
Type members:
- … methods
- … static methods
- … setter
- … getter
- … field
- … constantField
- … namespace
- … metatag
Object Oriented:
- Interface implementation rate
- class inheritance depth
Dependency based:
- Number of incoming references
- Number of outgoing references
Behavior (Function) based:
- Method lines of code
- Number of conditions
- Number of blocks
- Number of flow terminations

Now I would like to talk about the last three metrics and how they can be computed.
Lets start with the simple one – number of blocks.
blocks are code statements wrapped in ‘{}’.
So by providing the number of blocks in a function we can make assumptions about horizontal and vertical distance inside the function.
FDT has also a Parser that creates AST from source code.
Block is an AST element so we just have to walk throw a function AST and count the appearance of Block Nodes.

I wrote some Scenarios to test the visitor:

Scenario: Check an empty function
Given a function:
function foo(){
}
When applying Function Analyser
Then number of blocks is '1'

It’s pretty simple to test the visitor because there is no need of binding the function. But any way if your Visitor needs a binding based computations it’s better to delegate it to another Class and mock it out for the test. This way you also end up with a better responsibility distribution.

Here is another Scenario for block computations but than let’s move on

Scenario: Check function with nested if/else condition for blocks
Given a function:
function foo():void{
	if(true){
		if(false){
		}
	}else {
	}
}
When applying Function Analyser
Then number of blocks is '4'

Next metric I would like to mention is number of conditions.
This metric show how many ways your code can be executed and how many tests (at least) you should write to have a 100% code coverage.
I implemented all three metric computations in the same visitor for a better performance and because they all have the same responsibility – count appearance of some particular AST element.
The AST elements I am interested in for condition counting are:
all sort of loops, if and case statements.
I also included a try block because the code inside a try block can have different execution flows.
Oh and last but not least condition expression.
Here is a scenario

Scenario: Check a function with nested condition expression 
Given a function:
function foo():void{
	true ? true : false ? trace("a") : trace("b")
}
When applying Function Analyser
Then number of conditions is '2'

Number of flow terminations – this metric provides you with info how many exit points your function has. The more exit points your program has, the more aspects you have to keep in mind when you are reading it.
A simple void function has only one exit point.

Scenario: Check an empty function with void type
Given a function:
function foo():void{
}
When applying Function Analyser
Then number of flow terminations is '1'

A typed function has a termination when it has a return statement

Scenario: Check a simple typed function
Given a function:
function foo():int{
	return 0;
}
When applying Function Analyser
Then number of flow terminations is '1'

A termination point can also be a continue and break statement. Those are no end points for a complete behavior, but they merge two execution flows together.
A global behavior end point is also a throw statement.

Scenario: Check a void function with throw exeption
Given a function:
function foo():void{
	if(false){
		throw new Error("foo");
	}
}
When applying Function Analyser
Then number of flow terminations is '2'

All the scenarios can be browsed in FDT-OS project on google code website
http://code.google.com/p/fdt-os/source/browse/#svn/trunk/FDTPflectionTest/src/de/bomzhi/mz/pflection/model/scenario

So if you think there are some additional scenarios/features I haven’t thought of, please try it out and post it in comments.

When I worked in FDT Project I was always thinking about a contributor program, so when I leaved Powerflasher I arranged to start an OpenSource project for FDT. http://code.google.com/p/fdt-os/

And here is the first born out of this arrangement.

The Idea:
I was always interested in Software Metrics. I think it is a very strong instrument to improve your design, and detect code smell. Pflection gives you the possibility to reflect on your code (project) directly in your IDE. It also provides you with possibility to navigate to this code smells and think about refactoring :) .

So at the moment it is still work in progress I implemented only a few metrics, but it is more to go. And maybe I will start a parallel Project for JDT.

PS: If you want to try it out, navigate to this URL download the jar file and place it in your FDT/Eclipse “dropins/plugins” folder.

© 2011 Max Blog Suffusion theme by Sayontan Sinha