When naming variables is the only creative moment of your life (.NET)

How and what to name your variables in .NET

Introduction

“Naming a baby is an act of poetry, for many people the only creative moment of their lives.”
Coding is very opinionated. You’re asked to write some code to validate some acceptance criteria. If you’re an enthusiast like myself, you will try to find the ‘best’ implementation for your code… Turns out, there’s no perfect implementation and your manager commented on things you thought were the cleanest.
Naming variables are one of the most common and biased feedbacks, and yet they are present in every PR. So how do we tackle them objectively?

Why should we?

How many times did you run away from a big chunk of code that an old colleague of yours wrote years ago. This ball of bud basically sits in your application until you’re forced to take care of it.
You spent days analyzing and reading each algorithm when you just realize that all is it doing is adding items to a list. So here comes the hero of the day:
This is not understandable at all, I will write it from scratch and refactor it so that everyone can understand and evolve it.
After some time, someone from another team reaches out to you to understand what you wrote, you spend 2 3 hours explaining to him so that he can use it. So you decide to write an article documenting this chunk of code, and maintaining it on every change…

The Solution

Effectively, you want to write clean and structured code so that everyone can understand. One of the pioneers to achieve this is correctly naming your variables.

Naming Styles Conventions

In every language, one or multiple conventions exists as a set of rules to name variables in a defined context. In .NET, it started with Microsoft’s to then Resharper’s… C# and .NET changed a lot in the last years, and each one of them evolved differently.

Common and Agreed

Some rules are common, and agreed on upon industry. If your company does not accept those, you’re basically isolating yourself from the current standards and community like prefixing ‘_’ for private fields, camelCasing and PascalCasing, constants naming, prefixing interfaces with I. Grouping public and private methods…

Freestyle

Some of you might say that all this is not a big deal, I will share with you an example where naming conventions give a whole new sense now depending on the convention you are following.

In Microsoft’s, Nullable reference types like strings when defined normally are considered as ‘might be null’. For example, if you have:
private string _username;
The compiler determines this as a might be null normally. A reference can be null and can trigger a NullReferenceException if not assigned.

In Resharper’s, they actually enforce another approach where all types should not be null unless specified. How do we specify? we use the nullable operator ‘?’ to indicate that this variable might be null and we are aware of this.
private string? _username;
This approach and when used correctly, eliminate your chances of having a NullReferenceException without knowing why or null checking each and every function in your code to validate your context before executing.

While I am all in for enforcing this behavior, there’s ton of other behaviors and rules that can actually change the way you read and understand someone’s code. Part of your journey is to be flexible and write with different coding styles and common standards when needed.

And please, long descriptive name for your variables…