C# Anti-Patterns: A List Of Programming Practices To Avoid

Welcome to the Basic Anti-Patterns section. I will give a quick introduction on how the section is organized before we get started.

The correct use of constants helps a lot to make your code more easily readable. Also, constants are super-handy when you need to make changes in the future. Instead of having to hunt through your code, finding each occurrence of a specific literal and changing it, you simply change the constant directly.

However, sometimes during a code review you encounter two extremes: code without any constants whatsoever, and code where literally everything has been turned into a constant.

In this lecture I will show you some code on the extreme ends of the scale, and I'll teach you some handy tips to find the sweet spot in the middle between these two extremes.

In the .NET Framework the Boolean type is a first class citizen. Both Boolean 'true' and 'false' values are explicitly defined and cannot be cast to integers. This is very different from the C language, where boolean 'true' and 'false' values correspond to certain integer values, and boolean values can be freely cast to integers and back.

C programmers making the transition to C# often retain certain defensive programming practices. These practices work well in C, but result in very strange C# code.

In this lecture I will teach you how to spot these practices. I will show you the line of thinking behind each defensive practice, and then teach you the correct way to program in C#.

The .NET Framework provides a very powerful DateTime type with lots of helper methods to manipulate date and time values, calculate timespans, find specific calendar dates, and much more.

But sometimes developers come from a much more restrictive language which offers almost no support for date and time operations. They develop convoluted workarounds to get around this limitation, and bring these code patterns to C#. This can result in some very weird code.

In this lecture I will show you an extremely bad and convoluted way to calculate this week's date range. Then I'll show you how to do it right by fully relying on the DateTime helper methods.

The .NET Framework features a Garbage Collector: an automatic process that identifies all variables that have gone out of scope and deallocates their corresponding objects. A C# developer never has to worry about deallocating variables. This happens automatically in the background, and the process is highly reliable.

But sometimes developers come from a more restrictive environment that doesn't have a Garbage Collector, and they get into the habit of manually deallocating all their variables. When they bring this practice to C#, the result is lots of redundant and unnecessary code.

In this lecture I will show you some code from a developer performing manual memory management, I will explain why the code is bad, and I'll show you what the correct equivalent code in C# should be.

Congratulations on finishing this section. This is a recap of what we have learned.

Sometimes a code review will expose very strange code. What would you say about a loop that only loops once, by design? What could possibly be the reason for writing code that way? Isn't a loop that loops only once every time completely redundant?

After completing this lecture you will have learned what the developers were trying to achieve with the loop, and where their line of thinking went wrong.

The singleton pattern is the black sheep of the patterns & practices community. Singletons were popular in the past, but today most developers agree that they are best avoided. That does not deter everybody though.

In this lecture I am going to show you a singleton from a code review that wraps the SmtpClient class. I'll demonstrate why this is a terrible idea, I will point out a nasty bug in the code, and I'll provide you with a scenario where the use of a singleton is still acceptable.

After completing this lecture you will have learned when using singletons is allowed, and how to correctly implement one yourself.

Sometimes we see expressions crop up in code reviews that look like this:

if (1 == variable) { ... }

The variable appears on the right hand side and the argument on the left hand side of the equals operator. We call this a 'Yoda expressions' after the famous Star Wars character who flips words around in his speech.

In this lecture you will learn why some developers use Yoda expressions, you will see why we consider them anti-patterns in C#, and I will show you a niche case where a Yoda expression is very useful and saves you an extra if statement.

Spaghetti code is very convoluted code that lacks a clear control structure. So obviously spaghetti code is considered an anti-pattern because the code is unreadable and hard to maintain.

But did you know that anyone can fall into the trap of producing unreadable spaghetti code? In this lecture I will show you how a simple process of repetitive code refactoring leads to spaghetti code, and how the code can be fixed by undoing the refactoring steps.

In this lecture I'm going to show you some bad date and time handling code that occasionally show up in code reviews. Sometimes a programmer will go to great trouble to simply copy one date into another. I'll show you the reasoning behind this practice, and why we consider it an anti-pattern in C#.

Other developers will repeatedly read from DateTime.Now or DateTime.Today to perform a date calculation. I will show you how this practice introduces a nasty bug where the calculation breaks down in a specific edge case.

In this lecture I will show you code from a real-life code review that does some very strange things with a property. At first glance the code appears to be completely broken. But then I'll show you some hidden functionality inside the property, and it turns out that all of our assumptions were incorrect.

By the end of the lecture you will have learned that properties with unexpected hidden functionality are considered anti-patterns, because they produce code that is extremely hard to maintain.

This classic anti-pattern is a very interesting one, because it involves the overuse of actual correct design patterns. A developer afflicted by Pattern Love will implement design patterns everywhere, including in places where they are completely inappropriate.

In this lecture I will show you how to spot Pattern Love in your own code. I will also show you a very interesting and somewhat convoluted application affected by Pattern Love, and I will teach you how to refactor Pattern Love code to resolve the anti-pattern.

Swiss-Army Knives are objects that try to do too many things at the same time. This leads to very confusing code that is hard to maintain.

In this lecture I will show you how to spot a Swiss-Army Knife object in your own code. I will demonstrate a stock trading application that contains a Swiss-Army Knife object, and I'll show you how you can easily recognise these objects in a class diagram.

Then we will refactor the code and resolve the anti-pattern by using the healthy 'facade' pattern. I will show you modified mutual fund code that accomplishes the same objective, but does not rely on a Swiss-Army Knife.

The Assume The Worst anti-pattern springs from an overly defensive mindset. In this pattern a developer is constantly writing defensive code that assumes an absolute worst-case scenario. This leads to code with an irrationally high amount of exception handling, or an architecture that is ridiculously over-engineered for its intended purpose.

In this lecture I will show you several examples of Assume The Worst code. Then I'll teach you which red flags to look out for, and how you can refactor Assume The Worst code to resolve the anti-pattern.

Crystal Balls are blocks of code that are overly generic and make wild assumptions about future developments, with little or no justification for the generic architecture.

In this lecture I will show you an order processing module that has been reused too many times and has turned into a crystal ball. I will teach you how to recognise crystal balls in your own code, and how you can use a very simple design principle from Extreme Programming to resolve this anti-pattern.

In this lecture I would like to thank you for finishing the course and offer some final words.