I wrote a few articles about design patterns. A few examples are the Repository Pattern (or the generic version) and the Strategy Pattern. Both are very effective when writing software. But I have also mentioned SOLID; a collection of design principles. But what is the difference between design patterns and design principles? When do we talk about a design pattern and when about a design principle?

Design patterns and design principles are here to help us make better code. One focuses more on the architecture and guidelines, the other focuses more on solutions in code. It’s important to know that we – developers – have some sort of guidelines and solutions as you go. But remember we are working with software: Expect the unexpected and not all environments are the same.

In my years as a developer, I have come across a lot of design patterns and design principles. Some are thought of by a team member and it works for that solution and some are defined by great minds, still maintained, and are used to this day. This article is about the latter.

Definition

Both design patterns and design principles have a different definition that already shows the big difference between them. A design pattern is a solution to a particular problem. Most definitions can be shown in code. Because it can be translated to code, the solution is usually reusable and helps to solve recurring design issues.

A design principle is a guide that explains certain solutions or guidelines to developers, making it easier to solve problems that might occur in code. These guidelines are here to help us prevent problems. Design problems help us create robust, maintainable, and flexible software. A design principle is not code, only theory.

Design Patterns

One of the most well-known design patterns is the Singleton Pattern. This pattern states and shows that a class should be initiated only once and this instance should be used throughout the application’s lifecycle. This pattern can be used in all programming languages that use classes and initiates classes.

Another example is the Strategy Pattern. This pattern is a behavioral pattern that enables dynamic selection and interchangeability of algorithms or strategies at runtime. You can simplify complex if-statements or make dynamic choices at runtime.

Other examples are the Observer pattern and the Factory pattern. But there are way more. You can divide them into 3 categories: Creational design, structural design, and behavioral design. The image below gives you a good idea of which patterns belong in what category.

It is (almost) impossible to know and learn them all. My advice: Learn the basic idea of them, know when you can use them, and figure out how they work when you are in a situation where you might think “Oh, I know a pattern for that!”

Design Principles

If you look at the design principles, we see other names coming up. Names like SOLID, DRY, KISS, and other funny-looking abbreviations.

DRY stands for Don’t Repeat Yourself, which states that you should not write duplicate code. Duplicate code can cause many problems when you have to change something. Avoid issues and write your code once and reuse it in other parts of your application.

KISS stands for Keep It Simple Stupid, although the last ‘s’ is removed in this day and age. This one states that code should be simple and understandable for others. The more complex you make it, the harder it becomes to understand.

SOLID is a collection of different principles: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, I could give examples for all of them, but then it would be a lot of reading for you (and writing for me). If you follow Wikipedia on SOLID, you will get a lot of information.

Applications

The moment you use a principle or pattern is different too. There is no one-size-fits-all solution and you might not use them at all. Design patterns are used during coding since they give solutions to certain code issues. Patterns can be added or removed along the way.

While creating software, your views might change (or those of a manager). This makes you decide differently and you might want to add or remove a pattern. This is okay. For example, a simple if-statement suddenly becomes this monster of if-elseif-elseif-elseif-elseif-etc. Then maybe it’s time to implement the strategy pattern.

Design principles are usually applied in the early stages of development. They are mostly about architectural design and planning. But also high-level designs. You can’t change these things when you are halfway through coding your application.

The Single Responsibility Principle (SRP) is pretty important. If you lose control of this one and classes and methods get multiple responsibilities, you might end up refactoring your code and breaking a lot of methods because the responsibility might be scattered across multiple methods and classes.

Conclusion On Design Patterns And Design Principles

Design patterns are proven solutions that can help solve reoccurring problems. Design principles are guidelines that can help you give structure and architecture to your software. That’s it, that’s all.

You don’t need to use all design patterns and design principles that exist. Using all SOLID principles in a single software application is nearly impossible. I managed it once, and that was a fairly small project.

