Is the C# internal keyword a code smell?

Is the C# internal keyword a code smell?

In this post, I am going to show why I think the internal keyword, when put on class members, is a code smell and suggest better alternatives.

This is a companion discussion topic for the original entry at

Here are six reasons to ditch the term code smell altogether:

  1. It’s demeaning.
  2. It’s condescending and lazy.
  3. It’s non-specific.
  4. It’s smug.
  5. It’s disgusting.
  6. It promotes black and white thinking.

Receiving feedback should not be a visceral experience. As a working programmer I don’t use this term. I rarely—if ever—hear it used by colleagues for whom I have respect, and actively discourage its use among colleagues that I mentor.

I disagree on a few things with this article. I use it to discourage people from trying to declare certain things manually. Why? Work with people enough and you’ll find out that people bypass IoC. You’ll see.

I would definitely not recommend to use it like that: just occasionally in certain parts of the code.

In my previous project, every project in the solution had 2 parts: Interfaces and the rest. Everything in the Interfaces was public and properly documented. The rest was all internal. Only the unit test project for that project was allowed to see the internals.

This approach worked very well for us, we even had sonar qube rules to make sure this rule was followed.

Besides the over simplicity of the post, the real code smell is formatting C# as javascript

First, why the assumption that the interface will (should) never be mocked? Using an internal class to fulfill and public interface works fine if there is some factory to provide the instance. In fact, this could be a great example of encapsulation.

Second, another use of the internal access would be if you exposed a class from Entity Framework and wanted to protect the key from being set outside the assembly. This will bring some other restrictions but could be a very valid method.