C# Tip: do NOT use nameof to give constants a value

According to Microsoft’s definition,

A nameof expression produces the name of a variable, type, or member as the string constant.

This means you can get, for example

void Main()
{
    PrintItems("hello");
}

public void PrintItems(string items)
{
    Console.WriteLine(nameof(items));
}

to print “items”, not “hello”: This is because we are printing the variable name, items, and not its runtime value.

A true example I have seen in my career

In some of the projects I’ve worked on over the years, I’ve seen a strange approach that I strongly recommend against using: populating constants with the constant name itself:

const string User_Table = nameof(User_Table);

and then use the fixed name to access things in external, independent systems, such as API endpoints or databases:

const string User_Table = nameof(User_Table);

var users = db.GetAllFromTable(User_Table);

The reasons behind this, according to my team members, are that:

1. Easier to write
2. It’s more performant: we use constants that are populated at compile time, not at runtime
3. You can simply change the constant name if you need to access a new database table.

I don’t agree with them: Especially the third point is quite problematic.

Why not use this approach

We require data access to the name of a constant, not its value.

We could end up in big trouble because, overnight, the system might not be able to get to the user table because the name doesn’t exist.

how is it possible? It’s fixed, it can’t change! No: It’s a constant whose value changes if the content name changes.

This can change for several reasons:

1. A developer accidentally changes the name of the constant. For example, from User_Table To Users_Table.
2. An automatic tool (like Linter) with incorrect configurations updates the names of the constants: m User_Table To USER_TABLE.
3. New staff style guides are followed: If the new rule is that “constants must not contain hyphens” and you apply it everywhere, you’ll end up in trouble.

To me, these are valid reasons not to use nameof give value to determine.

How to overcome it

If this approach exists in your code base and it takes too long to update it everywhere, all is not lost.

You must do only one thing to avoid all the problems I mentioned above: Add tests, and check the actual value.

If you’re using Moq, for example, you should check the database access we saw earlier as:

[...]


_mockDb.Verify(db => db.GetAllFromTable("User_Table"));

Note it here You must check against the actual name of the table: if you write something like

_mockDb.Verify(db => db.GetAllFromTable(It.IsAny<string>()));

or

_mockDb.Verify(db => db.GetAllFromTable(DbAccessClass.User_Table));

The whole test becomes pointless.

Additional readings

This article is in the middle of my C# tips 🔗 and my clean code tips 🔗.

This article first appeared on Code4IT 🐧

finishing

In this article, we learned that you could have A constant value with its own name, using nameofbut also you Do not need.

Have you ever seen this attitude? In your opinion, what are some other pros and cons of this? Leave a comment below! 📩

I hope you enjoyed this article! Let’s keep in touch Twitter or on LinkedIn, If you want! 🤜🤛

Happy coding!

🐧