It’s a good practice to look at the differences between design principles and design patterns and know when to use which one. Again, it is almost impossible to know all patterns and principles by heart, but know the names and the basic idea behind them.

Lately, I have seen a lot of articles about clean code. And that’s good! When I was teaching people asked me as well what my vision of clean code is. I never understood why people ask about ‘my vision’. I just read about Robert C. Martin, a.k.a. Uncle Bob, and apply clean code with C#.

But some people read a book and follow it as the bible of clean code. I believe there is more to it than just someone telling his best idea of clean code.

My Vision On Apply Clean Code With C#

My vision of clean code is based on experience and learning from others. I have a few ground ‘rules’ I stick to and try to teach that to others who are interested. These are not the only way to go and you may not agree with some, but the following tips are some I have been using for many years.

I will focus mostly on clean code with C#, since that is what language I generally use. But you can apply clean code in most languages.

The Team

Clean code is not some given book, like the 10 commandments. You will discover and develop it when you work your way up to being a good developer. Yes, there are good developers with terrible code who usually don’t work in a team. Because as a team you set certain ground rules on how team members should be making code. The idea of this is simple: Everyone in the team develops code in the same way, so everyone can read it, change it, and continue on it.

We call these ‘rules’ code styles. It’s most of the time a (digital) document that describes what kind of decisions the team has made on certain developing styles.

It can be about anything. Like using var or not, using brackets with a single-lined if statement or not, and declaring variables with capitals, underscores… Or not. But also things like the maximum number of parameters a method should receive.

This way the team members know how to develop certain codes. Sadly, I have seen this kind of coding style in 3 companies I worked for… Out of the 21. It usually caused frustration, (unresolved) discussions, and even a fight.

So, how to create this document of coding styles? Well, it starts with the team getting together and talking about the current code. Maybe some members have questions or disagreements about certain choices of other members. It’s not a race about who is right and who is wrong, but it’s about getting the team together in a way so everyone can read and understand the code. If two members of the team can’t agree, it’s usually the lead developer that makes the final decision.

Some Rules I use

Besides the team, it’s also important for you to make decisions on how to create clean code. If you are working on a project by yourself you could go with the flow and do whatever seems fit. But, what happens if someone comes and helps you? Or if you publish your code online, like in a question or tutorial?

So, to help you decide your way and the idea of clean code, here are the tips that I use.

To Var Or Not To Var

I think most of us developers know this discussion: Should we use var or explicit declaration? I’ve been using both because my employers asked me to. But when I work on a project by myself, I use var. Yes, past tense.

Using var looks like this:

var someString = "Hello world";
var client = new HttpClient();

Var is an alias of what’s on the right side of the =. So in the first line, var is a string. In the second line, var is an HTTPClient. A big advantage is that you don’t have to type the type twice. So… Var is for lazy people? Nah, it’s just easier. It’s not about being lazy or not. It’s a way of declaring a variable.

But it does make the code a little bit harder to read. If you use explicit declaration on the previous code it would look like this:

string someString = "Hello world";
HttpClient client = new HttpClient();

In the example above, you can see the types of variables quickly. This way of declaring a variable is enforced in example code in tutorials or teaching. Another advantage is that you can now remove the type on the right side and just type ‘new’. For example:

string someString = "Hello world";
HttpClient client = new();

This doesn’t work on the string since it doesn’t have an initializer.

I used var a lot, but I am using explicit way more. Why? The new way of initializing a type has become more efficient (read: less code) and it’s easier to read. In some cases I still use var, but that’s limited to unit tests.

Someone told me that using var was insufficient. Because the application has to convert the var to the actual type. This is not true; at compile time the var is being replaced by the actual type, making the var not insufficient when running the application.

Brackets

The use of brackets is well-known in C# and in other languages. It defines a block of code, like a method, class, if-statement, and so on. In some cases, you can remove the brackets.

We all know this piece of code:

if(val == "somestring")
{
    Console.WriteLine("Correct!");
}

