Use of "my" prefix in object naming

Question

I am refactoring a large code base, and noticing the author often uses "my" to prefix object names. For instance, using myThingy to identify an object of type Thingy. Is this generally considered a good or bad naming pattern?

After listening to Software Engineering Radio's episode on naming, I am suspect to naming patterns and curious if there is a general consensus on this matter.

Answer 1

Sounds like the author has been cutting and pasting code examples, which commonly show classes that begin with My in order to illustrate that they are written by the individual (as opposed to framework classes or classes that are autogenerated). You're supposed to take off the prefix and/or name the class something that is relevant in the subject matter domain. Keeping the prefix is not a known convention I've ever heard of, and in fact is very pedestrian.

Also, class names should be capitalized in both Java and C#, so at the very least it should be MyThingy instead of myThingy.

• Jasmijn: Minor nitpick: they mentioned Thingy is the class name, and myThingy is the name of a variable that points to a Thingy instance. So their use of capitalisation is actually standard.
• Kevin Van Dyck: Not such a minor nitpick. This is accepted as answer even though it doesn't answer the question at all. OP talks about object names and this answer is about subclass names.

Answer 2

You don't way which programming language you're using and that makes a lot of difference!

In a 'C'-style language, class names generally start with an upper-case letter. A variable of that Type can then be declared with a lower case first letter, as in:

class Zebedee { ... } 
Zebedee zebedee = ... ; 

In BASIC-style languages, which often don't care about case, you can't do this because the two names would clash (effectively "Zebedee" = "zebedee" !!), so a prefix is often added to distinguish between the two.
Back in the dim and distant Past, when Object Types were relatively few and far between, Hungarian Notation put an abbreviated, type-specific prefix on every variable name. using this, you had to know what the prefix meant to understand what sort of variable you were working with. As objects became more "mainstream", though, this got completely out of hand, with the ever-growing number and length of prefixes often being longer than the "meaningful" variable name tacked somewhere on the end of them!

Nowadays, putting something on the front (or back) is still a necessity in these languages and many books and courses have been written that splatter "my" all over the place.

• Steve: +1 for the Basic pun - "the dim and distant past"!

Answer 3

For instance, using myThingy to identify an object of type Thingy. Is this generally considered a good or bad naming pattern?

Is this instance of Thingy a member of another object? Could they be trying to indicate the relationship of the member?

There is a convention in many languages, for instance, where members are prefixed with an underscore - so _thingy. In C++, the underscore prefix often indicates reserved names, so people commonly use m_thingy, thingy_ or use the this pointer (this->thingy). This is to help with scoping in member methods where you might be passing an instance of Thingy since you don't need scope specified in a class method to access the class' other members.

So myThingy is unconventional, but understandable if this is the case.

• Jon Deaton: In the code I'm refactoring these objects are almost never members of another object, usually just local to a method. Interesting point about C++ convention - thank you.
• Emile Bergeron: See Hungarian notation. I've seen this used in Java as well. I used to prefix member variable in C++ with m like mCount.
• einpoklum: The convention, if any, is an underscore as a suffix...
• HorusKol: @einpoklum I've seen lots of code in many languages using _member. Can't say I ever recall seeing member_ in use.
• einpoklum: We were talking about C++. Names starting with underscores are reserved in various context, so many people avoid them even when they're not actually reserved. See this answer on SO. Also, the different answers th this question.

Answer 4

This is a dead fad. It started when Win98 subjected us to MyDocuments and it ended when that was renamed to Documents.

Our convention for lowercase first letters for variables and upercase for class names usually lets you steal the name of the class without any prefix warts when all you want to say with the name is that you have an instance of the class.

Thingy thingy = new Thingy();

So the only real justification for myThingy is if that name communicates something more.

Thingy myThingy = new Thingy();
Thingy yourThingy = new Thingy();

If it doesn't do that then this is just extra annoying noise. If you're going to name it different than the class name it's much more valuable if the name tells you something about whats going on here. But even so, please tell me there are no actual classes named Thingy.

• GrandmasterB: Yeah, I seem to remember this being common with Visual Basic back in the day.
• David Conrad: This had nothing to do with Windows 98 or My Documents. This was a naming style that was common in pedagogical programming examples long before then. I consider it to be bad style, personally.

Answer 5

Is this generally considered a good or bad naming pattern?

In my experience a naming pattern is good if it is consistently followed throughout the codebase and means the same thing every time. So if the prefix my always denotes a local variable or always denotes a member variable, then I'd say it's a good naming pattern. In that case the pattern allows you to immediately infer some information about the scope or purpose of the variable without having to dig further into the code.

It's when the pattern is not followed consistently that it becomes a bad pattern. If the my prefix doesn't allow you as the programmer to infer anything about the variable because it's not followed consistently, then it becomes at best useless and at worse harmful (e.g. if my is mostly used for member variables, but then somebody uses it for a local variable, it could lead a programmer to make false assumptions and lead to a bug)

So in my opinion it's not as much about whether you use myCustomer or _customer or customer_ or whatever - it's making sure that whatever naming pattern you use, either ensure you use it consistently or don't use a pattern at all.

Answer 6

It's usually a very bad idea. As already said, all major programming languages are case-sensitive, so you can write

void processThingy(Thingy thingy) {
 Foo foo = new Foo(thingy);
 Bar bar = new Bar(thingy, foo);
 ...
}

without any prefix. A "my" prefix makes sense when there's also some "theirs" (e.g., when merging in git) or alike. Otherwise it's wrong.

But Thingy thingy is not good either.

It's only good, when there's no better name available. Compare

void copy(File file, Path path);

and

void copy(File source, Path destination);