This is another RAMP51 best practices document.
In programming we use class names for expressing a purpose or a role that the class plays in the system. When the purpose of our code is clear the name also tends to be clear.
It’s common to hear advice that you should never name classes Helper or Utility. I think most of us agree.
In the .NET Framework Reference source for .NET 4.7.2 there are 20,176 files, among those files I found roughly 340 files named *Helper.cs
Microsoft is definitely a leader among leaders in terms of experience developing frameworks and SDKs for others to use and consume. So the collective intelligence of their developers and those that worked on the .NET Framework would seem to indicate that there were times where they wanted something named Helper.
I personally try to shy away from anything Helper because it’s easiest for its creator to understand what belongs in the Helper and what doesn’t, but less intuitive for your teammates.
Some times it’s definitely hard to find a name for one off utility methods. I guess we could glean from the .NET framework code base a ratio of Helper files to Non-Helper files, which would come out to roughly 1 helper file to 58 files that aren’t named helper. This obviously assumes code files are spread evenly across all assemblies and namespaces, which we know is not the case.
How many “Helper” or “Utility” files do you expect to see in your solutions? In the classic ASP days I remember having one “junk drawer” include that just was a grab bag of utility functions, and it worked ok. Often code would be duplicated though. With today’s SAST tools we’d find these duplications fairly quickly. Does it make sense to have junk drawer now? Or is nuget simply the junk drawer? I’m still trying to name everything with a specific purpose in it’s context to inform future developers as to the intent of how functionality should be maintained and enhanced. So for now, I’m still keeping the junk drawer at home.