A simple if-statement with one line within the block. But you can remove the brackets since there is just one line. The advantage is that you reduce the number of brackets, making the code look a bit cleaner and you can focus more on the code.

if(val == "somestring")
    Console.WriteLine("Correct!");

Maybe the example code does not really show the obvious reason for removing the brackets, so here is a bigger example with brackets:

string greeting = "Hello world";

if(greeting.GetType() == typeof(String))
{
    // Yes this is a string
    Console.WriteLine(greeting);
}
else
{
    Console.WriteLine("This is not a string.");
}

if(greeting.Length > 5)
{
    Console.WriteLine("The length of the greeting exceeds 5 characters.");
}
else
{
    Console.WriteLine(greeting);
}

It’s a simple piece of code of 20 lines. We can reduce the number of lines to 11 by simply removing the brackets:

string greeting = "Hello world";

if(greeting.GetType() == typeof(String))
    Console.WriteLine(greeting);
else
    Console.WriteLine("This is not a string.");

if(greeting.Length > 5)
    Console.WriteLine("The length of the greeting exceeds 5 characters.");
else
    Console.WriteLine(greeting);

The downside of this is when you add another line to the body of the if-statement. Brackets can be removed when you have just one line. If you add more you’ll need to add the brackets again.

string greeting = "Hello world";

if(greeting.GetType() == typeof(String))
    Console.WriteLine(greeting);
else
    Console.WriteLine("This is not a string.");
Console.WriteLine("Please use a string"); // This line will always be printed.

if(greeting.Length > 5)
    Console.WriteLine("The length of the greeting exceeds 5 characters.");
else
    Console.WriteLine(greeting);

Line 7 has been added. As you can see the line jumps to the left, showing you it’s not a part of the else-statement. Line 7 will always be executed, even when the greeting is a string.

I am not a fan of brackets as they kinda blur the code. I try to reduce the number of brackets to a minimum if possible. This usually also helps to notice other refactor options, like in the code above. We can reduce the number of lines even more.

string greeting = "Hello world";

if (greeting.GetType() == typeof(string) && greeting.Length <= 5)
    Console.WriteLine(greeting);
else if (greeting.Length > 5)
    Console.WriteLine("The length of the greeting exceeds 5 characters.");
else
    Console.WriteLine("This is not a string.");

When I apply clean code with C#, this is one of the things I look at.

Comments

I already posted a whole blog about comments and how (not) to use them. So here is a small summary.

Don’t use comments

…

Thank you.

Comments can blur the code, making it harder to read the code. The only times one should use comments are:

• When you work on a project alone.
• To write summaries in an interface.
• Explain a really hard calculation

Don’t use comments to:

• Explain the method.
  Maybe the name of your method is not correct.
• To mark you need to do something later.
  Use a scrum board for this.
•  Tell your team members to leave the code alone.

Camel case and Pascal case

• The way we declare variables, methods, and classes is important. Not only the name but also how we write them. It’s a convention so we can see what a specific name is. Camel and Pascal casing are a big part of this. They define how to use capital letters in a name:
• PascalCasing
• camelCasing

Here I follow the Microsoft code conventions, meaning I follow their view on when to use Pascal casing or when to use camel casing. There is a whole document you can follow on this topic. But it’s pretty simple:

• Public types are PascalCasing
  This includes, but is not limited to, classes, interfaces, methods, properties, and enums.
• Private types are camelCasing
  This includes but is not limited to, methods, variables, and private properties.

An example:

namespace ExampleCasing // namespace = PascalCasing
{
    // interface = PascalCasing. Mind the capital I and E.
    public interface IExampleClass 
    {
        string Name { get; set; }
    }

    public class ExampleClass // class = PascalCasing
    {
        public string Name { get; set; } // public property = PascalCasing
        private DateTime currentDateTime; // private class variable = camelCasing

