What problems are easy to spot in a dependency graph?

Question

What are the things I should be looking for when I produce a dependency graph?

Or to put it another way, what are the characteristics of a good looking graph vs a bad one?

Edit: The context here is my first look at my assemblies in NDepend.

Answer 1

The biggest problem you can spot is definitely Dependencies Cycles. The tool NDepend proposes an interactive dependency Matrix and a dependency Graph that will help to spot dependency cyles. Disclaimer: I am one of the developers of the tool

Notice that the dependency matrix is much more adapted than graph to spot cycles. Because a cycle avoid the matrix to be triangular.

The other ranges of problems are relative to your application structure: For example, is it normal that the UI uses directly the DB? or much worse, the DB depends on UI?

You can write code rules over LINQ queries (CQLinq) to check for forbidden dependencies. The following code rule check that UI types shouldn't use directly DB types:

// <Name>UI layer shouldn't use directly DB types</Name>
warnif count > 0

// UI layer is made of types in namespaces using a UI framework
let uiTypes = Application.Namespaces.UsingAny(Assemblies.WithNameIn("PresentationFramework", "System.Windows", "System.Windows.Forms", "System.Web")).ChildTypes()

// You can easily customize this line to define what are DB types.
let dbTypes = ThirdParty.Assemblies.WithNameIn("System.Data", "EntityFramework", "NHibernate").ChildTypes()
              // Ideally even DataSet and associated, usage should be forbidden from UI layer: 
              // http://stackoverflow.com/questions/1708690/is-list-better-than-dataset-for-ui-layer-in-asp-net
              .Except(ThirdParty.Types.WithNameIn("DataSet", "DataTable", "DataRow"))

from uiType in uiTypes.UsingAny(dbTypes)
let dbTypesUsed = dbTypes.Intersect(uiType.TypesUsed)
select new { uiType, dbTypesUsed }

Answer 2

a dependency graph of what? classes? stored procedures?

cycles are bad...

Answer 3

If changing one dependency means you need to change a whole lot of others, it's bad.
But yea, some context could help.

Answer 4

I don't known what NDepend shows but artifacts that tend to get into many sections (particularly unrelated sections) of code would tend to be bad (IMHO). I've thought of that as "Cancer Code".

Answer 5

A speaker at a NFJS conference showed us some dependency graphs... One smell he pointed out was to look for things with relationships to different functional parts of your codebase. These likely break encapsulation.

Also I would look at the general complexity of each section.. ones with lines all over are suspects.