Czy złym zwyczajem jest nazywanie własności / członka tak samo jak typ deklarujący w C #?

Na przykład klasa taka jak:

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

a następnie właściwość taką jak:

Dog Dog { get; set; }

Powiedziano mi, że jeśli nie mogę wymyślić bardziej pomysłowej nazwy, muszę użyć:

Dog DogObject { get; set; }

Czy są jakieś przemyślenia, jak je nazwać lepiej?

c# naming properties

— Storm Kiernan
źródło

Ten wymóg, o którym mówiono, wydaje się nie do pomyślenia, być może z powodu nadmiernego egzekwowania dobrych wytycznych (nie używaj tylko nazwy typu, gdy jest lepsza nazwa).

Nie będzie to nawet kompilować w języku C #, ponieważ nazwy członków nie mogą być takie same jak typ załączający.

— Lee

@Lee: Myślę, że kontekst jest taki, że właściwość jest innego typu. Np. PersonKlasa zawierająca Dogwłaściwość o nazwieDog

— goric 26.09.13

To znaczy, jeśli rzeczywiście jest psem, oznacz ją jako taką.

— Thomas Eding,

Podświetlanie składni twojego IDE powinno różnicować typ i właściwość. Kiedy nie używasz IDE, zawsze możesz spojrzeć na kontekst.

— Cyanfish,

Odpowiedzi:

Może to być zła praktyka, gdyby nie fakt, że jest już dość oczywiste, o czym mówisz w kodzie, w oparciu o kontekst.

Dog = new Dog();

Jaki jest konstruktor typu? Który jest przedmiotem Nie mylić? OK, a może

Dog = Dog.Create()?

Który jest przedmiotem Jaka jest statyczna metoda fabryczna dla danego typu? Nadal się nie mylisz? Nie myślałem tak.

Jedyny raz, kiedy widziałem, że jest to potencjalny problem, to wtedy, gdy drzewo przestrzeni nazw staje się dość skomplikowane, a kompilator nie może zrozumieć dwuznaczności, w którym to przypadku kończy się coś takiego

Dog = new Some.Namespace.Dog();

W każdym razie powinno to się zdarzyć tylko w przypadku właściwości automatycznych (i być może wyliczeń), ponieważ nazwy zmiennych lokalnych są zawsze uwzględniane w wielbłądach, unikając całkowicie niejednoznaczności.

dog = new Dog();

— Robert Harvey
źródło

+1. A alternatywy są gorsze: „TheDog”, „AnyDog”, „MyDog” itp. Gdy nie ma nic do dodania, najlepiej niczego nie dodawać.

— kevin cline

Przypuszczam, że ten drugi mógłby się pomylić, gdyby z jakiegoś powodu Dogzostała wywołana metoda instancji Create, ale w tym momencie nurkowałbyś w dość okropnych praktykach kodowania.

— KDiTraglia

Jest to nie tylko rozsądna praktyka, język został specjalnie zaprojektowany, aby to umożliwić. Wyszukaj specyfikację i uzasadnienie w specyfikacji C # dla „Kolor koloru” i zobacz

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

dla niektórych interesujących przypadków narożnych wynikających z tej decyzji.

W żadnym wypadku nie należy nazywać właściwości „DogObject”, aby uniknąć nazywania jej tym samym typem; co jest sprzeczne z wytycznymi dotyczącymi projektowania ram.

— Eric Lippert
źródło

Jeśli typ właściwości to taki, którego instancje nie mają tożsamości (np. Color), Takie użycie wydaje się uzasadnione. Nie podoba mi się to jednak w przypadku zmiennych lub IDisposabletypów. Czy „formant Font” odnosi się do tych aspektów stanu, które są enkapsulowane przez właściwość, czy do wystąpienia Fontzidentyfikowanego przez getter właściwości?

— supercat

Można to w pełni nazwać Dogi tak właśnie zaleca Microsoft w wytycznych nazewnictwa Framework :

UWAŻAJ, że właściwość ma taką samą nazwę jak jej typ.

Na przykład następująca właściwość poprawnie pobiera i ustawia wartość wyliczenia o nazwie Kolor, więc właściwość ma nazwę Kolor.

A oto przykład, którego używają w powyższym przewodniku:

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

— Isak Savo
źródło