Zmienne konwencje nazewnictwa? [Zamknięte]

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?

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.

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ść:)

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.

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.

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”.

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?

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.

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 :)