NDepend

Improve your .NET code quality with NDepend

Self_Documenting_Code_vs._Comments_Turns_Out_It_s_Both_or_Neither

Self Documenting Code vs. Comments? Turns Out It’s Both or Neither

It’s been about a month since my last research post, and I’ve been musing about the next topic.  What should it be?  Well, I’ve decided.  Since I love nothing more than throwing the gates wide for everyone’s internet anger, I thought I’d weigh in on the subject of self documenting code vs comments.

I’ll be awaiting your rage below, in the comments.

Continue reading Self Documenting Code vs. Comments? Turns Out It’s Both or Neither

extension_methods_decline_of_traditional_oop

Extension Methods and the Decline of Traditional OOP

A bunch of years ago, I wrote a post on my own personal blog titled, “Why I Don’t Like C# Extension Methods.”  Over the years, I’ve updated that post a bit, but mostly left it intact for posterity I guess.  But if you ask me how that post has aged, I’d respond with “it’s complicated.”

I didn’t like extension methods back then.  I do like them now, provided they aren’t abused.

So, what gives?  Am I just a hypocrite?  Or is it a matter of growth?

Well, none of the above, I’d argue.  Instead, the programming landscape has changed and evolved.  And I’d submit that extension methods were actually ahead of their time when the language authors came up with the concept.  But now they’re hitting their stride.

Don’t take my word for it, though.  This is another one of my research posts, whose previous ranks have included how functional approaches affect codebases, what unit tests do to code, and a look at singletons.  Today, we’ll take a look at extension methods and what properties of codebases they correlate with.

Continue reading Extension Methods and the Decline of Traditional OOP

shotgun_surgery_what_is_it_ndepend

Shotgun Surgery: What It Is and How to Stop It

I really love the name “shotgun surgery” for describing a code smell.  It’s sort of an interesting mix of aggressive and comical, and so it paints a memorable picture.  I kind of picture Elmer Fudd blasting away at a codebase and then declaring “ship it” and doing some kind of one-click production push.

But misappropriating Looney Tunes aside, what actually is shotgun surgery?

Well, it’s a specific code smell in your codebase.  Shotgun surgery happens when you have to make many changes in your codebase to achieve seemingly simple tasks.  Often, you’ll find yourself making changes to code that seems pretty similar, either copy-pasted directly, or else of similar intent.

Continue reading Shotgun Surgery: What It Is and How to Stop It

ISV_Favor_Software_Products_That_Include_Support_Price

You Should Favor Software Products That Include Support in the Price

Quite often we talk about architectural concerns on this blog, with topics like application layering or the merits of design patterns.  But today I’m going to switch gears a little and talk about your wallet.

Oh, don’t worry.  We’re not going too far afield.  I’m going to talk about how your developer tools purchases affect your wallet.

When it comes to product support, you probably don’t give this a ton of thought.  At least, you’re probably more focused on features, what problems the product solves for you, what the price is, and so on.  The support arrangement probably matters somewhat to you, but doesn’t rise to top of mind.

But today, I’m going to ask you to think about it a little bit.  And I’m going to suggest that you give a quick consideration during future purchases as to how support works.  Simply ask yourself, “does this vendor ask you to pay extra for support?”

If the answer is yes, that’s a smell.

Continue reading You Should Favor Software Products That Include Support in the Price

autofac_detailed_look_under_hood

Autofac: A Detailed Look Under the Hood at Its Code Quality

In case you haven’t seen it, I’ve been diving ever-further down the code research rabbit hole.  Today it brings me to the Autofac codebase (found here).  But to understand how I’ve arrived here, consider some of the questions that I’ve answered previously.

With each of these studies (and the rest of the series), the research has become more sophisticated.  This is because I’ve started working with folks that have a data science and machine learning background.  So I’m now having fun assembling measurable codebase properties into broad categories and seeing how my corpus of 500+ open source codebase resolves into patterns.

And that brings me to Autofac.

It caught my eye by ranking in the 85th percentile for what I’m calling “testable” codebases and in the 58th for “readability.”  And in general, it scores decently to well in just about every measure.  This gave me an idea for a post in the same sort of vein as the one I did about Moq.  Let’s do a deep dive into Autofac’s codebase using NDepend.

Continue reading Autofac: A Detailed Look Under the Hood at Its Code Quality

log4net vs NLog A Comparison of How They Affect Codebases

Log4net vs NLog: A Comparison of How They Affect Codebases

Ah, the old “versus” Google search.  Invariably, you’re in the research stage of some decision when you type this word into a search engine.  Probably not something like Coke vs Pepsi.  Maybe “C# vs Java for enterprise projects” or “angular vs react.”  Or if you landed here, perhaps you’re looking at “log4net vs NLog.”

