Stupid Question 43: Are utility, helper and or static classes and methods considered a code smell?

I definitely lean on the side of these things being code smells.  I've written about the topic here:

http://simpleprogrammer.com/2010/04/12/should-i-leave-that-helper-class/

And how to remove some of them here:

http://simpleprogrammer.com/2010/04/14/how-to-refactor-the-helper-class/

Now sometimes, you have to have a bit of a method that doesn't really belong somewhere else.  We can't be completely purist in our thinking here.

I strive to find a home for things that seem out of place.  I really want my connections between things in my system to be discoverable.  So, I'll try to think about some other responsibility the help method is doing.  Often times it has its own responsibility and can become its own class.  The class is light, but it is single purposed.

As for utility type methods, there isn't a great answer.  Extension methods are good, but not very discoverable.  I wrote about a way to make them more discoverable here:  http://simpleprogrammer.com/2012/01/05/no-class-is-an-island/

That is the best way I could come up with to keep the methods from being utility methods that someone has to know about.  That is the big problem with utility, helper and any static methods, someone has to know they exist.

Great question though.  This is a very tough question and is very situational.  (Sorry for all the links.) 

It depends on size of your project and should it be maintainable in the future or it is kind of projects you deploy and forget about. Because if you maintain it and going to add more features it could be easily become a mess. You find yourself trying to get through all these helpers/services/managers classes and you can have dozens of them. I try to left all domain related logic into the domain classes. With ORM tools like NHibernate your domain classes not have to be anemic. For example if there are a domain related rules for different kind of users sometimes it absolutely right to fulfill these rules in the User class itself. Lets say it is about VIP clients and additional service they get. 

Utility classes are great for common functions which are not related to object or group of similar objects. I think Convert static class with its methods is good example and it is not considered as code smell. Utility class should follow SoC as Convert does.

If you have common functions which are related to object or group of similar objects, but you dont need them to work with these objects directly. These method is not needed for its correct funcionality across application. Example is Enumerable static class. Good example can be extending int object with Odd and Even extension methods.

Helper classes are similiar(from my POV) to extension methods. Cant explain why. I try to not use them, but when some method HELPS me to code less I make one.

Static classes I use for cross app shared variables.

Uuhhh. 

I think it depends on the definition of a utility/ helper class.
For instance defining a DateUtilities class that can be accessed from multiple places in your code is ok, because you have a class that is concerned with a single area of responsibility, and it makes sense to have a class for that. (I work with some financial software, where such a class calcualtes date-differences, a persons age based on birthday and current date, finding the next date stocks can be traded based on a bank-day calendar).
You can of corse discuss if such a class should be called a utility class or class should simply be calls something like DateMath...

I have also seen utility class spring into existense because an existing class got too big, and simply was split in  two. That is not good. Another case is when some functionality in a class, suddenly is needed to be accessed from two places and out pops a utility "trashcan". That is also not good.

I think that with proper design, utility classes can be great - but maybe name them something other than utility or helper. A "StringHelper" indicates that it is a trashcan for anything string related, which is probably bad. But if you create a SocialSecurityNumber class for handling SSN strings and only that, then it is ok. 
But then you can discuss if it is a utility class at all... I guess not... Iris do you have an example of a utility class that you think is a code smell? It might be eaiser to discuss a concrete example.

There is nothing wrong with having stateless classes. Functions and algoritms need a place to live. There are also classes like that in the framework. For instance the Math class. Is the Math class a utility class? Why / why not? 

Sometimes the utility classes are a necessity. And I still struggle how to keep them discoverable enough.
I try to make my utility classes into extension methods when possible. And when I do I tend to group them either by related technology (WpfExtensions) or by the class I'm extending to virtually add methods to (StringExtensions and ArrayExtensions). By grouping them that way I frequently see them all popping up in IntelliSense, and keep them familiar.

Unlike the previous replies I think Convert and Math are two of the worst constructed utility classes in existence. 
IMHO Convert and Math have no reason to exist whatsoever. All of the Convert methods could easily be added as methods to existing types. (Convert.ToInt32(object o) could have been int.From(object o), and Math.Sin(double n) could just have been n.Sin(), perhaps even as the property n.Sin, since it's quite pure.)
Same goes for the Array class. 

My short answer to the question in the title is "yes, that is a code smell."  There's often a fine line between "this truly doesn't fit into any of my objects" and "I'm in kind of a hurry and don't want to spend time thinking about where this fits".

My longer answer is that everyone seems to be focusing on discoverability here, which is reasonable enough.  In the discoverability sense, static methods are hard to find, extension methods are better, and instance methods are probably best (assuming you have an instance).  But I'm going to suggest two additional considerations that haven't been touched upon (much).  

First, static methods are inherently procedural in nature.  When you write and consume a static method in C# you completely surrender any chance of polymorphism.  So, if you write Logger.Log() as a static method and use it in about 15,000 places throughout a project, your options are sort of unpleasant if you decide that you want to to be able to switch between a file logger and a console logger on the fly.  With an instance-based logger, you could swap out implementations of ILogger or derive one logger from the other and fulfill this requirement with one line of code change.  With the static logger, you are forced to choose between two bad alternatives: create a second static method and insert 15,000 if conditions in client code or add global state to the static class that determines which approach the static method takes. 

The second thing is what Michael calls a "trashcan" and touches on briefly (great term, by the way).  A class called FooUtils or FooHelper is an invitation to violate the single responsibility principle.  If you have a class like LeapYearFinder, you know exactly what kind of code ought to be in that class.  But if you have a class called DateUtils or DateHelper, what belongs in that class, according to its name?  Well, pretty much anything that has anything to do with dates that the author things would be useful or helpful.  When a class is described as "helper", there are no wrong answers to the question "what should I stick in there?"  I've rarely seen a class  with a name like that do anything but explode in size and scope over the course of time.

YMMV.  I avoid static methods because of these reasons and their negative impact on testability of code bases, but purism is rarely a good answer.  The nature of code smells means they may indicate a problem, but not necessarily.  Not all statics are a problem, and not all utils classes are a problem, but both are frequently abused, IMO. 

I've just been in and refactored out a helper class. Thanks all! 

Int explicitly implements methods of IConvertible interface. So, You can convert object directly without using Convert class.

I will take a look at Math class and I will respond. I didn't use it for whole my life. (so, why the object have to implement all of the stuff?)

Most of the devs don't think about small overheat, but too many of these made app slower for a bit.

My opinion and exps ;)