What naming anti-patterns exist? [closed]

Question

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

For example:

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

Answer 1

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.

Answer 2

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.

Answer 3

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 )

Answer 4

Speeling:

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.

Answer 5

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.

Answer 6

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

Answer 7

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]

Answer 8

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.

Answer 9

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.

Answer 10

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.