With a search like this, you expect a certain standard script.  The writer should describe each one anecdotally, perhaps with a history.  Then comes the matrix with a list of features and checks and exes for each one, followed by a sober list of strengths and weaknesses.  Then, with a flourish, I should finish with a soggy conclusion that it really depends on your needs, but I maybe kinda sorta like one better.

I’m not going to do any of that. Continue reading Log4net vs NLog: A Comparison of How They Affect Codebases

Moq a Detailed Look at its Code Quality

Moq: A Detailed Look at Its Code Quality

In case you haven’t seen it, I’ve been doing a series of research-oriented posts for this blog.  This is going to be in the same vein but focused on the Moq codebase instead of focusing on hundreds of codebases.  Why Moq?  Well, I’ll get to that in a moment.

I started this by making a set of observations relating unit test prevalence to properties of clean code.  That generated considerable buzz, so I did some more studies in that vein, refining the methodology and adding codebases as we went.  By the end of the series, we’d grown the sample size to 500 codebases and started doing actual regression analysis.

Since then, we’ve enlisted the help of someone who specializes in data analysis to do some PCA with the data, which far outstrips my background studying data.  We brought this to bear in studying the effects of functional-style programming on codebases and also on categorizing codebases according to simple vs. complex and monolithic vs. decoupled, in addition to functional vs. OOP.  Doing this across more than 500 C# codebases has produced a wealth of information.

Okay, But How Does Moq Fit in?

I give you all this backstory in case you want to read about it but also to explain that I’ve looked at these codebases en masse.  With hundreds of codebases and millions of lines of code, I’m not going in and poking around to see if the code looks clean.  I’m using NDepend to perform large-scale robo-analysis.

And, while that’s been great, I started to want to see just how these categorizations stacked up.  So I started scrolling through the summary data and Moq jumped out at me.

First of all, I know Moq pretty well from using it over the years, and secondly, it had stood out when looking at the rate of unit test methods in the codebase.  Nearly half of its methods are test methods, which seems reasonable for a tool designed to help you write unit tests.  Combine that with these stats in the PCA:

So as a quick interpretation, Moq counts as reasonably non-monolithic, very simple, and very functional.  Add to that the high degree of unit testing, and I figured we’d have a codebase that was a joy to look at.  So I popped open the source code (as it was at the beginning of the year when I was grabbing codebases en masse) and analyzed it with NDepend, fresh off my excitement about using the new dark theme. I wanted to see if it was as much of a joy to look at as all of this data and statistical rigor indicated it would be.  And spoiler alert, it was the kind of codebase I’d feel right at home in.  Let’s take a tour.

NDepend Analysis, Test Coverage, and First Look

The first thing I wanted to look at was code coverage.  This was because I wanted a quick test case to see if my assumption that a high rate of test methods would correspond to high coverage.  And, it did.  Here’s a quick look at what happened after I imported coverage data and then ran analysis on the project.

Now I could see with Visual Studio’s coverage tool itself that Moq was sporting roughly a 90% test coverage.  But by importing the coverage data into NDepend, you can paint a much more compelling picture.

The heat map dominating most of the screen shows squares corresponding to methods in the codebase.  Larger squares are larger methods.  And the coloring indicates test coverage.  Over on the right, among the 2,152 methods in question, you can actually scroll through them in order of percent coverage and navigate to them if you want to take a look.

Taking a Look at the Dashboard and Technical Debt

So far, all systems go.  Most of the stats on the codebase looked good, coming in from the broad aggregates I have in a spreadsheet.  And then, following the same trend, Moq looks great in the IDE from a testing perspective.  But I looked at the dashboard and saw this:

Basic stats about the codebase lined up, and there’s the test coverage, hovering around 90%.  But a C for its tech debt rating?  10 critical rules violated?  This surprised me, given how rosy everything looked in the statistical analysis.  I drilled in to take a look.

And, sure enough, there be some dragons.  Huge types and overly complex methods are a problem.  Also in there are mutually dependent namespaces, which create coupling that hurts you as a codebase grows.  And you’ve got some hiding of base class methods and global state.  To get a sense for what I was looking at, I created another heat map. In this case, we’re looking at types.  The bigger the square, the more lines of code, and the closer to red, the more methods in that type.

This explains why the averages looked good in my spreadsheet but why NDepend has some objections and critical rules violated.  By and large, you have a lot of little green types, which is what you’d hope to see.  But there are some pretty hefty types in the mix, both in terms of lines of code to the type and number of methods to the type.

Some of these are gigantic unit test classes, while others are the API.  For those of you familiar with Moq, this should make sense to you.  Think of how many static methods you invoke on the Mock class. This illustrates the classic tradeoff between shooting for clean code guidelines about methods per type and such and between providing the API you want to furnish.

Drilling Into the Sources of Debt

