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?

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.

  • 1
    How about the Smurf Naming Convention?
    – back2dos
    Commented Jun 6, 2011 at 19:40
  • 4
    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... Commented Jun 6, 2011 at 21:11
  • 1
    oh by the way c2.com/cgi/wiki?DontNameClassesObjectManagerHandlerOrData
    – jhocking
    Commented Jun 6, 2011 at 21:37
  • 2
    @Aaronaught: Any suggestions? I've articulated this as well as I am able in the edit.... Commented Jun 6, 2011 at 23:51
  • 1
    @jhocking - I agree with some of that link - especially that bit about "Manager" and "Handler" being too valuable to let go. And I'm not that sold on the design-pattern-based and other alternatives, which seem at least as vague in many cases. Sometimes, "Queue" or whatever may be appropriate, but often the fact that a manager keeps (or references) items in a queue is only one aspect of managing those items. Just as something useful is expressed by "manager" as a job title, IMO the same applies in OOP.
    – user8709
    Commented Jun 7, 2011 at 13:10

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.
  • 8
    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. Commented Jun 6, 2011 at 18:45
  • 3
    +1 for "Ambiguos abbreviations with missing vowels" those drive me crazy! Commented Jun 6, 2011 at 18:48
  • 6
    @Billy ONeal: C++ has interfaces; they're just not artificially separated from classes. ;)
    – Jon Purdy
    Commented Jun 6, 2011 at 20:38
  • 4
    @Billy ONeal: That was my point.
    – Jon Purdy
    Commented Jun 6, 2011 at 21:33
  • 2
    @MariusSchulz: oh yeah, I agree with you :) Just thought it wasn't such a terribly opaque abbreviation.
    – amara
    Commented Jan 14, 2012 at 2:11

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.


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 )

  • 7
    Hungarian Notation is ALWAYS evil :) Commented Jun 6, 2011 at 18:20
  • 13
    @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. Commented Jun 6, 2011 at 18:36
  • 3
    @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. Commented Jun 6, 2011 at 18:53
  • 4
    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
    Commented Jun 6, 2011 at 19:32
  • 3
    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." Commented Jun 7, 2011 at 18:26


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.

  • 2
    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
    Commented Jun 7, 2011 at 1:35
  • 4
    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. Commented Jun 7, 2011 at 18:24
  • 1
    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
    Commented Jul 13, 2012 at 22:24
  • From my experience, if you are having problems like that you can easily fix it by learning Russian accent and keep saying to everyone that your first language is Russian, that would explain why you are making such mistakes. :) Commented Jul 15, 2021 at 4:17

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.

  • @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. Commented Jun 6, 2011 at 19:02
  • 1
    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
    Commented Jun 6, 2011 at 19:27
  • 1
    @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. Commented Jun 6, 2011 at 21:22
  • 2
    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
    Commented Jun 6, 2011 at 23:16
  • 1
    Whenever possible, interfaces should be preferred over concrete classes for argument types and return types. Therefore, it makes sense for interfaces to get the "clean" names, and the concrete implementations (the actual type of which the caller may not even know or care about) to get the warts. Commented Apr 27, 2016 at 6:20

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 ...

  • 1
    "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. Commented Jun 6, 2011 at 21:17
  • 3
    "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
    Commented Jun 6, 2011 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]

  • -1 -- this does not mention naming at all. Commented Jun 7, 2011 at 4:53
  • A naming anti-pattern can't include more than one name? Commented Jun 7, 2011 at 4:57
  • How does too many arguments == naming antipattern? I'm confused. Commented Jun 7, 2011 at 5:00
  • 1
    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
    Commented Jun 7, 2011 at 8:11
  • 3
    @Billy ONeal: Yes they do. The design problem is the lack of normalization, and the number suffixes are the naming pattern pointing to it. Commented Sep 14, 2011 at 7:33

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.

  • 2
    Interesting. Any examples? Commented Jun 6, 2011 at 21:54
  • 2
    I read the link, it says "tautology"... ;)
    – Benjol
    Commented Jun 7, 2011 at 5:44
  • 10
    The first rule of tautology club is the first rule of tautology club.
    – Cercerilla
    Commented Jun 7, 2011 at 6:03
  • I read the link (okay, the content of the link) and found no examples
    – barjak
    Commented Jun 7, 2011 at 12:23
  • okay so according to that link we should stop using I<InterfaceName> ... right. Commented Sep 14, 2011 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.

  • +1 - I see "Common" all the time.
    – user3792
    Commented Sep 14, 2011 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.
  • 3
    I actually like "ScrollableX" at least as much as "CanScrollHorizontally". "X" isn't really an abbreviation. Commented Feb 5, 2015 at 18:46
  • @user1172763 You'll like it up to the point where every co-worker asks what "X" means. Commented Aug 30, 2020 at 1:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.