Take the 2-minute tour ×

There are some names, where if you find yourself reaching for those names, you know you've already messed something up.

For example:

This is bad because a class should describe what the class does. If the most specific word you can come up with for what the class does is "manage," then the class is too big.

What other naming anti-patterns exist?

EDIT: To clarify, I'm not asking "what names are bad" -- that question is entirely subjective and there's no way to answer it. I'm asking, "what names indicate overall design problems with the system." That is, if you find yourself wanting to call a component Xyz, that probably indicates the component is ill concieved. Also note here that there are exceptions to every rule -- I'm just looking for warning flags for when I really need to stop and rethink a design.

share|improve this question

closed as not constructive by Jarrod Roberson, gnat, Dynamic, Jim G., GlenH7 Sep 20 '12 at 19:52


How about the Smurf Naming Convention? –  back2dos Jun 6 '11 at 19:40
To those voting to close as "not constructive" -- would you be willing to explain the reason why? The only one this doesn't do too well with is that the answers can be short, but it certainly meets the other five guidelines... –  Billy ONeal Jun 6 '11 at 21:11
My problem isn't that the word "manager" is the most specific word I could use, I just have a bad habit of not thinking of a more specific term. When I say XxxManager I almost always mean XxxQueue or XxxCollection, or possibly even XxxTranslator –  jhocking Jun 6 '11 at 21:32
@Aaronaught: Any suggestions? I've articulated this as well as I am able in the edit.... –  Billy ONeal Jun 6 '11 at 23:51
@jhocking - that vagueness can be useful in OOP too. Requirements changes can result in changes to the specific responsibilities of a manager class, without making much (or any) difference from a callers perspective. –  Steve314 Jun 7 '11 at 19:19

10 Answers 10

The following naming anti-patterns are related to .NET and, especially, C#:

  • Inconsistencies. If you decided to start every field name with a leading underscore, stick to it.
  • Ambiguos abbreviations with missing vowels. I have seriously seen field names such as cxtCtrlMngr. You can hardly guess what what that is supposed to stand for.
  • Too long and verbose variable names. ILoginAttemptRepository is fine and descriptive — ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMapping is descriptive, but definitely not fine.
share|improve this answer
+1 Although long, descriptive names are good when applied well (e.g. EFLoginAttemptRepository : ILoginAttemptRepository to differentiate between a repository using EF and one using, say, NHibernate), but the example you gave is just crazy. –  Wayne M Jun 6 '11 at 18:37
Is I meant to mean interface here, implementer, or first person singular? Since most classes implement an interface, having too many classes/interafes startign with an capital I is anoying, and hindering readability, and a code smell on it's own. –  user unknown Jun 6 '11 at 18:45
+1 for "Ambiguos abbreviations with missing vowels" those drive me crazy! –  FrustratedWithFormsDesigner Jun 6 '11 at 18:48
@Billy ONeal: C++ has interfaces; they're just not artificially separated from classes. ;) –  Jon Purdy Jun 6 '11 at 20:38
@Billy ONeal: That was my point. –  Jon Purdy Jun 6 '11 at 21:33

One that I run into often is, simply, not using any naming pattern at all. Typically indicative of developer ignorance (that naming patterns are a good thing) and also this anti-pattern tends to grossly violate SRP by stuffing all kinds of methods that are kinda/sorta related to a class into that class itself, so for instance a Customer class has properties, CRUD methods, anything remotely related to a Customer that some part of the application needs.

I'll also add that using "Engine" as a suffix is about the same as using "Manager". It's very vague and a class called XxxEngine tends to be what amounts to a VB-style Module containing a bunch of methods so it's in one "easy to use" spot, without any knowledge or idea of object-oriented programming.

share|improve this answer

