Jaki jest urok systemów węgierskich? [Zamknięte]

18

W jakich wytycznych dotyczących nazewnictwa przestrzegasz? , autor mówi:

Wolę też kodować za pomocą węgierskiej notacji Charlesa Simonyi.

Natknąłem się na kilku programistów, którzy nadal wolą używać węgierskiego, głównie węgierskiego smaku Petzold / Systems. Myśleć dwLength = strlen(lpszName).

Przeczytałem „Poprawny wygląd kodu” i rozumiem uzasadnienie dla aplikacji w języku węgierskim, w których informacje o typach domen są zawarte w nazwach zmiennych. Ale nie rozumiem wartości przypisywania typu kompilatora do nazwy.

Dlaczego programiści nadal używają tego stylu notacji? Czy to tylko bezwładność? Czy są jakieś korzyści przewyższające zmniejszoną czytelność? Czy ludzie po prostu uczą się ignorować dekoratorów podczas czytania kodu, a jeśli tak, to w jaki sposób nadal zwiększają wartość?

EDYCJA: Wiele odpowiedzi wyjaśnia historię lub dlaczego nie jest już istotna, obie są ujęte w cytowanym przeze mnie artykule.

Naprawdę chciałbym usłyszeć od każdego, kto nadal go używa. Dlaczego go używasz? Czy to w twoim standardzie? Czy użyłbyś go, gdyby nie był wymagany? Czy użyłbyś go w nowym projekcie? Jakie są zalety?

AShelly
źródło
5
Notacja węgierska była na topie, kiedy zaczynałem w branży IT, ale było to środowisko całkowicie kodujące. Prosty edytor tekstowy bez podświetlania składni, inteligencji i plików kodowych o długości kilkuset linii ze wszystkimi zmiennymi zadeklarowanymi na początku. To po prostu ułatwiło życie w wypracowaniu tego, z czym masz do czynienia. Jednak dzięki nowoczesnym narzędziom i praktykom taka potrzeba stała się moją opcją i naprawdę należy ją
przenieść
1
Korzystałem z tego lata temu i nigdy nie podobało mi się to zbytnio. W ogóle mi tego nie brakuje.
MetalMikester
imo największym problemem było używanie prefiksów zamiast sufiksów - nawet w węgierskich aplikacjach „brodawka” zwykle zawiera mniej informacji semantycznych niż reszta nazwy
jk.

Odpowiedzi:

38

W tej chwili nadal używam węgierskiego z dokładnie trzech powodów , rozsądnie unikając go dla wszystkiego innego:

  1. Aby zachować zgodność z istniejącą bazą kodu podczas wykonywania konserwacji.
  2. Do kontroli, np. „txtFirstName”. Często musimy rozróżniać (powiedzmy) „firstName” wartość od „firstName” formantu. Węgierski zapewnia wygodny sposób na zrobienie tego. Oczywiście mógłbym wpisać „firstNameTextBox”, ale „txtFirstName” jest równie łatwe do zrozumienia i zawiera mniej znaków. Co więcej, użycie węgierskiego oznacza, że ​​formanty tego samego typu są łatwe do znalezienia i często są pogrupowane według nazwy w IDE.
  3. Gdy dwie zmienne mają tę samą wartość, ale różnią się typem. Na przykład „strValue” dla wartości faktycznie wpisanej przez użytkownika i „intValue” dla tej samej wartości po jej przeanalizowaniu jak w liczbie całkowitej.

Z pewnością nie chciałbym traktować moich pomysłów jako najlepszej praktyki, ale przestrzegam tych zasad, ponieważ doświadczenie mówi mi, że od czasu do czasu można korzystać z węgierskiej łatwości zarządzania kodem korzyści, ale niewiele kosztuje. To powiedziawszy, stale weryfikuję swoją własną praktykę, więc może rozwijać się w miarę rozwoju moich pomysłów.


Aktualizacja:

Właśnie przeczytałem wnikliwy artykuł Erica Lipperta, wyjaśniający, w jaki sposób język węgierski może pomóc, aby zły kod wyglądał źle. Warto przeczytać.

