Czy warto dbać o wytyczne konwencji nazewnictwa?

Nazywam zmienne przy użyciu konwencji .Net:

• camelCase dla zmiennych i pól (zwykle używam _camelCase dla prywatnych pól w klasie)
• PascalCase dla metod, właściwości i klas

Jedyne miejsce, w którym zbaczam, to stałe i wyliczenia, w których faktycznie wolę styl Java SCREAMING_CAPS.

Baza kodów mojej firmy jest zaśmiecona pseudo-węgierskim stylem notacji z VB6 i VBScript, jeśli nie w pełni węgierskim tj.

• s lub str dla Strings
• i lub int dla Ints
• d dla dziesiętnego (lub czasem podwójnego)
• o lub obj dla dowolnego rodzaju obiektu

Kulę się, ilekroć widzę ten styl kodu używany w cudzym kodzie (nawet w kodzie Greenfield, nie tylko w starszym crufcie), i sam odmawiam używania tego stylu. W przeszłości poruszałem kwestię standaryzacji konwencji nazewnictwa .Net i jest to po prostu ignorowane - ludzie, którzy piszą po węgiersku, nadal to robią, ci z nas, którzy mnie nie lubią, nadal używają naszego własnego stylu; Jestem trochę boi się, że jeśli mamy zrobić Standarize = standaryzacja (które przeć do, ale nikt się tym nie przejmuje), to będzie on notacji węgierskiej i nie zalecany sposób i wtedy będę zmuszony do zapisu kodu tak .

Czy w związku z tym robię górę z kretowiska? Czy nie powinienem się przejmować, czy kod jest zaśmiecony nadmiarowymi identyfikatorami, a nie nazwami opisowymi, i nadal używać po swojemu i naciskać, aby stał się standardem?

Jedyną rzeczą, na którą powinieneś zwrócić uwagę, jest to, że pracujesz w zespole, w którym ludzie nie dbają o sprzątanie. To bardzo smutne

Rób to, co robisz, nadal korzystaj z nowoczesnego stylu i zapraszaj ludzi (ale nie zmuszaj ich), aby również je przyjęli. Oczywiście zajmie to trochę czasu. Po pewnym czasie zobaczysz, czy leci gdziekolwiek i co możesz robić dalej.

PS A może umówisz się na spotkanie w tej sprawie i zaprosisz wszystkich zainteresowanych? Następnie zwrócisz ich pełną uwagę, wskażesz problem i przedstawisz swoje podejście. To da im coś do przemyślenia. Być może z twoich lokalnych prób nie traktują cię bardzo poważnie.

Myślę, że być może będziesz musiał zadać sobie pytanie, czy notacja węgierska wpływa na twoją osobistą wydajność / jakość, czy może po prostu szkodzi twojemu ego. Przez ego rozumiem, że ogólnie rzecz biorąc wszystko działa dobrze, ale nigdy nie chciałbyś, aby ktoś, kogo szanujesz z zewnątrz, zobaczyłby wstydliwie przestarzały kod. Chociaż myślę, że obawa ma swoje zalety, musisz porównać ją z uderzeniem jakości / produktywności, które poniosą wszyscy, którzy musieliby się zmienić.

Jest to rodzaj technicznego zadłużenia, ponieważ masz całkowitą rację, że ten styl węgierski nie ma sensu w .Net (z wyjątkiem interfejsów z „I”, ale to na inny czas), jednak może to być rodzaj dług techniczny, z którym Twój zespół może żyć, dopóki w naturalny sposób nie zniknie .

Najlepszym argumentem przeciwko węgierskiej notacji, oprócz współczesnych IDE, które mają wiele metod, aby pokazać typ, widoczność i inne elementy zmiennej o kolorze, z małymi symbolami i tekstami narzędzi podczas odkurzania, jest wzięcie tego na poważnie.

• Zachęcaj do większego dystynkcji (b) ool (f) loat (c) har (l) ong (s) hort (konflikty z String? No: (S) tring), (v) oid.
• Zachęcaj do kodowania widoczności. Jestem z Javaland i mam nadzieję, że pasuje również do .net: (pri) vate, (pub) blic, (pro) tected (def) ault powinien zostać użyty.
• .net ma końcowy / const? Zrób z tego prefiks! Czy słyszę „niestabilne”?
• Dlaczego int i long potrzebują prefiksu, a różne obiekty nie? To nie jest logiczne. Utwórz tabelę skrótów. gdzie każdy nowy Obiekt otrzymuje wyraźny skrót.
• Zmienne, które mogą być zerowe i takie, które nigdy nie powinny być zerowe, mogą być również poprzedzone. Sprytni ludzie umieszczają cały DbC w prefiksie zmiennej.

Poważnie: podczas refaktoryzacji możesz zmienić zmienną z int na long, z String na char. Nie powinieneś również zmieniać nazwy.

