Best Practice - Avoid naming class and field the same?

Question

When modeling classes I always have stumbled on the problem that the class has a field with the same name. Look at this example:

class Name {  
  string meaning;  
  string language;  
  string name; //the actual name
}  

As you can see, the class Name has a field name, which is the actual name. Is this good practice? How to avoid this naming issue?

Answer 1

Bart van Ingen Schenau has some good advice, but I'd like to offer some additional advice.

Don't universally avoid naming a class and property the same, but definitely question it. Consider all of the properties together as one cohesive concept: name, language, and meaning. Rather than renaming the property, perhaps rename the class. This is more than a name.

Instead, pick a word or short phrase that describes the concept of the combination of a name, its meaning, and the language (or culture) for the name. For example, typically the combination of a word or phrase along with its meaning is called a "definition". The class could be called NameDefinition, which has a name property. The addition of the word "Definition" helps differentiate the type from the data in the type, while also communicating to consumers of this class that it is more than a simple string.

Answer 2

Fields/properties/attributes within a class should describe something of the concept that you are modelling with that class. You should be able to ask questions like "What is the <property> of the <class>?" without having domain experts going "what the heck are you talking about?".

Typically, it is not a good idea to have an attribute with the same name as the class, because the attribute name doesn't describe anything meaningful within the context of the class. Probably it is more meaningful to name such an attribute 'value'. As in, the value of a Name object is the actual name being represented by that object.

Answer 3

name.name() feels rather silly (why say the same thing twice?). name.value() is better as in you don't have to repeat yourself, but it's a bit vague (what is the value of a name?). It might be worth it to add more intent to these properties. So, name.displayName() feels more meaningful if I am about to display that name somewhere. It also gives the flexibility that the display name maybe specialized in some way depending on the context. Similarly, name.ipaName() for any phonetic use, name.utf8() for transportation/serialization, etc.

Answer 4

The general advice is to name things for the reader, so that they are understood when they are read.

Perhaps it will help you to consider all the contexts in which the thing appears (here a class name and/or a field/property name).

• In the definition of the class. Here, you want it both to be somewhat meaning full by itself, and with respect to the class/thing (i.e. as a property of the thing, "the XXX of a Y"; in your example "the name of a Name" is dubious; perhaps you can use something like text or writtenAs). See Bart's answer.

• When used in code external to the class. Here it will be attached to the name of a variable. Example for "the dbid of an item":

   foreach item in recordset:
       print item.dbid
  

  In your case/example :

   Name selectedName = FindGoodName(some query or constraints);
   print selectedName.text;
  

  or

   print selectedName.writtenAs;
  

  or whatever you find appropriate.

• In the code internal to the class; this is relevant for private fields, but is perhaps of lowest priority for a public property/field.

(I'm probably forgetting some context(s)... 🤔)

Answer 5

While I agree with just about all of these answers (and while it obviously depends on constraints and use cases), I think it can be important to consider the informational hierarchy with relation to importance/usage context, i.e:

class Person {
    string name;
    Biography biography;

    class Biography {
        string nameMeaning;
        string nameLanguageOrigin;
    }
}

Obviously your mileage may vary (and is dependent on your requirements), but I mean to point out that just because two topics are related (such as the "name" and the "meaning"), doesn't mean that they're often used in the same context, which could mean they should sit in different "buckets" when designing classes.