Kramii Przywróć Monikę
źródło
Doskonała odpowiedź, firefly odpowiada na zadane pytanie.
AShelly
właśnie zauważyłem kreatywną edycję mojego iPhone'a ... gsub („świetlik”, „w pełni”);
AShelly
5
+1 za użycie quasi-węgierskiego w celu ułatwienia grupowania kontroli interfejsu użytkownika w IDE. To jedyne zastosowanie, które wciąż ma sens w przypadku nowych projektów i po prostu nie mógłbym bez niego żyć. Często wiem, że formant jest polem tekstowym, ale nie wiem, czy nazywa się „FirstName”, czy po prostu „Name”.
Cody Gray
2
Zgadzam się na tę odpowiedź. Używając intValue i strValue, możesz również zobaczyć go jako valueAsInt i valueAsStr, więc nie wiem, czy rozważę tę węgierską notację, to raczej int i str są częścią nazwy zmiennej.
Michel Keijzers,
2
2 Wolę pełne sufiksy, ponieważ prefiksy mogą być dość głupie (co to jest tssba tsddi? Tak, istnieją). Skróty mają również problem jednorodności, biorąc TextBoxnie może być niespójność o to, czy jest to tbalbo txt(osobiście widziałem „Senior” dev wykorzystania zarówno na pojedynczym oknie). Dla 3 upuszczam węgierski, kiedy zmienna osiąga ostateczny zamierzony typ (np. Użyłbym valuei strValuew twoim przykładzie).
Jonathan Dickinson
6

Nie jestem wielkim fanem używania węgierskiej notacji, ale pomyśl w ten sposób:

  • Możemy również zauważyć, że szybciej jest znaleźć ciąg znaków odnoszący się do TextBox w kodzie: wpisując „txt” w polu wyszukiwania.

Nie wyobrażaj sobie czegoś przeciwnego, w którym każdy element ma swoją nazwę. Znalezienie miejsca, w którym chcesz się udać, może być wolniejsze, prawda?

To samo dotyczy ddl, gdy chcemy odwoływać się do DropDownList, czy jest łatwiej czy nie? :)

Ludzie nie spędzą dużo czasu, aby dowiedzieć się, gdzie jest ten element.

Używanie przedrostka nie jest użyteczne w nowoczesnych kompilatorach języków, takich jak C #, ale jest użyteczne (czytelne) dla ludzi.

Junior M.
źródło
To najlepszy przykład jego praktycznej wartości, jaki słyszałem. (Ale wciąż nie wystarczy, żebym go przyjął :)
AShelly,
1
Prefiksy nigdy nie były dla kompilatorów, zawsze dla ludzi. To, co się zmieniło, to nie kompilatory, ale IDE, które dostarczają informacji o typie i bardziej efektywnych sposobów poruszania się po kodzie.
Jeremy
Zrobię to samo ze zmiennymi i (szczególnie) widżetami - często dając im krótkie prefiksy dla oznaczenia ich typu. Ale nie do tego stopnia, żeby się na nich „całkowicie węgierski”.
GrandmasterB
4

Aplikacje węgierskie (tagi określające właściwości semantyczne obiektów, których nie można wyrazić za pomocą systemu czcionek) były rozsądnym sposobem radzenia sobie z niektórymi typowymi błędami przy użyciu słabo typowanych języków z początku lat osiemdziesiątych. Nie mają większego sensu w dzisiejszych silnie pisanych językach.

System węgierski (tagi nadmiarowo oznaczające zadeklarowany typ obiektu) nigdy nie służył żadnemu celowi poza narzucaniem powierzchownie jednolitego wyglądu bazy kodu. Został on stworzony i rozpowszechniony przez nietechnicznych menedżerów oraz niedoświadczonych programistów, którzy źle zrozumieli zamiar Apps Hungarian i wierzyli, że jakość kodu można poprawić dzięki złożonym wytycznym kodowania.

Oba style powstały w Microsoft. Obecnie konwencje nazewnictwa Microsoft kategorycznie mówią „Nie używaj notacji węgierskiej”.

Mike Seymour
źródło
4

Jeśli wybierzesz odpowiedni system prefiksów, możesz rozłożyć zużycie klawiszy, co zmniejszy wydatki na klawiatury zastępcze.


Podejrzewam, że mógłbym to rozwinąć. Używam SH w moim miejscu pracy przez ostatnie, och, dziesięć lat (bo to jest w naszym standardzie). To nigdy nie pomogło rozwiązać problemu.

Z drugiej strony używałem nieosłoniętych, ale dobrze nazwanych zmiennych w moim „kodzie domowym” prawie tak samo długo. Nigdy nie przegapiłem SH.

W obu miejscach napisałem kod protokołu, który wymaga typów pierwotnych o stałym rozmiarze. Jest to najbardziej korzystny przypadek użycia, jaki mogę wymyślić dla SH. Nie pomogło mi to stwierdzić po napisaniu za pomocą SH i nie przeszkodziło mi to, gdy napisano bez SH.

Podsumowując, jedyną różnicą, którą widzę, jest zużycie klawiatury.

Kaz Dragon
źródło
1
jak tam sarkazm :)
JohnL
4

Właściwie zacząłem używać SH w nowym kodzie, który napisałem w tym miesiącu.

