When, if ever, should the name of a property contain the name of the class?

Question

public class Fruit
{
    // choose one
    public int Id { get; set; }
    public int FruitId  get; set; } // redundant or usefully more descriptive?

    // choose one
    public string Name { get; set; }
    public string FruitName { get; set;} // redundant or usefully more descriptive?
    public string Fruit { get; set; } // or what about this?
}

Which is your preferred convention for the fruit's identification number and name? Why? Are there other examples where you would answer differently?

Answer 1

public class Fruit
{
    public int Id { get; set; }
    public string Name { get; set; }
}

I know that these properties are properties of Fruit, so why repeat this name? SomethingId is foreign key property for me.

Answer 2

In my opinion, almost always, Id and Name are preferred and redundantly specifying the class name is not recommended. However, a notable exception is when Id or Name refer to an internal identifier or name and FruitNumber and FruitName refer to "real world identifier" or "display name" of the entity and for some reason you don't want to name it DisplayName.

Answer 3

Never.

Ever.

Seriously.

Answer 4

In general, property names should be named after themselves, not the class.

Five situations where the class name may be useful as a prefix or suffix on a member of the class:

1. The desired property name is a reserved word in your language. For instance, FruitType instead of Type. In most cases it is better to just name the property something else.

2. Where the class acts as a factory and returns instances of itself. For instance, if Fruit has a static method called "GetFruitById" that returns a fruit. In this case, you'd likely be better off having a separate FruitFactory class for that method.

3. Where the class contains other things of its own type. In your example, perhaps, if Fruit is a graph showing the evolutionary links of fruit, each Fruit instance could contain a list of fruits descended from it in a called "DescendantFruitList". Chances are, you could drop the word "fruit" and it would still be perfectly descriptive.

4. The name of the class in your domain model matches a word used in common programming naming conventions. Example: an object representing a literal (real-world) Factory, List, Dictionary, etc. and also needing to use the same words for related classes in your programming.

5. Compatibility with an O/R mapping to a database or implementation of an external Interface whose members happen to have the same word. For instance, if Fruit implements an existing IFruitStandProduct interface. In this case, you aren't responsible for the coincidence of naming.

Answer 5

I'd only redundantly specify the class name in a property name if the customer already did. Maintaining ubiquitous language is worth it.

Answer 6

I sometimes need to do this (rarely) in a case like:

class Fruit {
 public int ID {get; set;}
}

class Apple : Fruit {
// I want to call this ID also but it refers to a different ID than the base ID
 public int AppleID {get; set;}
}