I wanted to see what
NDepend had to say
about the code of SharpDevelop 3.0. SharpDevelop is an
Integrated Development Environment (IDE) for C#, VB.NET and Boo projects. It is
compatible with VisualStudio 2008
project and solution files. You can then easily switch from VisualStudio to SharpDevelop forth and back. Try it on your current code base’s
solution(s), frankly it is impressing.
The root point for the source
code of SharpDevelop is a solution
composed of 53 projects. You can rebuild everything seamlessly and the core assemblies
of the IDE will be put in the $Root$\bin folder. But actually SharpDevelop is composed of numerous add-ins.
The addin’s assemblies can be found in the $Root$\Addins\
sub folders.Btw, downloading a project, opening one unique solution, being able to rebuild everything without a single problem, all these facts advocate at first glance for a solid impression of quality. I can attest that this is unfortunatly more the exception than the rule.
Normal
0
21
false
false
false
FR
X-NONE
X-NONE
MicrosoftInternetExplorer4
Project Organization & Global Metrics
When starting investigating a massive
code base, I found out that assemblies’ location information is essential
to get a first big picture. And the VisualNDepend > Project Properties > Code to Analyze panel is
a good place to start, even before performing any analysis. Thanks to the
button Add Assemblies of a VisualStudio
solution, in a click I was able to:
- List the 53 SharpDevelop
assemblies
- List the 34 tier
assemblies on which the SharpDevelop assemblies depend on.
- List the numerous folders
that contains all these assemblies (SharpDevelop ones + tiers)
- For each assembly, this
panel immediately gives access to many relevant information: Size, Version, Location,
PDB found or not, Strong named or not, last modification time, Runtime & Platform targeted
+ a tooltip to instantly see which assemblies are referenced (+ these referenced assemblies versions).
- For each folder, I can
see which application/tier assembly it contains (green/blue).
After performing the
analysis you get more information. First surprise, the project is not that big
with 141 455 Lines of Code.
Still, it is a lot of code, twice as big as NDepend, 10 times NUnit, 4
times NHibernate, a third of Resharper, a tenth of the .NET framework. Here are
some other metrics:
# lines of code (LOC) 141 455
# Assemblies 53
# Namespaces 229
# Types
3 894
# Methods 32 656
# Fields 12 012
Tier code
used by the application:
# Tier
Assemblies used 34
#
Namespaces used 120
# Types
used 1 545
# Methods
used 5 115
# Fields
used 321
Normal
0
21
false
false
false
FR
X-NONE
X-NONE
MicrosoftInternetExplorer4
Assemblies Dependency Graph
By having a look at the assembly
dependency graph we can see the IDE extensibility pattern in action: All addins
assemblies (in green) reference directly the assembly ICSharpCode.SharpDevelop. (in orange) + a few others (in blue).
Normal
0
21
false
false
false
FR
X-NONE
X-NONE
MicrosoftInternetExplorer4
Core Namespaces Entangling
It is clear that the assembly ICSharpCode.SharpDevelop made of 28K LoC is the core
of the IDE. By looking at this core assembly's namespaces dependency with the Dependency Matrix below, we can see that its code is not properly layered. Indeed, the red square shows a
big lump of entangled code. The namespaces ICSharpCode.SharpDevelop,
ICSharpCode.SharpDevelop.Project and ICSharpCode.SharpDevelop.Gui
are the roots because more or less all other namespaces use them. Each black cell
of the 3 corresponding rows (numbered 17, 19 and 22) represents a dependency to
discard from the root to upper level.
Normal
0
21
false
false
false
FR
X-NONE
X-NONE
MicrosoftInternetExplorer4
Code partitioning through Assemblies
Despite this core entangling
issue, the overall structure of the code seems well balanced. We can infer this
information by looking at the metric view where we can see that features are
pretty well partitioned in their respective assemblies. I am usually against
having numerous assemblies but here, due to the extensibility nature of an IDE,
harnessing assembly physical frontiers do make sense: this enables loading
feature on-demand. And indeed, the starting-time of the IDE is really short and
I suspect it is thanks to this fine-grained physical componentization.
Normal
0
21
false
false
false
FR
X-NONE
X-NONE
MicrosoftInternetExplorer4
Methods Quality
With the
following CQL query we can ask for methods that doesn’t satisfy classic quality
metric threshold. 1246 methods are matched which is not neglectable, but far from being a major issue.
WARN IF Count > 0 IN SELECT METHODS WHERE
!NameIs "InitializeComponent()" AND
// Metrics' definitions
( NbLinesOfCode > 30 OR // http://www.ndepend.com/Metrics.aspx#NbLinesOfCode
NbILInstructions > 200 OR // http://www.ndepend.com/Metrics.aspx#NbILInstructions
CyclomaticComplexity > 20 OR // http://www.ndepend.com/Metrics.aspx#CC
ILCyclomaticComplexity > 50 OR // http://www.ndepend.com/Metrics.aspx#ILCC
ILNestingDepth > 4 OR // http://www.ndepend.com/Metrics.aspx#ILNestingDepth
NbParameters > 5 OR // http://www.ndepend.com/Metrics.aspx#NbParameters
NbVariables > 8 ) // http://www.ndepend.com/Metrics.aspx#NbVariables

Project evolution
Finally, by curiosity I did a diff with NDepend between SharpDevelop v3.0 beta 3 and SharpDevelop v3.0.
I find out that not only a lot of changes occured (733 methods
modified, 613 added) but this changes impacted pretty much the whole
code base. It certainly means that between these 2 releases, the team updated many features and maybe some non-fonctional requirement as well. The
homogeneity of changes is exposed on the picture below. When we are
asking for methods where code was changed between the 2
releases, we can see on the treemap that blue rectangle (representing
methods matched) are spreaded all around the code base.

Normal
0
21
false
false
false
FR
X-NONE
X-NONE
MicrosoftInternetExplorer4
Posted
Sun, Apr 26 2009 1:27 PM
by
Patrick Smacchia