Patrick Smacchia [MVP C#]

Sponsors

The Lounge

Advertisement

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

 


Posted Sun, Apr 26 2009 1:27 PM by Patrick Smacchia

[Advertisement]

Comments

DotNetShoutout wrote The big picture of the SharpDevelop code base - Patrick Smacchia - CodeBetter.Com
on Sun, Apr 26 2009 3:19 PM

Thank you for submitting this cool story - Trackback from DotNetShoutout

Visual C# Kicks wrote re: The big picture of the SharpDevelop code base
on Mon, Apr 27 2009 3:46 PM

Wow this is truly interesting. Very good read.

hdierking wrote re: The big picture of the SharpDevelop code base
on Tue, Apr 28 2009 2:45 AM

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!

Brownsblogging wrote Daily Reading List
on Tue, Apr 28 2009 8:29 AM

Daily Reading List

Mihai wrote re: The big picture of the SharpDevelop code base
on Tue, May 5 2009 4:18 AM

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

A. Bekiaris's Blog wrote Inspect Xaf code quality and override version migration problems using NDepend
on Sat, Jul 4 2009 2:27 PM

NDepend is the most wonderful analysis tool I have ever found . It can help you by providing metrics

Add a Comment

(required)  
(optional)
(required)  
Remember Me?