Skip to content

+15 (Important) Tips to Writing Clean C# Code in 2022

9 de February de 2022
.net tricks c# programming tips

One of the most important skills of a C# programmer is writing clean, efficient code that performs well and can be easily maintained by others who will inherit your code after you’ve moved on to other projects. This can seem like an impossible task, as there are many factors to consider when writing C# code, including variables, methods, classes, and types, just to name a few. But with these c# tips and tricks, you can learn how to write clean C# code that’s easy to read and understand by others on your team.

Index

Use variable names that are easy to remember

This malpractice is one of the most common. Many times we — the .NET developers — want to complicate a lot when in most of the occasions it is not necessary.

When declaring a variable, we should use a name that makes sense, that is easy to remember and that is easy to pronounce.

Bad way:

Good way:

This does not seem to be important, but once the project develops and becomes larger, the number of variables will be very large. And we all know that when we open a project after a long time without opening it, many times we don’t know what some part of the code does.

Use variable names with the same structure

Many times it has happened to us that we declare variables but we declare each one with a different structure or — lexically speaking — with a different vocabulary. Let me explain:

We should always look for the greatest simplicity. We should always use the same word and not vary it — I mean synonyms. Let’s see a practical example.

Bad way:

Good way:

In that example, we can clearly see that in the bad way we are using different synonyms for the same word. This may cause confusion in the future, both for the current developer and for the (possible) future developer who will have to understand the code.

Use searchable names

I am sure that more than once you forget where something is and you start looking for that something but you can’t find it because you don’t remember what name you gave to the variable or directly, you don’t remember if you named that constant. For your better understanding:

Bad way:

Good way:

This small practice, although it may not seem like it at the time, will save us many hours of searching and quite a few headaches (both for us, the current developers, and for potential future developers). Remember: The easier to read code, the better.

Don’t repeat yourself (DRY)

This error is very common because we unconsciously repeat names or words. This bad practice in the long run makes you have a very dirty code since there will be many things that will be repeated. Let’s get down to practice:

Bad way:

Good way:

In this way we can see that by spending less time thinking and writing, we get a much cleaner and easier to read code (which we will thank ourselves in the future for having done).

Uses highly descriptive variable names

Another bad practice is to send functions directly as an argument of another function. This only causes a lot of confusion and makes our heads hotter than an old AMD FX series processor.

Bad way:

Good way:

The solution, as we can see, is to add the resulting values in variables and then send those variables to the function. This will allow us to understand in a simpler way the information that you are sending to it and besides, we will save a Noctua heatsink for our head.

Always encapsulate conditionals

Encapsulation is a way that helps isolate implementation details from the behavior exposed to clients of another class.

Bad way:

Good way:

Also, encapsulation allows for greater control over the coupling of the code being written.

Use private/protected members

By not using private/protected members, they are susceptible to being modified (accidentally or unintentionally) and this can cause errors in the code.

We have to keep in mind that we are responsible for the permissions we give in the code. This may seem a bit abstract, but if a string must be read only, specifying that it is read only and not write, is your obligation.

Bad way:

Good way:

By not using set; we prevent it from being accidentally modified in the future.

Learn to use setters and getters

Many times we do not set public, private or protected methods. This prevents us from better controlling the modification of the object’s properties.

Bad way:

Good way:

Also, when inheriting that class, by default, there is the possibility to override that functionality. The possibilities that this allows you are many.

Composition is better than inheritance

Although many do not know whether to use inheritance or composition, let me tell you that it is better to choose to use composition.

At first, many programmers think that inheritance is better but, you always have to ask yourself if composition could somehow model the problem better.

Bad way:

Good way:

To know when it is best to use which one, let’s look at a quick example:

  • Relationship “is-a” (Human-Animal)
  • Relationship “has-a” (User-UserDetails)

Don’t use magic chains

For those who do not know this, magic strings are string values that must be specified in the code. They always generate an impact on the code. In most cases, magic strings end up almost always duplicating themselves and because they cannot be updated automatically, they are susceptible to being a source of errors.

Bad way:

Good way:

In this way, we will prevent these strings from being duplicated and causing errors in case of making any change in any of them.

I know these little tips are pretty simple (although I’m sure not all of you will follow them😏). The number of ways to write cleaner code in C# is more infinite than the universe. So, I’m going to make a list of Cleaner C# Code articles, in which, we will touch on more advanced tips and some other tricks to improve the quality of our code.

Limiting function arguments

It is very important to limit the number of parameters that a function has. Remember: The simpler, the better. The problem comes when a function has more than 3 arguments, because it can cause many problems in understanding what it does.

Bad way:

Good way:

The best option is to use 1 or 2 arguments. Can you use more? Of course you can, but only if you are aware that in a couple of months you will have to figure out what is supposed to do what. The ideal would be to group when there are 3 or more.

If you have more than 2 arguments in your function, it means that function is doing too many things.

Name the functions with what they do

Another bad practice is to name functions with incorrect or incomplete names. Just by reading the name of the function we should know almost 100% of what EXACTLY it does, otherwise this only causes confusion.

Bad way:

Good way:

The best recommendation is to spend a little more time thinking of a name that is very descriptive for the function. If you don’t do this good practice — just to save a couple of seconds in defining a good name, you will waste a lot more time in the future reading those lines of code and trying to understand what they do.

Never save unused code

This bad practice reminds me of when we keep or collect “stuff” at home but never make use of it. This is the same, if you have code that is not used, delete it. There is no point in having it taking up space and bothering you.

Bad way:

Good way:

Remember: Don’t bite off more than you can chew. If you haven’t used that code, there’s no point in keeping it there. You can still check it again in the version history in case you ever need it.

One level of abstraction per function

If you are developing and you find that a function does not have only one level of abstraction, but has several, this means that the function is doing too many things by itself.

This bad practice, apart from in the future generating questions like: What is this? What exactly does it do? It makes it difficult to reuse code because it does many things at the same time.

Bad way:

Good way:

This, apart from leaving the code cleaner, will allow you to reuse code and test it (which you could not do properly before due to the large amount of things the function does).

Never write in global functions

This bad practice consists of “contaminating” the globals. This is not a good thing because you could have problems and even crash with another library. Any user could run into this problem and would not realize it until the exception occurred.

Bad way:

Good way:

After this, we load the configuration and when it is ready, we create an instance of the Configurationclass

Now yes, in the application, we should use one instance of Configuration

Settings