Zmienne konwencje nazewnictwa? [Zamknięte]

11

Właśnie zacząłem używać ReSharpera (dla C #) i podoba mi się jego wyszukiwarka zapachów, pokazuje mi pewne rzeczy na temat pisania, które chciałem naprawić dawno temu (głównie zmienne konwencje nazewnictwa).

Zmusiło mnie to do ponownego rozważenia niektórych konwencji nazewnictwa dla metod i zmiennych instancji. ReSharper sugeruje, że zmienna instancji ma być małą literą wielbłąda i zaczyna się od podkreślenia. Przez jakiś czas chciałem, aby wszystkie moje zmienne lokalne były małymi literami wielbłąda, ale czy konieczne jest podkreślenie? Czy uważasz to za wygodne? Nie podoba mi się ta konwencja, ale jeszcze jej nie wypróbowałem, co o tym sądzisz?

Drugą rzeczą, która skłoniła mnie do ponownej oceny, są moje konwencje nazewnictwa dla programów obsługi zdarzeń GUI. Zwykle używam standardu VS ControlName_Action, a moje formanty zwykle używają węgierskiej notacji (jako sufiksu, aby pomóc w wyjaśnieniu w kodzie tego, co jest widoczne dla użytkownika, a co nie, gdy mamy do czynienia ze zmienną o podobnej nazwie), więc kończę na OK_btn_Click ( ), co o tym sądzisz? Czy powinienem poddać się konwencji ReSharper, czy istnieją inne równie ważne opcje?

Ziv
źródło

Odpowiedzi:

19

Możesz zmodyfikować ReSharper, aby używał dowolnego używanego schematu konwencji nazewnictwa. Jest dość elastyczny, w tym dostosowuje moduły obsługi zdarzeń, pola, właściwości, metody o różnych poziomach dostępności itp.

Nie pozwól, aby narzędzie definiowało twoje standardy - używaj go do egzekwowania własnych.

Aktualizacja: Powiedziawszy to, w pracy używamy głównie małych liter wielbłąda do większości rzeczy prywatnych - zmiennych, pól i argumentów. Wielkie litery wielbłądów dla nazw metod, stałych i właściwości. Nazwy modułów obsługi zdarzeń są oparte na akcji, którą reprezentują, a nie na czymś specyficznym dla formantu - np. HandleCustomerContinue zamiast HandleContinueButtonClick. Próbowałem przez pewien czas domyślnego schematu ReSharper i właściwie to nie przeszkadza, tak naprawdę nie jestem zrozpaczony.

mjhilton
źródło
Oczywiście bardzo podoba mi się to, jak pomaga mi kontrolować moje lokalne zmienne, ale jestem ciekawy standardów innych ludzi, szczególnie jeśli chodzi o procedury obsługi zdarzeń.
Ziv
W porządku, zredagowałem, aby podać bardziej osobiste szczegóły doświadczenia.
mjhilton
11
+1 za „Nie pozwól, aby narzędzie definiowało twoje standardy”
techie007
„Nie pozwól, aby narzędzie definiowało twoje standardy” stało się jednym z moich ulubionych cytatów programistycznych wszechczasów.
seggy
18

Z szacunkiem do

ale czy konieczne jest podkreślenie? czy czujesz się komfortowo?

Jedną z rzeczy, które bardzo lubię w używaniu podkreślenia, jest to, że radykalnie ogranicza użycie „tego”.

Rozważać:

public void Invoke(int size) {
    _size = size;
}

bez podkreślenia musiałbyś napisać:

public void Invoke(int size) {
    this.size = size;
}

co potencjalnie wprowadza subtelny błąd:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

Ponadto uzupełnianie kodu jest czystsze, ponieważ po prostu wiążąc podkreślenie, otrzymujesz listę tylko prywatnych pól, podczas gdy z „tym” otrzymujesz listę wszystkiego.

Z szacunkiem do

zwykle używają węgierskiej notacji

Wytyczne dotyczące projektowania ram: konwencje, adresy i wzorce bibliotek wielokrotnego użytku .NET mówią:

NIE używaj notacji węgierskiej

Pozostawiając mało miejsca na dwuznaczność:)

