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

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?

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

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.

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

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.

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.

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

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?).

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.