Well, simple answers first: type hungarian ( http://mindprod.com/jgloss/unmainnaming.html , also has some great other ideas. A more balanced view on when hungarian is not evil, http://www.joelonsoftware.com/articles/Wrong.html )

share|improve this answer
Hungarian Notation is ALWAYS evil :) –  Wayne M Jun 6 '11 at 18:20
@Wayne: Actually, it's not always evil. I worked for Charles at Xerox in the late 70's and the original naming system was a lifesaver. We were working in BCPL which has 1 type: integer. Everything else about type was conveyed by use and naming convention. We had 7 programmers + Charles and any one of us could walk into someone else's code and immediately be productive. This is not to say that it can't be horribly twisted/misapplied (even by Charles), just that in the right context it was the right solution. –  Peter Rowell Jun 6 '11 at 18:36
@Marius: Read Joel's article. The type system can't always enforce all semantic differences between variables. Intellisense doesn't help in such cases either. –  Billy ONeal Jun 6 '11 at 18:53
Type is easier to infer than use, esp. with modern editors. However, it requires discipline. You don't have to prefix everything. I work in Java, and most of the time apps Hungarian isn't necessary, but when I'm doing anything requiring several of the same type of variable (like fromX and toX) in coordinate systems it's a lifesaver. –  Michael K Jun 6 '11 at 19:32
What would be nice is a general ability to make new types easily. "This one is like an int, except that it applies to row numbers." –  David Thornley Jun 7 '11 at 18:26

Well I'm afraid my opinions are a little bit controversial. But lets try ...

As far as I'm concerned I have to agree with Mike Baranczak, names like XxxController, XxxHandler is something we really often use. For us a Controller is something like an entrypoint for something "encapsolated" e.g. managing transactions, dealing with unexpected errors, calling XxxHandler for doing the actual work. I would say a XxxManager is a synonym for a controller. I think its important not to use Manager in one case and Controller in an other. Being consistent is very important if you work in a team.

It would be really hard or maybe not even possible to find better names for stuff like this. Xxx should be well choosen to make the situation more clear.

What I personally do not like is, when a method called get... or set... is more than just a simple accessor. I like det... for determine.

An other thing, that comes into my mind: According to uncle Bob. An "And" in a method name is a sign of doing to much. But life is not always just black and white - there are situations where I think its ok - eg. due to performance issues (when you already have the data due to check why not process them) ...

I'm personally also a big fan of the systems hungarian notation - most of the time you are dealing with sourcecode in an IDE ok. But often you are using just an editor or you are browsing the repo in a browser. One disadvantage might be toolsupport due to type-prefixes ...

I think the most important thing is beeing consitent - a suboptimal convention - for me - is better than having no convention ...

share|improve this answer
"Controller" has different semantics than "Manager". Personally, I don't like either, but "Controller" gets by because it's a common component of many patterns, particularly MVC. XxxHandler is just as bad. If the class just "handles" something -- then either the class is too big, or it should just be called the "Xxx" part. –  Billy ONeal Jun 6 '11 at 21:17
"It would be really hard or maybe not even possible to find better names for stuff like this" - not if you designed your type hierarchy properly, with well-defined dependencies and responsibilities. Of course if you're using "Controller" as part of an MVC or "Handler" for a generic event/message handler then that's different - those are examples of jargon - but if they're just being used as generic names for ill-defined classes then that's a major red flag. –  Aaronaught Jun 6 '11 at 23:20

Perhaps the worst naming anti-pattern is this one:

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

We have a three-element list of [foo,bar] pairs. If we need a fourth, we will have to add new columns to the table.

Leading to code like this:

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

A separate table should be created with columns foo and bar and linked to the stuff table:

create table fubar(foo string, bar string, stuff_id long)

The second worst is this:

class Student {
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;

Here we have six fields instead of two instances of an Address class.

This anti-pattern is marked by a series of two-part names listing every combination of two sets, e.g. [foo, bar] x [1,2,3] or [home, perm] x [street, city, state]

share|improve this answer
-1 -- this does not mention naming at all. –  Billy ONeal Jun 7 '11 at 4:53
A naming anti-pattern can't include more than one name? –  kevin cline Jun 7 '11 at 4:57
How does too many arguments == naming antipattern? I'm confused. –  Billy ONeal Jun 7 '11 at 5:00
as far as i understand him, the convention is one that allows numbers where an actual name should be taken. These numbers lead to a false impression, that the items are some kind of list or array –  keppla Jun 7 '11 at 8:11
@Billy ONeal: Yes they do. The design problem is the lack of normalization, and the number suffixes are the naming pattern pointing to it. –  reinierpost Sep 14 '11 at 7:33

Prefixing an 'I' to the name of an interface, or 'Abstract' to the name of an abstract class. This might be excusable in languages that don't have the concept of abstract classes, or that don't differentiate between interfaces and abstract classes - but in Java, for example, it's always a bad idea.

Also, I don't agree with you on the Manager thing. I use that pattern sometimes, and it just means that if I tried to name it something else, then the name wouldn't be any more descriptive than XxxxxManager. There are some tasks (not necessarily complex ones) that just can't be summarized neatly in one or two words.

share|improve this answer
@Mike: I fully disagree with your statement, sorry. In my opinion, XxxxManager is the worst possible name a class can have. Of course it does manage something! That's the reason it was written for. Manager is a meaningless filler word that adds no value to understanding – by its name – what a class is responsible for. –  Marius Schulz Jun 6 '11 at 19:02
What about, say, TabManager? Got a better name for a class that controls a JSP tab mechanism? Or gasp TabController... As far as prefixing with Abstract, I feel it's overused but is often valid (see the Java libraries for examples). I think I can safely say that I've never seen I interfaces in any place where someone wasn't trying to program against an interface that shouldn't have been there. Like, only one class implements the interface. –  Michael K Jun 6 '11 at 19:27
I voted this up even though .NET conventions recommend using the I prefix for interfaces (Why I don't know, I presume to avoid the Java situation where you have to think of a generic name and a specific name, or worse use the dreaded Impl suffix). –  Wayne M Jun 6 '11 at 19:38
@Darien (And others): Either way -- it doesn't matter. None of those names are anti-patterns (and therefore they're off topic for this question). I don't think you can say anything about a system's design from whether or not they use IXxx or XxxImpl. –  Billy ONeal Jun 6 '11 at 21:22
This is just totally, utterly wrong. There are very good reasons to visually distinguish interfaces from classes: (a) they can't be instantiated, (b) they can't be freed/disposed, (c) they can't be serialized, (d) they can be proxied/intercepted, etc., etc., etc. You've just thrown out something you personally dislike (for some bizarre and unexplained reason) as an example of an anti-pattern without any justification at all. –  Aaronaught Jun 6 '11 at 23:16


I have a leaning disability and can't spell. With out the spell checker I am powerless I try to copy all the names I create to a word processor for verification but I always miss some. At my last project I wrote a large part of the api and I guess I didn't spell check the first time I used the word responce and I assumed it was right because no one told me. We had at least 50 functions with responce in it. A new person came on the team and asked why we use responce I felt real dumb.

share|improve this answer
I used a jQuery plugin briefly where the one of the parameters was affect (instead of effect). It drove me crazy and I quickly found a different plugin to do the same thing. –  zzzzBov Jun 7 '11 at 1:35
The worst problem I have with it is that, once I see a misspelled name, it really hurts my ability to remember what the names are. –  David Thornley Jun 7 '11 at 18:24
It gets worse when the same thing is spelled differently in different parts of the code. Like when you have a field strenght of class Srtength accessed by method getStrenth(). –  Eva Jul 13 '12 at 22:24

Any class or interface naming that is a tautology is a bad one, not just in Java which the link talks about, but in any language.

Tautology (rhetoric), using different words to say the same thing even if the repetition does not provide clarity.

share|improve this answer
Interesting. Any examples? –  Mike Baranczak Jun 6 '11 at 21:54
I read the link, it says "tautology"... ;) –  Benjol Jun 7 '11 at 5:44
The first rule of tautology club is the first rule of tautology club. –  Cercerilla Jun 7 '11 at 6:03
I read the link (okay, the content of the link) and found no examples –  barjak Jun 7 '11 at 12:23
okay so according to that link we should stop using I<InterfaceName> ... right. –  Dal Sep 14 '11 at 7:53

I frequently encounter software libraries with generic names such as Library or Common. They indicate suboptimal design: the developers make an effort to avoid code duplication but without any attempt to create a design decomposed on the basis of functionality.

share|improve this answer
+1 - I see "Common" all the time. –  Morgan Herlocker Sep 14 '11 at 13:22

From Microsoft on naming, I can provide this list for bad names:

  1. They are not semantic, which means that they have names which instead of emphasizing on what it does, emphasize on the technology it uses or the pattern it's based on.
  2. They don't follow a syntactical consistency. For example, part of names are camel cased, while other part is pascal cased.
  3. They are abbreviations, which are hard to understand, like ScrollableX instead of CanScrollHorizontally
  4. They're chosen such that they mess with the keywords of that environment.
share|improve this answer