Dakotah North
źródło
Ściśle mówiąc, jeśli postępujesz zgodnie z wytycznymi dotyczącymi projektowania ram, stwierdza się, że zmienne, które są przekazywane do metod publicznych, powinny również być pisane wielkimi literami, oprócz nazw metod :)
Surgical Coder
pzycoman ... czy możesz mi wskazać, gdzie to jest napisane. Rzut oka i nie mogłem znaleźć żadnego odniesienia do używania wielkich liter w zmiennych przekazywanych do metod publicznych. Ale na przykład na P 118 drugiego wydania istnieje przykład, w którym w metodach publicznych nie używa się wielkich liter, lecz małe litery. „public void Write (wartość uint);”
Dakotah North
10
W przypadku starć z nazwami powiedziałbym, że this.sizejest to o wiele wyraźniejsze niż _size. Użycie podkreślonej nazwy nie zapobiega subtelnemu błędowi, nadal możesz przypisać sobie rozmiar, ale mam nadzieję, że twój kompilator ci to powie.
edA-qa mort-ora-y
2
Jasne, zawsze możesz przypisać coś do siebie. Główną różnicą pomiędzy this.sizei _sizejest spójność. Oznacza this.sizeto, że jest opcjonalny. Na przykład, jeśli wywoływane było inne prywatne pole name, nie ma potrzeby używania this.namew kodzie, równie dobrze mógłbym używać namebez żadnych kolizji. Ponieważ thismoże być używany czasami, a nie innym razem, dlaczego używanie thisjest gorsze. Z drugiej strony nie ma dwuznaczności z _...
Dakotah North
2
Ugh ... dlaczego ludzie nadal używają podkreślenia w językach, które zapewniają lepszy sposób.
Rig
8

Spójność jest naprawdę kluczem. To i jasność, tzn. Nie bądź tajemniczy ani nie próbuj oszczędzać pisania, skracając wszystko. Intellisense to oszczędzanie pisania, a nie tajemnicze (ale krótkie!) Nazwy.

Richard
źródło
2
+1: Wybierz konwencję i trzymaj się jej. Wszystko, co zrobi (z wyjątkiem Systems Hungarian).
Donal Fellows
Spójność to nie jedyna rzecz. Na przykład, ktoś może wybrać spójne konwencje nazewnictwa dla własnego kodu, ale jeśli ta konwencja bardzo różni się od innych konwencji nazewnictwa, to podczas korzystania z innych bibliotek ... nieuchronnie pojawią się niespójności. Na przykład, jeśli wybiorę użycie konwencji nazewnictwa właściwości z C # w Javie, nie będę spójny z tym, jak kod jest zapisywany we wszystkich innych systemach. Mógłbym pisać order.Size()(w przeciwieństwie do order.getSize()), ale ponieważ inne biblioteki używają programów pobierających i ustawiających mój kod nie będzie spójny.
Dakotah North
Oczywiście, za wszelkimi konwencjami, które człowiek zdecyduje się zastosować, powinna kryć się inteligentna myśl, ale najważniejsza jest konsekwencja.
richard
@DototahNorth - sens ma styl domu, ale poza tym najważniejsza jest konsekwencja. Dopóki konwencja nie jest zbyt prosta, może być łatwo odebrana przez zewnętrznych / nowych programistów. Rzeczywiście warto opublikować styl domu, aby usunąć wszelką niepewność.
cjmUK
7

W języku C # rozpoczynanie nazwy chronionej lub publicznej znakiem podkreślenia jest niezgodne ze specyfikacją języka wspólnego. Jest to poprawne tylko w przypadku członków prywatnych.

Z MSDN:

Aby w pełni współdziałać z innymi obiektami bez względu na język, w którym zostały zaimplementowane, obiekty muszą udostępniać dzwoniącym tylko te funkcje, które są wspólne dla wszystkich języków, z którymi muszą współpracować. Z tego powodu zdefiniowano Common Language Specification (CLS), który jest zestawem podstawowych funkcji językowych wymaganych przez wiele aplikacji.

Zobacz: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Tutaj możesz przeczytać ostrzeżenie o podkreśleniu:

Nazwy elementów zaczynające się od znaku podkreślenia (_) nie są częścią Common Language Specification (CLS), więc kod zgodny z CLS nie może używać komponentu, który definiuje takie nazwy. Jednak podkreślenie w dowolnej innej pozycji w nazwie elementu jest zgodne z CLS.

Zobacz: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

Członkowie chronieni stanowią problem, ponieważ możesz dziedziczyć po klasach napisanych w innym języku.

Ale może nie jest to problem w twoim przypadku, jeśli nie potrzebujesz kodu zgodnego z CLS.

psur
źródło
4

Lubię podkreślenia. Na pierwszy rzut oka wiesz, że zmienna jest członkiem klasy i jest prywatna.

