The big picture of the SharpDevelop code base

 

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

 

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Anonymous

    Is that really the sharpdeveloper code base?

    http://magnetechtransformerrepair.com/

  • Mihai

    Why not do the same for MonoDevelop ? Let’s see if the second time the Linux guys got it better :D

  • http://codebetter.com/members/hdierking/default.aspx hdierking

    I really enjoy these posts, Patrick – they are helping me get more comfortable looking at all of the different analysis techniques that NDepend gives me. Many thanks!

  • http://www.vcskicks.com Visual C# Kicks

    Wow this is truly interesting. Very good read.