There is a very simple thing to do to rationalize a code base: making sure that every methods, fields and types have an optimal visibility. For example, if a method is declared internal but is not used outside its declaring type, it should be declared private. For such method the private visibility is its optimal one. Rationalizing a code base with optimal visibility help protecting from potential flaw. For example having optimal visibility can avoid improper coupling with a class that should have been declared internal as soon as it was developed.

Since the early days of NDepend, the tool was able to tell which code elements do not have optimal visibility. We now moved this feature into Code Query Language v1.5 with the following CQL conditions:

CouldBeInternal, CoulBeInternalProtected,  CouldBeProtected, CouldBePrivate and ShouldBePublic.

The default set of CQL constraints comes with a new Optimal Encapsulation group that contains constraints such as…

SELECT METHODS WHERE CouldBePrivate

…and that you can adapt to suit the needs of your own code base…

SELECT METHODS OUT OF NAMESPACES "MyNamespace1", "MyNamespace2" WHERE CouldBePrivate AND !NameLike "MyMethodsThatIDontWantToBePrivate"…

Of course, if your code base is a framework, there are chances that the query…

SELECT METHODS WHERE CouldBeInternal

…returns a lot of public methods that are not used by your code base, but that should remain public anyway because some external client code relies on it. In this case, just discard this query.

What about the condition ShouldBePublic? This condition matches types, methods and fields that are declared as internal but that are used by code declared in other assemblies thanks to the attribute System.Compilers.Services.InternalsVisibleToAttribute. In general, having code elements that are considered as ShouldBePublic is not a problem because it is made on purpose. However, it can be interesting to list them.

The condition CoulBeInternal can also apply to namespaces although .NET languages (C#, VB.NET etc) don’t allow visibility modifier on namespaces. A namespace is considered as CoulBeInternal if it contains only types that are used internally and if at least one of its types is declared as public.

SELECT NAMESPACES WHERE CouldBeInternal

While developing the optimal visibility feature, we notice an interesting thing. When you declare an internal class without  an explicit constructor, the default constructor automatically provided by the C# compiler is public. NDepend will tell you to declare explicitly an internal constructor but beware here: having a default internal constructor can sometime lead to serialization issues.