Moje zadanie polegało na przepisaniu kodu Perla w JS, aby mógł zostać przeniesiony na stronę klienta naszej aplikacji internetowej. W Perlu SH nie jest generalnie wymagane ze względu na sigile ($ string, @array,% hash).

W JavaScript odkryłem, że SH jest nieoceniony do śledzenia typów struktur danych. Na przykład,

var oRowData = aoTableData[iRow];

To pobiera obiekt z tablicy obiektów za pomocą indeksu liczb całkowitych. Przestrzeganie tej konwencji pozwoliło mi zaoszczędzić sporo czasu na wyszukiwaniu typów danych. Ponadto możesz przeciążać zwięzłe nazwy zmiennych ( oRowvs. iRow).

tl; dr: SH może być świetny, gdy masz złożony kod w słabo napisanym języku. Ale jeśli twoje IDE może śledzić typy, preferuj to.

Stefan Majewsky
źródło
2

Jestem również ciekawy uzasadnienia. Wiemy, dlaczego używali go w przeszłości: brak obsługi IDE dla informacji o typie. Ale teraz? Mówiąc najprościej, myślę, że to tradycja. Kod C ++ zawsze tak wyglądał, więc po co zmieniać rzeczy? Poza tym, jeśli zbudujesz na podstawie poprzedniego kodu, który używał węgierskiej notacji, wyglądałoby to dość dziwnie, gdy nagle przestaniesz używać tego ...

Paweł Dyda
źródło
2
Kod C ++ nie zawsze tak wyglądał - sprawdź książkę Bjarne Stroustrup.
JBRWilkinson
@JBRWilkinson: Charles Simonyi utworzył notację węgierską około 1976 r. ( C2.com/cgi/wiki?HungarianNotation ). Tak więc ta notacja faktycznie poprzedza C ++. Wielu, jeśli nie większość programistów C ++ używa go od pierwszego dnia (to znaczy ich kodowania). Rozumiem, że Bjarne Stroustrup jest godnym uwagi wyjątkiem, podobnie jak Linus Torvalds, ale to nie zmienia faktów.
Paweł Dyda
2
Myślę, że węgierski zawsze był przede wszystkim sprawą Microsoftu. Nie widziałem, żeby był często używany w środowiskach uniksowych i podobnych.
David Thornley,
2

Systemowa notacja węgierska była w rzeczywistości trochę zawracaniem głowy, nieporozumieniem z terminem „typ”. Deweloperzy systemów przyjęli to dosłownie jako typ kompilatora (słowo, bajt, ciąg, ...) w przeciwieństwie do typu domeny aplikacji (indeks wierszy, indeks kolumn, ...).

Ale myślę, że każdy programista przechodzi przez kilka faz stylu, które wydają się świetnym pomysłem w danym momencie (a typ prefiksu wydaje się być dobrym pomysłem dla początkującego), zanim wpadnie w pułapki (zmiana typu, tworzenie nowych, znaczących prefiksów, itp). Sądzę więc, że istnieje bezwładność: od deweloperów, którzy nie poprawiają się i zdają sobie sprawę, dlaczego jest to zły wybór, od programistów trzymających się standardów kodowania, które nakazują tę praktykę, i od osób używających <windows.h>. Zbyt kosztowne byłoby, aby Microsoft zmienił się, aby pozbyć się notacji prefiksu (co w wielu miejscach jest niepoprawne: WPARAM?).

Skizz
źródło
1
Nawet zamierzone użycie jest mniej niż optymalne, ponieważ tworzy prywatny system typów, o którym kompilator nie wie, a zatem nie może sprawdzić typu.
Larry Coleman
@ Larry: Chociaż jest to z pewnością prawda, dostępne jest oprogramowanie, które może analizować kod źródłowy i sprawdzać, czy kod jest zgodny ze standardem. Mogą być w stanie upewnić się, że prefiksy są zgodne w wyrażeniach.
Skizz
1
Moim ideałem przy korzystaniu z pisania statycznego jest, aby zestaw typów kompilatorów był nadzbiorem zestawu typów domen. Następnie kompilator może sprawdzić wszystko, bez żadnych dodatków.
Larry Coleman,
0

W Węgrzech brakuje jednej rzeczy. Notacja węgierska faktycznie działa WIELKO z funkcją autouzupełniania.

Załóżmy, że masz zmienną, a nazwa to intHeightOfMonster.

Powiedz, że zapomniałeś nazwy zmiennej

Może to być heightOfMonster lub MonsterHeight lub MeasurementMonsterHeight

Chcesz być w stanie wpisać literę i uzyskać autouzupełnianie zasugerować kilka nazw zmiennych.

Wiedząc, że heightOfMonster jest liczbą całkowitą, wystarczy wpisać i i voila.

Oszczędzaj czas.

użytkownik114310
źródło