NDepend

Improve your .NET code quality with NDepend

C#_Features_A_List_of_the_Best_Ones

C# Features: An Exhaustive List of the Best Ones

The first post I wrote for the NDepend blog was about C# 8.0 features. That post inspired a sequel, followed by the series’ final chapter. Those posts dealt with the future. Today’s post, on the other hand, is all about what’s already here. I’ll make a list of the C# features I consider to be some of the best ones. For brevity’s sake, I’ll do the briefest overview of each feature, though.
Also, be warned: I’m going to use “C# feature” loosely throughout this post. So you’ll see some items that are, technically, .NET frameworks features. The reason for this choice is that, for many developers, C# and .NET are interchangeable. That’s the way they think, talk, and google about this topic.
Without further ado, let’s dive into it.

Continue reading C# Features: An Exhaustive List of the Best Ones

Visual_Studio_Enterprise_vs._Professional_Essential_Differences

Visual Studio Enterprise vs. Professional: Essential Differences

If you’re a .NET developer, then it’s overwhelmingly likely that you’re a Visual Studio user. There are alternatives to it, sure. But the product from the Redmond giant is the go-to when it comes to developing for the .NET framework.

For a newcomer, though, things can get confusing since Visual Studio isn’t a single thing. Instead, it comes in several shapes and sizes. Which one should you pick? What are the features that matter for your use case? Since Visual Studio isn’t free—most editions aren’t, at least—you want to get the best bang for your buck.

That’s what this post is going to cover. As its title suggests, we’ll focus on the differences between the enterprise and professional editions of the integrated development environment (IDE). By the end of the post, you’ll have learned enough to make an informed decision on which version of the IDE better suits your needs. Let’s get started.

Continue reading Visual Studio Enterprise vs. Professional: Essential Differences

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?

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

design_patters_that_have_aged_poorly_ndepend

3 Design Patterns That Have Aged Poorly

Design patterns seem to be a controversial topic. On one hand, many developers seem to love them and treat the famous book by the Gang of Four like sacred scripture. On the other hand, many developers loath the very idea of design patterns. It’s not too hard to find posts around the web with titles such as “Design Patterns are Bad Design,” “Following Design Patterns Is A Bad Idea,” and of course, the inevitable “Design Patterns Considered Harmful.”

What can we take from that? Well, as it is with pretty much everything in our industry, it’s really hard to reach some form of consensus on design patterns. My take is this: design patterns are tools. Some are more useful, others less useful. Some may be outright harmful. And others may not make sense for your scenario, but maybe for Joe who sits three desks from you, they’re a gift from heaven.

But that’s not what this post is really about (i.e. deciding whether design patterns are “good” or “bad”). As we’ve seen, such discussion is simplistic and misses the point.

What we’re going to do instead is cover three design patterns that haven’t aged quite well. These design patterns are ones that you no longer go around implementing. And if you do, you probably shouldn’t.

Let’s get started.

Continue reading 3 Design Patterns That Have Aged Poorly

Continuing Our Clean Architecture Example in C Sharp

Continuing Our Clean Architecture Example in C#

After a somewhat long delay, it’s time to finally continue our series on clean architecture. This is the second post in the inner series in which we show you a quick implementation of said architecture and the third post in the overall series. In case you haven’t read the previous posts, please do so by using the links in the series layout below:

Without further ado, let’s continue our implementation.

Continue reading Continuing Our Clean Architecture Example in C#

Text over the depths of the ocean

Imperative Programming in Depth

Programming languages come in all shapes and sizes: interpreted vs. compiled, weak vs. strong typing, low-level vs. high-level, terse vs. expressive… There are many buckets you can put a programming language into, even though not all are equally meaningful.

One very common way people classify languages is to organize them into paradigms. You can think of a paradigm as a group of languages that share similar characteristics. There are many paradigms currently in use: procedural, functional, and object-oriented. Many of these terms are often misused or confused; there’s also some degree of overlap between different paradigms, which definitely doesn’t make things easier.

Add all of that together and what you get is a landscape that’s not too easy for a beginner to grasp.  In today’s post, we’ll try and fix this situation by giving you a clear picture of the imperative programming paradigm.

Continue reading Imperative Programming in Depth

Separation of Concerns layered over dripping yellow liquid

Separation of Concerns, Explained

Software development is a very young field, particularly when you compare it to, say, medicine or law. Despite this, there’s no shortage of wisdom pearls, which accumulated in the decades that preceded us.

One interesting phenomenon I’ve observed in myself over the years—and I’m sure there’s a name for it—is that some of these sayings sound like they must be right, even if I don’t really understand them the first time I hear them. For instance, in my post about the SOLID principles, I mentioned how the SRP’s definition—”each class should have just one reason to change”—just ticks the right boxes for me in some way that I can’t even pinpoint. 

Unfortunately, just hearing a phrase and acknowledging that it kind of sounds right doesn’t do much to really make you understand the topic, right?

Then why do so many in our industry act like that’s the case? I’ve lost count of how many times I’ve seen experienced developers toss around catchphrases like this as if they’re able to automatically inject the necessary information into beginners’ heads.

In this spirit, I’ve decided to demystify one of these catchphrases that happens to be one of my favorites: “Separation of Concerns.” What does that mean and why should you care? That’s what today’s post is all about.

Continue reading Separation of Concerns, Explained

Null Is Evil. What's the Best Alternative Null

Null Is Evil. What’s the Best Alternative? Null.

“Null is evil.” If you’ve been a software developer for any reasonable length of time, I bet you’ve come across that statement several times.

I’d say it’s also very likely that you agree with the sentiment, i.e., that the null reference is a feature our programming languages would be better off without. Even its creator has expressed regret over the null reference, famously calling it his “billion-dollar mistake.”

Bashing poor old null tends to get old, so authors don’t do just that. They also offer alternatives. And while I do believe that many of the presented alternatives have their merits, I also think we may have overlooked the best solution for the whole thing.

In this post, we’re going to examine some of the common alternatives for returning null before making the argument that the best alternative is null itself. Let’s get started! Continue reading Null Is Evil. What’s the Best Alternative? Null.