W mojej obecnej pracy nie ma wytycznych dotyczących kodowania. Każdy właściwie koduje tak, jak chce. Co jest w porządku, ponieważ firma jest mała.
Jednak jeden nowy facet niedawno zaproponował, aby zawsze używać notacji węgierskiej. Do tej pory niektórzy z nas używali węgierskiej notacji, niektórzy nie. Wiesz, to firma inżynierska, więc style kodowania nie mają tak naprawdę znaczenia, dopóki algorytmy są prawidłowe.
Osobiście uważam, że te małe skróty są w pewnym sensie zbędne. Dobrze przemyślana nazwa zwykle zawiera tę samą wiadomość. (Co więcej, większość naszego kodu musi działać na niektórych dziwnych procesorach DSP, w których koncepcja taka jak bool
lub float
nie istnieje).
Co myślisz o notacji węgierskiej? Czy używasz tego? Czemu?
coding-standards
notation
hungarian
bastibe
źródło
źródło
Odpowiedzi:
Kiedy większość ludzi mówi „notacja węgierska”, tak naprawdę mówi o „ węgierskim systemie ”.
Systemy węgierskie są całkowicie bezużyteczne i należy ich unikać. Nie ma potrzeby kodowania typu zmiennej w jej nazwie. Jednak Systems Hungarian to nieporozumienie z oryginalnym „prawdziwym” językiem węgierskim: Apps Hungarian.
W aplikacji węgierskiej nie kodujesz „typu” w nazwie zmiennej, tylko „rodzaj” zmiennej. Więc nie
nWidth
, alepxWidth
lubemWidth
(odpowiednio dla „szerokość w pikselach” lub „szerokość w ems”). Nie,strName
alesName
lubusName
(odpowiednio dla „bezpiecznej nazwy” lub „niebezpiecznej nazwy” - przydatne przy akceptacji danych wejściowych od użytkowników: niebezpieczne ciągi znaków).Osobiście zwykle nie zawracam sobie głowy żadnym z nich. Chyba że robię coś, co jawnie przekształca „rodzaj” wartości (na przykład w przeszłości używałem przedrostka „px” i „em”, ponieważ popełnia błędy jak
pxArea = emWidth * emHeight
oczywiste).Zobacz także artykuł Joela „ Sprawianie, że zły kod wygląda źle ”.
źródło
raw
tjrawUsername
s
jest nie dostring
albo coś, ale za „bezpieczne” (lub również słyszałem „bezpieczną string”).zaimek Czasownik powinien przysłówek Czasownik nigdy Używać przymiotnika Rzeczownik węgierski Notacja, przyimek Czasownik Sprawia, że zbieramy rzeczownik Wszystko przysłówek
źródło
Po pierwsze:
Style kodowania mają znaczenie niezależnie od firmy. Tak, algorytmy muszą być poprawne, ale kod musi być możliwy do utrzymania przez wszystkich, nie tylko oryginalnego programistę. Posiadanie standardu kodowania, który zawiera elementy stylu, w pewien sposób pozwala to osiągnąć. Nie twierdzę, że cały kod powinien być identyczny pod względem stylu - to przyniosłoby efekt przeciwny do zamierzonego, ale powinna istnieć pewna spójność.
Teraz na węgierski zapis:
Choć miał swoje zastosowania, w nowoczesnym środowisku IDE obsługującym zachowania typu IntelliSense nie jest konieczne dołączanie typu zmiennej do jego nazwy. Informacje te są dostępne na inne sposoby. Co gorsza, może to utrudnić odczytanie kodu, jeśli będziesz musiał zmienić typ zmiennej w przyszłości.
źródło
Nie używaj tego. Jest redundantny i utrudnia odczytanie kodu.
źródło
Wiele debat na temat (systemowego) zapisu węgierskiego zależy od obszaru pracy. Kiedyś byłem bardzo stanowczy po stronie „nie ma mowy!”, Ale pracowałem przez kilka lat w firmie, w której jest on wykorzystywany do programowania wbudowanego, widzę pewne zalety tego rozwiązania w niektórych aplikacjach i na pewno mnie to rozwinęło .
Systemy węgierskie
Z tego, co mogę powiedzieć, Systems węgierski jest często używany w dziedzinie osadzania. W aplikacjach na PC kompilator poradzi sobie z wieloma problemami związanymi z różnicami między (np.) Łańcuchami, liczbami całkowitymi i wartościami zmiennoprzecinkowymi. Na głęboko osadzonej platformie częściej obawiasz się różnic między 8-bitowymi liczbami całkowitymi bez znaku, 16-bitowymi liczbami całkowitymi ze znakiem itp. Kompilator (a nawet wątek z egzekwowanymi regułami MISRA) nie zawsze je rozpoznaje. W tym wypadku mającego nazwy zmiennych podoba
u8ReadIndex
,s16ADCValue
może być pomocny.Aplikacje węgierskie
Aplikacje węgierskie mają wyraźne zalety, jeśli chodzi o aplikacje komputerowe / internetowe, na przykład oferując wizualną różnicę między „niebezpiecznymi” ciągami a „bezpiecznymi” ciągami (tj. Wprowadzonymi przez użytkownika i tymi, które uciekły lub zostały odczytane z zasobów wewnętrznych lub cokolwiek innego ). Kompilator nie ma wiedzy o tym rozróżnieniu.
Jaki jest sens?
Używanie (systemów lub aplikacji) węgierskiego polega na tym, aby zły kod wyglądał źle .
Jeśli kopiujesz niebezpieczny ciąg bezpośrednio do bezpiecznego ciągu bez ucieczki, będzie wyglądać źle, jeśli użyjesz aplikacji węgierskiej.
Jeśli zwielokrotnisz liczbę całkowitą ze znakiem przez liczbę całkowitą bez znaku, kompilator (często po cichu) wypromuje tę liczbę do (możliwej ogromnej) liczby całkowitej bez znaku, co może skutkować błędem: system węgierski sprawia, że wygląda to źle.
W obu tych przypadkach notacja węgierska (Apps / Systems) przyspiesza formalne przeglądy kodu, ponieważ mniej odwołuje się do rodzaju zmiennej.
Ogólny
Ogólnie rzecz biorąc, moim zdaniem najważniejsze jest posiadanie standardu kodowania. To, czy korzysta z węgierskiego systemu, czy węgierskiego, czy nie, jest kwestią preferencji osobistych lub grupowych, podobnie jak wybór typów wcięć itp. Jednak cały zespół programistów pracuje z tymi samymi preferencjami.
źródło
Celem notacji węgierskiej jest zakodowanie informacji w identyfikatorze, których inaczej nie można zakodować w systemie typów. Moim zdaniem, jeśli ta informacja jest wystarczająco ważna, aby ją zakodować, to jest wystarczająco ważna, aby być zakodowana w systemie pisma, gdzie można ją właściwie sprawdzić. A jeśli informacja nie jest ważna, to dlaczego, do cholery, chcesz zaśmiecać nią swój kod źródłowy?
Lub, mówiąc bardziej zwięźle: informacje o typie należą do systemu typów. (Uwaga: nie musi to być system typu statycznego . Dopóki wyłapuje błędy typu, nie obchodzi mnie, kiedy je wychwytuje.)
Kilka innych odpowiedzi wymieniło Jednostki miary jako dopuszczalne zastosowania notacji węgierskiej. (Jestem trochę zaskoczony, że nikt jeszcze nie wspomniał o NASA Mars Climate Orbiter, ponieważ wydaje się, że pojawia się to cały czas w dyskusjach na temat notacji węgierskiej).
Oto prosty przykład w F #:
Spójrz, mamo, nie ma Węgrów!
Gdybym był w użyciu notacja węgierska zamiast typów tu nie pomoże mi jeden bit:
Kompilator przepuścił go prosto. Teraz polegam na człowieku, który dostrzega błąd, który jest zasadniczo błędem typu. Czy nie po to jest sprawdzanie typu?
Jeszcze lepiej, używając języka programowania Frink :
Podsumowując: nie lubię notacji węgierskiej. Nigdy nie powinieneś go używać.
Biorąc to pod uwagę, myślę, że używanie notacji węgierskiej jest dobrym pomysłem. Czekaj, co?
Tak! W tym konkretnym przypadku wspomniałeś:
Ale to jest właśnie jedyny rozsądny przypadek użycia dla notacja węgierska!
PS: Z całego serca polecam patrzeć na Frinka. Jego instrukcja zawiera jedne z najbardziej niesamowitych dowcipów z pierdnięciem. To także całkiem fajny język :-)
źródło
typedef meter float
...Nie ma to sensu w języku zorientowanym obiektowo - wszystko jest typem, który jest widoczny, gdy próbuje się go użyć.
źródło
Jedynym miejscem, w którym System Węgier jest ostrzeżony, jest słabo napisany język, taki jak C. Jest to podwójnie ważne w C, ponieważ nie ma wyraźnego obiektu (ma struktury, ale wszystkie funkcje są zewnętrzne względem struktury). W czymś silniej wpisanym, takim jak C ++, Java i C #, to nie pomaga, a nawet pogarsza sytuację. Zmiany kodu i zmiana typu jest dużo łatwiejsza niż zmiana wszystkich miejsc, w których używasz nazwy zmiennej. Jest to również niepotrzebne zajęcie, które zwykle jest ignorowane.
Jeśli masz jednostki miary, może to pomóc zakodować to w nazwie - ale ostatecznie może to być dodatkowy szum. Na przykład zadeklarujemy standardową jednostkę miary dla różnych rzeczy, z którymi pracujemy w naszym kodzie. Na przykład, czy używamy gradientów lub stopni, metrów lub stóp, ramek lub milisekund? Po ustawieniu standardu dla kodu, za każdym razem, gdy czytamy w jednej jednostce miary, zawsze konwertujemy natychmiast na standardową jednostkę miary dla kodu.
Moja rada : zacznij od obecnych punktów bólu i wybierz rozsądny standard dla tej części kodu. Przekroczenie standardu kodowania przynosi efekt przeciwny do zamierzonego. Posiadanie nazw zmiennych i pól, które określają ich reprezentację, ma dużą wartość i przez większość czasu można bezpiecznie wywnioskować typ z tej koncepcji.
źródło
NA PEWNO NIE!
Nie używaj notacji węgierskiej ani żadnej innej notacji. Jako programiści nie powinniśmy używać „notacji” dla naszych nazw zmiennych.
Powinniśmy dobrze nazwać nasze zmienne :
z
gdy jest to zmienna klasowa reprezentująca nazwany obiekt, powiedzmy rachunek telefoniczny. Nazwij tophoneBill
lubPhoneBill
.Unikaj zbyt specyficznych nazw. Gdy coś jest jasne bez dodatkowych informacji, nie uwzględniaj tego. Jeśli jest to tylko zmienna indeksu ciągów do przechodzenia między znakami ciągu, a używasz go tylko raz w funkcji MyFunc, dlaczego, do licha, miałbyś go tak nazywać
MyFuncTempStringCharacterIndex
? To smutny żart. ZadzwońPos
lub naweti
jeśli chcesz. W kontekście następny programista łatwo zrozumie, co to znaczy.Przy określaniu, jak ogólna lub szczegółowa powinna być nazwa, należy wziąć pod uwagę domenę i kontekst innych możliwych znaczeń. W wąskim przypadku, gdy istnieją dwa łatwo mylące, podobne typy elementów, które są używane w ten sam sposób, dobrze jest wymyślić prefiks lub sufiks, aby wskazać tę różnicę. Trzymaj to tak krótko, jak to możliwe.
Jak powiedzieli inni odpowiedzieli, w tym wąskim przypadku uruchomiono „Aplikacje węgierskie”, aby rozróżnić pomiary względem okna
rwTabPosition
i względem dokumenturdTabPosition
. Ale w aplikacji, która robi wszystko w stosunku do dokumentu, nie dodawaj żadnych dodatkowych cruft! W rzeczywistości, dlaczego nie wykorzystać pomysłu Jörga W Mittaga, aby stworzyć z niego naprawdę nowy typ? Wtedy nie możesz pomylić rzeczy.W prawie każdym obszarze dodanie rzeczy, które mają minimalną gęstość znaczeń, zmniejsza ogólną sensowność i łatwość zrozumienia. Oto jeden przykład z Bena Franklina . I inny przykład: w języku angielskim można ozdobić nasze słowa ich częścią mowy. To więcej informacji, prawda? W przypadku pomieszania początkujących z angielskim, może to być dla nich naprawdę pomocne, prawda? Przeczytaj to i powiedz mi, jak przydatne jest to dla długoterminowego zrozumienia i skutecznego przekazywania informacji:
Przez dodanie informacji, że zrobiłem kompletny ból czytać.
Więc zapomnij o notacji. Zapomnij o specjalnych prefiksach, które zawsze dodajesz. Moim zdaniem jedyną prawdziwą wytyczną powinna być:
źródło
Cel identyfikatora jest ważniejszy niż jego typ. Jeśli używasz opisowych nazw dla identyfikatorów w swoich programach, nie musisz używać węgierskich notacji.
isConnected
jest zawsze bardziej czytelny i łatwy do zrozumienia niżboolConnected
.źródło
Kiedy byłem programistą C ++, używaliśmy węgierskiego i było świetnie. Możesz zobaczyć typ zmiennej (np. BSTR, CString, LPCTSTR lub char *) bez wyszukiwania deklaracji. W tych dniach szukałeś deklaracji, wykonując:
To miało znaczenie. Ale gdzieś około 2000 roku wydarzyło się kilka rzeczy:
lastName
jestSystem.String
, ponieważ istnieje tylko jedna klasa ciągów.Byłem jednym z ostatnich, którzy zrezygnowali z węgierskiego, a teraz, gdy czytam stary kod źródłowy, to mnie denerwuje.
źródło
Nienawidzę węgierskiego zapisu, wolę używać podkreślników niż rozgraniczać nazwy zmiennych.
Ponadto, gdy umieścisz typ jako pierwszą literę na początku nazwy zmiennej w następujący sposób: float fvelocity; vect vDirection; ciąg ** ppszWord;
autouzupełnianie sortuje je wszystkie i masz problem ze znalezieniem tego, czego chcesz, a ludzie zwykle używają tego, co według nich jest lepsze, i nie jest to już notacją.
Po prostu lubię pisać ThingsLikeThat, kiedy muszę bardzo opisowo opisywać zmienną, ponieważ oszczędza ona miejsce, a fakt, że są wielkie litery, czyni ją bardziej czytelną.
Zazwyczaj robię to, nazywając moje metody i klasy, pierwszą literą jest Wielka litera i mała litera dla nazw zmiennych oraz podkreślenie dla nazw zmiennych (uważam, że ta ostatnia jest przydatna).
Poważnie wolę, aby ludzie dbali o te zasady: używaj przecinków, arytmetyki i nawiasów klamrowych z odpowiednimi spacjami:
Nie więcej niż 80 znaków na linię lub AT MOST 90 znaków, używaj wieloliniowych argumentów dla funkcji lub długich
if
:źródło
Zgadzam się z większością, to stary styl.
W przypadku nowoczesnych IDE szybkie najechanie kursorem na zmienną pokazuje typ.
źródło