W IDE nazwy często posortowane są w ramce z boku. posortowane według nazwy, gdzie łatwo je znaleźć. Jeśli większość zmiennych zaczyna się od o lub i, niepokojące dla oczu jest dotarcie do znacznej części nazwy.

Dodatkowe znaki zakłócają semantykę zmiennej. Liczba całkowita „rozsądna” otrzymuje „i_sane”, która bardziej przypomina „szaloną”.

Notacja węgierska była pomocna w językach, w których brakuje systemu pisma. Nie potrzebujesz go, jeśli kompilator wymusza określone typy. Jeśli udekorujesz swój lamento na temat węgierskiej notacji empatycznym „tak, dla starszych programistów, używanie go w przeszłości miało sens!”, Ci starsi programiści mogą być próżni i wolą nie być identyfikowani jako starzy.

Ale musisz być ostrożny, aby technika zadziałała. Może możesz obniżyć głos, mówiąc o „starszych programistach”, aby mogli poczuć, jak bardzo jesteś wobec nich ostrożny i jak bardzo potrzebują opieki. Aby trzecia osoba w pokoju rozpoznała, że ​​próbujesz coś ukryć, co oczywiście zwiększy jego ciekawość.

Kup kopię wytycznych projektowania ramowego i upuść ją na biurku swojego kierownika (lub osoby kontrolującej styl kodowania). Pamiętaj, aby umieścić post, który wyraźnie wskazuje na wprowadzenie, w którym podkreślają znaczenie spójności. Aby dalej jechać do domu, pobierz kopię Clean Code i umieść tam zakładkę w części dotyczącej konwencji kodowania.

Pod pewnymi względami jest to kwestia subiektywna i jest to jedna z tych debat programistycznych (ortograficznych?), Które bawię przez jakiś czas, a następnie unikam. Chociaż myślę, że węgierska notacja jest grzechem, który należy usunąć, myślę, że spójność jest ważniejsza.

W tym duchu dołożę wszelkich starań, aby przekonać zespół do korzystania z nazewnictwa zmiennych skoncentrowanych na domenie zamiast konwencji nazewnictwa opartego na typach, ale jeśli wszystko stanie się trudne, wycofam się, aby zaakceptować standard nazewnictwa, którego wszyscy muszą przestrzegać wspólna podstawa kodu.

Nie jestem zwolennikiem jakiegoś generalnie obowiązkowego standardu narzuconego przez grupę norm, ale zespoły oprogramowania opracowują własny standard, a co ważniejsze, trzymają się go.

Dzięki resharper zmiana nazw zmiennych jest tak szybka, że ​​mogę cofnąć tak źle rozważane konwencje nazewnictwa tak szybko, że nie muszę pozostawiać starych, źle kierowanych konwencji.

Jeśli nie masz narzędzi do refaktoryzacji, zgadzam się z innymi komentatorami, którzy zasugerowali przestrzeganie obowiązującej konwencji bazy danych, jak tylko możesz, nawet jeśli było to błędne. (do pewnego stopnia istnieją różne konwencje nazewnictwa, które zamieniają się w generatory błędów, jeśli im na to pozwolisz)

Większość twoich obaw jest uzasadniona i ułatwiłoby życie nowemu deweloperowi, a prawdopodobnie także twojemu rozsądkowi. Jedną konwencją, którą powinniście wszyscy przyjąć, są nazwy opisowe. Powinieneś być w stanie dojść do konsensusu w tej sprawie bez drastycznej zmiany stylów w zależności od tego, jak złe są. Po wszystko inne albo poczekaj, aż będziesz rządził, albo zastąpisz obecnych członków świeżymi programistami, którzy myślą i czują to, co robisz.

Moje odchylenia:

• _PublicPropertyBacker
• _private_property_backer
• _privateMember
• CONSTANT_MEMBER
• privateFunction
• param_
• prywatny przycisk okBU; //itp. ogranicz 3 znaki
• struct SOMESTRUCT // dla struktur pinvoke

Ogólne regiony kodu i układ plików:

• Członkowie
  • (prywatny | wewnętrzny | chroniony | publiczny) X [statyczny] X [const / readonly]
• Nieruchomości
  • (prywatny | wewnętrzny | chroniony | publiczny) X [statyczny] X [tylko do odczytu]
• Konstruktory
  • (prywatny | wewnętrzny | chroniony | publiczny) X [statyczny]
• Polecenia // cokolwiek z nieważnym zwrotem lub zwrotem statusu
  • (publiczny | chroniony | wewnętrzny | prywatny) X [statyczny]
• Obsługa zdarzeń / prywatna /
  • (Sterowanie | Zdalne | Usługa | Inne) Zdarzenia
• Funkcje // sprawdzają stan, nie powinny mieć skutków ubocznych
  • (publiczny | chroniony | wewnętrzny | prywatny) X [statyczny]