NDepend has a view where you can drill into the technical debt per type or per method, and sort it accordingly.  I did that per type, and here’s what I saw:

No big surprise there.  The technical debt was coming disproportionately from these large types.  So I took advantage of another view to see where the debt was coming from, by rule violation. Here’s what that looked like:

Topping that list is a series of things that I would make it a priority to address in my own codebases, time permitting: types that are too big, types that have too many methods, namespace dependency cycles, and so on.  There is, however, one exception to what I would worry about as a top priority issue—visibility of nested types as a design choice.  That’s based on a Microsoft guideline and I don’t personally favor an approach where I use this a lot.  But it doesn’t bother me, either.

I see that the creators of Moq did that 395 times, so clearly they view it as a useful design choice.  This made me curious about what would happen to the tech debt grade if I disabled that particular rule.  So I did that, and the result was a somewhat greener and more pleasing grade of B:

What’s the Verdict With Moq?

I also spent some time scrolling through various classes and methods.  I didn’t want the entirety of the experience to be just a matter of data gathering since that’s what I’ve been doing for months.  And the verdict I have is that this particular data point fits in nicely with the aggregate.

Moq has excellent stats for most of what I’ve been looking at.  And, indeed, there are a lot of simple, functional methods in the codebase, almost all of which are thoroughly tested.  I would happily work in this codebase.

But NDepend is calling out real and important opportunities for improvement.  If I were working on this codebase, I’d make an effort to break some of those gigantic unit test classes into smaller ones that are more cohesive over their context.  I’d also take a hard look at the mutually dependent namespaces and either merge them or rework the dependency direction a bit.  And even I’d give some idle thought to how I might segment the large Mock class somehow into smaller chunks if that wound up making sense.

So the whole thing winds up being an interesting microcosm to me.  Moq is, as the stats would indicate, a pretty nice codebase.  But, as with just about any codebase, there’s plenty of room for improvement.  And having a tool to show you where to improve quickly is invaluable.

On the Superiority of the Visual Studio Dark Theme

When I downloaded the newest version of NDepend, something wonderful awaited me.  Was it support for the latest .NET Core version?  The addition of checks for ubiquitous language for DDD projects?  Any of the various rule additions or bug fixes?

Nope.  I’m a lot more superficial than that, apparently.  I saw this and was incredibly excited:

Dark Theme

In case you’re scratching your head and wondering, “what?” instead of sharing my delight, I’ll be more explicit.  NDepend added support for the Visual Studio dark theme.  And I absolutely love it.

Asserting the Superiority of the Visual Studio Dark Theme

Why so excited?  Well, as a connoisseur of the Visual Studio dark theme, this makes my experience with the tool just that much better.

Don’t get me wrong.  I didn’t mind the interface up until this release, per se.  I’ve happily used NDepend for years and never really thought about its color scheme.  But this version is the equivalent of someone going into my house where I already like the bathroom and installing a radiant floor.  I never knew I was missing it until I had it.

Everything in Visual Studio is better in the dark.

Oh, I know there’s evidence to the contrary.  People are, apparently, 26% more accurate when reading dark text on a light background than vice-versa. And it’s easier to focus on and remember text in a light theme.  I understand all of that.  And I don’t care.

The dark theme is still better.

Continue reading On the Superiority of the Visual Studio Dark Theme

Functional C# Improves Your Design without Making Your Code Cleaner, Exactly

Functional C# Improves Your Design Without Making Your Code Cleaner, Exactly

Today I offer another one of the code research posts we’ve been doing.  If you want more backstory on the series, check out the last post in the series, where I give a brief history.  You should also read it if you want to understand both what I mean by functional C# and for details about its impact on codebases at the method level.

Quick editorial note: a couple of people have commented/sent notes asking about p-values.  I’ve been eliding those to keep the posts more narrative.  But as we’ve expanded the set of variables we capture, we’ve been looking only at dramatically lower p-values.  Those cited in this post, for instance, range between 0 and 0.04, with most being less than 0.01.

I’ll summarize the last functional study here, briefly.  Last time, I studied about 500 codebases to see what functional-style programming did to methods and types.  And the answer was that it made them less object-oriented, but it had surprisingly little influence on clean code statistics, like

  • Lines of code per method or type.
  • Cyclomatic complexity.
  • Parameters per method.
  • Method nesting depth.
  • Methods per type.

I expected that functional codebases would correlate with a reduction in all of those things.  In other words, I figured that functional-style programming would lead to smaller, clearer, more focused, and less complex methods.  It didn’t.

Undaunted, I vowed to take a broader look at the effect of functional programming on a wider array of concerns. And I did just that, with the help of my partner who runs the statistical regressions. Continue reading Functional C# Improves Your Design Without Making Your Code Cleaner, Exactly