Jakie konwencje nazewnictwa używasz w C#?

Question

Jako początkujący programista staram się ustalić dla siebie standardową konwencję nazewnictwa. Zdaję sobie sprawę, że to osobiste preferencje, ale starałem się uzyskać pewne pomysły od niektórych z was (wielu z was), którzy są znacznie mądrzejsi ode mnie.

Nie mówię o zapisie wielbłąda, ale raczej o tym, jak nazywasz swoje zmienne itp. IMHO, var_Quantity jest znacznie bardziej opisowe niż Q lub varQ. Jak jednak sprawić, by zmienna nie stała się zbyt długa. Próbowałem być bardziej opisowy przy nazywaniu moich kontrolek, ale skończyłem z niektórymi takimi jak "rtxtboxAddrLine1" dla RadTextBox, który ma adres z linii 1. Too me, to jest niemożliwe do kontrolowania, chociaż jest całkiem jasne, czym jest ta kontrola.

Po prostu jestem ciekawy, czy masz jakieś przewodniki, które śledzisz, czy też zostawiam je na własne urządzenia?

Answer 1

Niektóre basic rules can be found here. I much more extended rules can be found here. Są to oficjalne wytyczne od projektantów frameworków Microsoft.

Jak na przykład, zmienna powinna być nazywana po prostu quantity.

Answer 2

Im bardziej opisowy tym lepiej, okaże się, że długość nie jest tak ważna, jak pamiętanie, co ta kontrola/zmienna zrobiła pięć lat w dół drogi.

Answer 3

Istnieje kilka dobrych standardów kodowania dokumentów dostępnych online - David Lance napisał jeden: http://weblogs.asp.net/lhunt/attachment/591275.ashx

Answer 4

Dla projektu .NET API (i niektórych # wytycznymi ogólny c) Sprawdzić Krzysztof Cwalina i Brad Abrams' Framework Design Guidelines

Pozdrowienia, tamberg

Answer 5

polecam skorzystanie własne wytyczne Microsoft jako punkt wyjścia . Zazwyczaj zaczynają się tam większość firm (i tak z mojego doświadczenia).

http://msdn.microsoft.com/en-us/library/czefa0ke(VS.71).aspx

Answer 6

W tym przypadku, myślę, że byłbyś lepiej nazywania go jako primaryAddressLine lub firstAddressLine. Oto dlaczego - rtxt jako przedrostek bezużytecznie mówi o typie. Intellisense pomoże ci z typem i jest odporny na zmiany dokonane w rzeczywistym typie obiektu. Wywołanie go firstAddressLine trzyma go z dala od (słabej) konwencji używania 1, 2, 3 ... na końcu nazw zmiennych, aby wskazać, że z jakiegoś powodu potrzebujesz ich więcej zamiast kolekcji.

Nazwij go za to, co on reprezentuje/jak należy go interpretować lub wykorzystywać nie dla jego typu danych, a nazywanie go nie skraca, jeśli nie potrzebujesz.

Answer 7

ja generalnie starają się podążać Microsoft wytyczne, z kilkoma bardzo starych nawyków wrzucony.
Tak, ja wciąż nie może wydostać się z zwyczaju poprzedzania szeregowców z _privateMember podkreślenia.
Jestem stary, a to wpadło mi w pamięć.

Jeśli chodzi o prefiksowanie widżetów kontrolnych, stwierdziłem, że jeśli stanie się zbyt opisowe, może stać się bolesne, w przypadku zmiany interfejsu w torze.

np. masz coś o nazwie ddlProductLine dla listy rozwijanej, a następnie to musi się zmienić na grupę przycisków radiowych, twoja konwencja dotycząca prefiksów zaczyna być bardziej PITA niż pomocna.

Kiedy masz dużo widżetów do pracy, czasami bardziej ogólny prefiks jak uiCtl może pomóc w bałaganie, ale nadal ma sens, jeśli musisz zmienić typ widżetu.

Answer 8

Lubię ten dokument:

C# Coding Standars for .NET (ZIP)

To dobra kompilacja najlepszych praktyk i wytycznych styl kodowania.

Answer 9

Najlepszym punktem wyjścia jest Guidelines for Names. Ale tak jak w innych dziedzinach życia, kiedy już znasz zasady, zaczynasz wiedzieć, gdzie jest rozsądnie je łamać.

Nigdy nie używam starej węgierskiej notacji, która nazywa rzeczy strFirstName, intCount i tym podobnych; ale nadal używać go na kontroli: txtFirstName, btnVerifyData, itd. Powody to:

• Nie jestem może zmienić rodzaj kontroli
• Jeśli zrobić zmienić rodzaj kontroli , Będę musiał zmienić wiele rzeczy, nie tylko nazwę, więc zmiana nazwy też nie jest wielka.
• Są znacznie łatwiejsze do znalezienia dzięki Intellisense.

Co więcej, całkiem prawdopodobne jest, że zrobię to samo dla wielu pól TextBox lub ComboBox na stronie lub formularzu, podczas gdy prawdopodobnie nie zrobię czegoś dla wszystkich int lub ciągów, o których mowa w stronę lub formularz. Pomaga więc szybko znaleźć wszystkie pola tekstowe z ich prefiksem txt.

Są jeszcze inni, którzy zdecydowanie sprzeciwiają się Węgrom, nawet w tym przypadku, i jestem pewien, że mają swoje powody. Niezależnie od Twojego osobistego stylu, możesz pracować nad zespołem, który ma zupełnie inny styl. W takim przypadku po prostu rób to, co robią; bardzo, bardzo rzadko warto to zrobić. Mogę to zrobić tylko wtedy, gdy ich styl doprowadzi do wielu błędów, ale poza tym nie mogę wymyślić przypadku, który by to spowodował.