Oczywiście IDE może ci powiedzieć, że kiedy najedziesz na nią myszką, ale „pierwszego spojrzenia” nie da się pokonać. Wiesz, co to jest zmienna lokalna i jaka jest zmienna składowa tylko na własne oczy. Nie wymaga przewijania ani kursorów myszy.

Możesz użyć słowa kluczowego „to”, ale _ jest krótszy, aby uzyskać lepszą możliwość skanowania w poziomie. Nazwy opisowe są zwykle pożądane, ale gdy coś jest ustaloną konwencją, lepiej mieć 1 znak. na przykład używając litery i jako indeksu podczas zapętlania tablicy. Ponieważ jest to ustalona konwencja, że ​​i jest indeksem, zyskujesz możliwość skanowania bez wady zastanawiania się, co oznacza „i”.

mike30
źródło
1

Zgadzam się ogólnie z tym, co mówią inni, jednak jeśli chodzi o narzędzia i łańcuchy narzędzi, jestem leniwy i lubię łatwe życie. Uważam, że życie jest często łatwiej robić po prostu tak, jak sugerują. Powody są

  • Jest łatwiejszy do zainstalowania (po prostu przejdź do ustawień domyślnych, nawet ja mogę nacisnąć Enter 20 razy i uruchomić)
  • Błędy zwykle są opracowywane z ustawień domyślnych, często to konfiguracja ezoteryczna, którą skonfigurowałem, która ujawnia defekt po raz pierwszy
  • Sprzedawca łańcucha narzędzi prawdopodobnie wie o nim więcej niż ja, dlatego zrobili to z jakiegoś powodu. Kim jestem, aby zdecydować, że eksperci się mylą (uważam ich za ekspertów, ponieważ kupiłem ich narzędzie)
  • Nigdy nie będziesz musiał bronić wyboru dostawcy przez Menedżera - „To jest to, co oni zalecają”
  • Nowy facet nie będzie cię denerwował słowami „dlaczego” i „Tak jest lepiej” - kiedy każda odpowiedź brzmi „ponieważ zdecydowali ...”

Tak więc uważam, że jeśli znajdziesz właściwy powód do zmiany konfiguracji narzędzi, na które właśnie wydałeś fortunę, zrób to wszystko. Jeśli nie możesz uzasadnić zmiany, nie rób tego.

Należy pamiętać, że każda zmiana wiąże się z ciągłymi kosztami (rzeczywistymi i ukrytymi). Im mniej, tym niższy koszt. Na przykład - ten nowy facet, o którym wspomniałem - brak zmian oznacza, że ​​może przeczytać jego instrukcję. Ponowna konfiguracja - musisz napisać aneks, przechowywać go wraz z innymi rzeczami, wycofać i poprosić go o przeczytanie po przeczytaniu instrukcji. Może nie stanowi to problemu dla sklepu dla 2 osób, ale co ze sklepem dla 100 osób?

mattnz
źródło
1

Dwie reguły, o które pytasz, podkreślają na początku prywatnych nazw pól, a nazwy metod są ogólnie uważane za normę w kręgach programistycznych C #. Dostosowując się do tych konwencji, Twój kod będzie od razu bardziej zrozumiały dla innych programistów, ponieważ jest to sposób myślenia, w którym są przyzwyczajeni do działania.

Sufiks Label, RadioButton itp. Dla twoich kontroli jest również ogólnie uważany za normę. Często istnieje wiele formantów dla pojedynczej koncepcji (np. Label i TextBox), a ten przyrostek jest całkiem przydatny. Prawdziwa notacja węgierska została porzucona już dawno temu, ponieważ została przekupiona na coś, co nie wyraża jej pierwotnej intencji, czyli kontekst dotyczący zmiennej, a nie jej typu, wielkości itp.

Charles Lambert
źródło
1

W moim przypadku użycie camelcase i podkreślników pomaga w opisowych (czytaj: długich) nazwach zmiennych i uzupełnianiu kodu. Nie jestem pewien, jak działa autouzupełnianie programu Visual Studio, ale w QtCreator iw mniejszym stopniu w Eclipse można na przykład wpisać

sDI

i niech rozszerzy się do

someDescriptiveIdentifier

Oszczędza trochę pisania na wypadek, gdybyś miał takie imiona

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

które mam tendencję do tworzenia w „opisowym trybie nazewnictwa”.

Za pomocą podkreślników mogę określić, która nazwa ma być automatycznie uzupełniana

someDescriptiveIdentifier

lub

_someDescriptiveClassMember

Mam nadzieję, że moje wyjaśnienie jest wystarczająco jasne :)

Manjabes
źródło