Utility classes are wrong by nature: instead of containing something specific, such as arbitrary precision arithmetic, they rather contain everything which hasn't found its way in other classes.

Using the same name for the namespace and the class inside it is also a sign of a problem. If the namespace contains more than one class, why would other classes be put there? For instance, what would you think of a namespace File containing classes related to operations with files, but also other classes related to directories? Would you intuitively search the File namespace when you need to work with directories?

If there is only one class, it might be a sign of an issue within the code organization, just as when you have too many classes within the namespace.

Using the same name for the namespace and the class inside it is problematic.

• If the namespace contains more than one class, why would other classes be put there? it doesn't feel right, because the goal of the name of the namespace is to describe all the classes within it, not just one. For instance, if you have JsonSerialization, BinarySerialization and XmlSerialization classes in a namespace, would it make sense to name your namespace XmlSerialization?

  What usually happens is that due to an extraction of a class from an existent namespace, or a merge between multiple classes or other reorganization, you find yourself with a namespace containing a major class; progressively, minor classes are put there because they are slightly related to the original class. For instance, a namespace LogParser may contain a single class LogParser, and then somebody puts LogConverter, because it's quite related to the parser, then LogSearcher, etc. The problem here is that the name of the namespace wasn't changed: as soon as LogConverter was added, the name should have been changed to LogsProcessing or, simply, Logs.

• If the namespace contains only one class, it might be a sign of an issue within the code organization.

  While I've seen a few times the situations where a single class with proper SOLID principles was very different from anything else in the code base and was therefore put in a dedicated namespace, such cases are rare. More often, this is indicative of a problem. Similarly, nothing prevents you from having a class containing a single method, but more often than not, such classes would indicate a problem.

  Even if your namespace contains only one class, there is usually a way to be more specific when naming the class, and more general when naming the namespace. Imagine an application which, among other things, should at a given moment convert files written in ABC format to DEF format. The conversion doesn't require any deserialization/serialization to/from the business objects, and is done by applying a bunch of regular expressions which are short enough to be put within the conversion class itself called AbcToDefConverter. All the conversion logic takes about 80 LLOC in about ten interdependent methods—seems like a situation where there is absolutely no need neither to split the existent class, nor create additional classes. Since the remaining part of the application has nothing to do with conversions, the class cannot be grouped with other classes in existent namespaces. So one creates a namespace called AbcToDefConverter. While there is nothing inherently wrong in that, one could also use a more generic name, such as Converters. In languages such as Python, where shorter names are preferred and repetition is thrown upon, it may even become converters.Abc_To_Def.

Therefore, do use different names for namespaces than for the classes they contain. The name of a class should indicate what the class is doing, while the name of the namespace should highlight what's common in all the classes put within it.

By the way, utility classes are wrong by nature: instead of containing something specific, such as arbitrary precision arithmetic, they rather contain everything which hasn't found its way in other classes. This is simply bad naming, just as a Miscellaneous directory on a desktop—something which is indicative of the lack of organization.

Naming exists for a reason: to make your life easier when you need to find stuff later. You know that if you need to draw a chart, you may try to search for “chart” or “plot”. When you need to change the way an app generates invoices, you'll search for “invoic[e/ing]” or “bill”. Similarly, try to imagine a case where you'll say to yourself: “hm, this feature should probably be found in misc”. I can't.

Look at .NET Framework. Aren't most of those classes utility classes? I mean, they have few things to do with the business domain. If I work on a financial app, or an e-commerce website, or the next gen education platform, serializing XML or reading files or doing SQL queries or performing transactions is all utility stuff. However, they are not called UtilitySerialization or UtilityTransaction, and they are not in the Utility namespace. They have proper names, which make it possible (and easy, thanks .NET developers!) to find them when I need them.

The same comes for your classes you commonly reuse in your apps. They are not utility classes. They are classes which do certain things, and the things they do should actually be the names of the classes.

Imagine you created some code which deals with units and conversion of units. You may name it Utility and be hated by your colleagues; or you may name it Units and UnitsConversion.

Utility classes ate wrong by nature  : instead of containing something specific, such as arbitrary precision arithmetic, they rather contain everything which haven't found its way in other classes.

Using the same name for the namespace and the class inside it is also a sign of a problem. If the namespace contains more than one class, why would other classes be put there? For instance, what would you think of a namespace File containing classes related to operations with files, but also other classes related to directories? Would you intuitively search the File namespace when you need to work with directories?

If there is only one class, it might be a sign of an issue within the code organization, just as when you have too many classes within the namespace.

Utility classes are wrong by nature: instead of containing something specific, such as arbitrary precision arithmetic, they rather contain everything which hasn't found its way in other classes.

Using the same name for the namespace and the class inside it is also a sign of a problem. If the namespace contains more than one class, why would other classes be put there? For instance, what would you think of a namespace File containing classes related to operations with files, but also other classes related to directories? Would you intuitively search the File namespace when you need to work with directories?

If there is only one class, it might be a sign of an issue within the code organization, just as when you have too many classes within the namespace.