We know 2026 is not a leap year. But how do we know that? We need to call some function to find out.

Steve sends us a bit of representative code; on it's own, it's not so bad, but with the broader context, it's horrifying:

namespace Utils{
    public static class Utils
    {
        public static bool IsLeapYear(int year)
        {
            return CultureInfo.CurrentCulture.Calendar.IsLeapYear(year);
        }
        …
    }
}

CultureInfo.CurrentCulture.Calendar.IsLeapYear is a .Net built in function. It does what you think. This code wraps it in their own IsLeapYear function, in a class called Utils, in a namespace called Utils.

I think you can see where this is going: Utils.Utils is a "god" class that has all the random utility functions you might want in it. It basically wraps the .Net core library up in its own interface. Sure, it's only the parts that the application needs to use, but it's still a lot of useless code that just piles a big old heap of functions that could mostly be one-liners already in a big bucket.

And of course, not everyone follows this convention, which means that much of the code uses the core library directly, and much of it uses the Utils.Utils. The mixture creates a maintainability nightmare, and it shows: the application has an ever growing bug list.

[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.