É uma má prática nomear uma propriedade / membro da mesma forma que o tipo de declaração em C #?

Por exemplo, uma classe como:

class Dog { } //never mind that there's nothing in it...

e então uma propriedade como:

Dog Dog { get; set; }

Foi-me dito que, se eu não conseguir criar um nome mais imaginativo, devo usar:

Dog DogObject { get; set; }

Alguma idéia de como nomeá-los melhor?

c# naming properties

— Storm Kiernan
fonte

Esse requisito sobre o qual você foi informado parece estar com morte cerebral, talvez devido ao excesso de aplicação de uma boa diretriz (não use apenas o nome do tipo quando houver um nome melhor).

Isso nem será compilado em C #, pois os nomes dos membros não podem ser iguais ao tipo de anexo.

— Lee

@ Lee: Eu acho que o contexto é que a propriedade está em outro tipo. Por exemplo, uma Personclasse que contém uma Dogpropriedade chamadaDog

— Gorić

Quero dizer, se ela é realmente um cachorro, rotule-a como tal.

— Thomas Eding 26/09

O destaque da sintaxe do seu IDE deve diferenciar o tipo e a propriedade. Quando você não está usando um IDE, sempre pode olhar para o contexto.

— Cyanfish

Respostas:

Poderia ser uma prática ruim, não fosse o fato de que já é bastante óbvio o que você está falando no seu código, com base no contexto.

Dog = new Dog();

Qual é o construtor de tipos? Qual é o objeto? Não está confuso? OK, que tal

Dog = Dog.Create()?

Qual é o objeto? Qual é o método estático de fábrica no tipo? Ainda não está confuso? Eu acho que não.

A única vez que vi esse problema em potencial é quando a árvore do namespace se torna bastante elaborada e o compilador não consegue descobrir a ambiguidade. Nesse caso, você acaba com algo como

Dog = new Some.Namespace.Dog();

De qualquer forma, isso só deve acontecer com Propriedades automáticas (e talvez enumerações), pois os nomes de variáveis locais são sempre camelCased, evitando a ambiguidade completamente.

dog = new Dog();

— Robert Harvey
fonte

+1. E as alternativas são piores: "TheDog", "AnyDog", "MyDog" etc. Quando não há nada a acrescentar, é melhor não adicionar nada.

— kevin cline 26/09/13

Suponho que o segundo poderia ficar confuso se, por algum motivo, Dogtivesse um método de instância chamado Create, mas você estaria mergulhando em algumas práticas terríveis de codificação naquele momento.

— KDiTraglia

Não é apenas uma prática razoável, o idioma foi projetado especificamente para permitir isso. Pesquise na especificação do C # por "Color Color" para obter as regras e uma justificativa e consulte

http://blogs.msdn.com/b/ericlippert/archive/2009/07/06/color-color.aspx

para alguns casos interessantes que surgem dessa decisão.

Sob nenhuma circunstância você deve nomear uma propriedade "DogObject" para evitar chamá-la da mesma forma que seu tipo; que contradiz diretamente as diretrizes de design da estrutura.

— Eric Lippert
fonte

Se o tipo de propriedade é aquele cujas instâncias não têm identidade (por exemplo Color), esse uso parece razoável. Eu não gosto muito, no entanto, de IDisposabletipos ou mutáveis . "Um controle Font" se refere aos aspectos do estado que são encapsulados pela propriedade ou à instância Fontidentificada pelo getter da propriedade?

— Supercat

É perfeitamente aceitável chamá-lo Doge é isso que a Microsoft recomenda nas diretrizes de nomenclatura do Framework :

CONSIDERE dar a uma propriedade o mesmo nome que seu tipo.

Por exemplo, a propriedade a seguir obtém e define corretamente um valor de enumeração chamado Cor, portanto, a propriedade é denominada Cor.

E aqui está o exemplo que eles usam no guia acima:

public enum Color {...}
public class Control {
    public Color Color { get {...} set {...} }
}

— Isak Savo
fonte