NDepend

Improve your .NET code quality with NDepend

When_Is_It_Okay_to_Use_a_C#_Partial_Class

When Is It Okay to Use a C# Partial Class?

Today’s post attempts to answer a very simple and straightforward question: “When is it OK to use a C# partial class?” And the answer as straightforward as this: “When you need to allow the user to edit code that was automatically generated.”

Whoa, that was hands down the easiest post I’ve ever written. So, that’s it for today, folks. Thanks for reading and see you next time!

OK, I’m just kidding, of course. If you’ve found this page by googling around on “C# partial class,” chances are you have a number of questions regarding this topic. For starters, what is a partial class? How do you actually use it? Are there any restrictions regarding its use? And the list could go on.

That’s what today’s post is all about. We’ll start out by explaining what a partial class is and providing some examples. Then, we’ll go a little bit deeper, giving a more detailed view of the partial class, its inner workings, and the rules that must be followed when using it.

Finally, we’ll explain the main use case for the C# partial class, nicely tying the end of the post to its beginning.

Continue reading When Is It Okay to Use a C# Partial Class?

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

programming_to_an_interface_simple_explanation_ndepend

Programming to an Interface: A Simple Explanation

As an architect, you know that programming to an interface is good. It’s what everyone should do.

But what does that mean? And why should you do it?

Searching the Internet for answers might only cause more confusion. There, you’ll find people arguing over what “programming to an interface” really means. And how everyone else is wrong about it. Yet everyone’s definition sounds pretty much the same. But is supposedly different. Somehow.

Let’s remove the confusion and break it down. In this post, we’ll look at what it means to program to an interface and why you should do it.

Continue reading Programming to an Interface: A Simple Explanation

what_is_a_good_unit_test

What Is a Good Unit Test? 5 Must-Haves

In this day and age, unit testing isn’t as controversial as it once was. Sure, you still see the occasional inflammatory, clickbait-y, confrontational “unit testing is garbage” type of post on Reddit and Hacker News.

And there are still developers out there ignorant of the existence of unit testing—or any type of automated testing, for what it’s worth. Believe it or not.

However, if we consider the developers that do know about unit testing, I’d say the debate is pretty much over. It’s generally agreed, today, that unit testing has a positive influence on software projects.

With that in mind, the next question then becomes “what makes for a good unit test?” That’s what this post is all about. Today, we present you five must-haves for a great unit test.

Continue reading What Is a Good Unit Test? 5 Must-Haves

layered_architecture_solid_aproach_ndepend

Layered Architecture: Still a Solid Approach

Layered architecture gets a lot of flack.

Even though it’s still the most prevalent architecture, we view it as an anti-pattern. It’s old, not scaleable, and anti-SOLID. It encourages (shudder) monoliths!

Yes, I know. Hexagonal architecture is the way to go. Or maybe I’m feeling a taste for onions. But only if it’s clean!

The point is that even though it may not be an object-oriented nirvana, layered architecture is still a useful pattern. And if done right, it paves the way towards more advanced designs and architecture.

So let’s talk about layers.

Continue reading Layered Architecture: Still a Solid Approach

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