24

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?

13
  • 2
    thesaurus.com/browse/name
    – Ewan
    Dec 14, 2022 at 16:40
  • 1
    @Ewan: I've spent many an hour browsing that site during "what do we call this thing" sessions. A thesaurus is usually a good first stop. Dec 14, 2022 at 19:38
  • 16
    What does the class Name represent? It's hard to tell even with the properties specified.
    – Marco
    Dec 15, 2022 at 1:43
  • 2
    @Barmar, unless the name is more than one word. Dec 15, 2022 at 22:55
  • 1
    Naming things is hard. Names are hard. Now what do we name this name... Dec 15, 2022 at 23:04

5 Answers 5

68

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.

2
  • Good alternative indeed. I can imagine this approach is particularly useful in weakly typed languages.
    – Rik D
    Dec 14, 2022 at 19:03
  • 1
    BvIS said, in the answer to which you linked, "You should be able to ask, 'What is the <property> of the <class>?'" In OP's case, if it makes sense to call the class Name, then good names for the field might be value, or text. E.g., What is the value of the name? What is the text of the name? Dec 17, 2022 at 17:08
40

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.

1
  • 3
    Or spelling in this case, as in What is the spelling of the name
    – Hugo
    Dec 15, 2022 at 19:09
9

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.

4
  • why not name.display or name.ipa? since we don't want to repeat the same thing twice.
    – Hugo
    Dec 15, 2022 at 19:11
  • 6
    Does ipaName apply to beer?
    – user949300
    Dec 15, 2022 at 19:56
  • 3
    @Hugo name.display sounds like it is going to 'display' the name? It's good to avoid the ambiguity. If you can find a non-confusing alternative that is similarly expressive, go for it. Maybe something like name.displayRepresentation(). That's a bit too verbose though. But at least that is the kind of name I would strive for. Dec 15, 2022 at 20:41
  • 3
    @user949300 no
    – Bergi
    Dec 15, 2022 at 22:07
0

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

0

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.

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