        public ExampleClass() // class = PascalCasing
        {
            string exampleVariable = "Hello world"; // private variable = camelCasing
        }

        private void DoSomething() // private method = camelCasing
        {
            ...
        }
    }

    public enum Gender // enum = PascalCasing
    {
        Male,
        Female,
        Other
    }
}

Naming Conventions

To apply clean code with C# is much more than how you code. It’s also how you name variables, classes, and so on. Camel casing and Pascal casing are both parts of the naming convention. But there is more to naming convention than just these two.

There are a few rules I stick to:

• A name should be short.
  private void ExecuteSQLStatementOnSQLDatabaseThatIsLocatedInAzureWithAConnectionStringInAppSettings()
• A name should be explainable.
  private void Execute() … Execute what? 
  private void ExecuteSQLStatement()… Ah, that!
• Only use letters.
  Don’t use numbers, underscores, or other characters. Some are not even allowed.
  private void Execute_Sql_Statement().Exception on the unit test methods.
• Don’t use prefixes on variables
  string sGreeting = “Hello world”;
  var lAmount = 1029265527892;

Keep the words readable

A variable, class, or method name that consists of multiple words should have capitals on each word. For example:

private string helloWorld { get; set; } // Correct; capital W
private string executestatement() // Incorrect. The 's' of statement should be a capital S.
{
    ...
}

public class SomeNewClass // Correct
{

}

The reason why we do this is to make the names more readable. On line 2 for example. It’s harder to read since you need to look for the words. Lines 1 and 7 are easier.

Underscores

Microsoft coding conventions dictate that when you have private property on a class you should add an underscore as a prefix. This is one of the Microsoft ‘rules’ I don’t use. A variable written with camel casing shows that it is private.

public class ExampleClass
{
    private DateTime currentDateTime;
    private string _greetingText;
}

Method length

Some people say a method should be no longer than 5 rows of code. If that includes the brackets, I don’t know. What I do know is that it’s almost impossible to accomplish this. Yes, you can create hundreds of small methods, but does that help create clean code?

What I try to do is keep my methods between 10 and 20 lines of code, keeping the single responsibility principle in mind: A method or class should have one responsibility. Sometimes I go over those 20 lines of code, but usually with a reason. Don’t stress about it too much.

Tip: Just start writing code in one method. When everything works like it should, with unit tests, try to break up the method into smaller methods. In the end, you will end up with small methods with around 10 to 20 lines. This is a great way to apply clean code with C#.

Parameters length

A method can have parameters. I like to keep them to a minimum of 5, If a method gets more, I usually create an object that holds those parameters and uses that single object as a parameter variable.

Some people think 3 is the max, which is doable. Keep the single responsibility principle in mind. If you put properties together in one single object, that have nothing in common, you’ll break that principle.

Line length

Common practice dictates that lines of code should not exceed the screen. I am really struggling with that one.

What it means is that you don’t scroll in the editor and you keep all your code in view. This is almost impossible due to the different resolutions of screens. The resolution of my laptop is 1920×1080. But if someone has a lower resolution, let’s say 800×600, the code that looks fine on my screen might create a scrollbar on the lower resolution.

Another problem is Visual Studio or different editors in general. Take a look at the screenshot below, which is my Visual Studio.

Everything I need: Editor and Solution Explorer. Other windows, like the SQL browser, GIT, and Error List are not needed all the time, so I minimize or hide them.

No, take a look at the screen of someone who likes to keep track of everything:

Who decides the length of the lines? How many characters are allowed per line? My advice: Keep your editor clean.

Conclusion On Apply Clean Code With C#

These are basically the rules of clean code and coding conventions I try to follow. Again, these are things I learned during my work and what I have found. You don’t have to agree. If you have any ideas or add-ons, please let me know in the comments.

To apply clean code with C#, or any language, is a good way to keep your code maintainable and readable. Just don’t go berserk with it. Do what you can and don’t spend hours and hours to perfect your code. Perfect code doesn’t exist.