Jaka jest korzyść z niestosowania notacji węgierskiej?

Jedną z rzeczy, z którymi się zmagam, jest niestosowanie węgierskiej notacji. Ja nie chcę iść do definicji zmiennej po prostu zobaczyć, jakiego rodzaju jest. Kiedy projekt się rozrasta, miło jest móc patrzeć na zmienną poprzedzoną przez „bool” i wiedzieć, że szuka wartości prawda / fałsz zamiast wartości 0/1 .

Wykonuję również dużo pracy w SQL Server. Moje procedury składowane poprzedzam „sp”, a tabele „tbl”, nie wspominając o wszystkich moich zmiennych odpowiednio w bazie danych.

Wszędzie widzę, że nikt tak naprawdę nie chce używać węgierskiej notacji, do tego stopnia, że ​​tego unikają. Moje pytanie brzmi: jaka jest korzyść z niestosowania węgierskiej notacji i dlaczego większość programistów unika tego jak zarazy?

Ponieważ jego pierwotna intencja (patrz http://www.joelonsoftware.com/articles/Wrong.html i http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids ) została źle zrozumiana i została ( ab) używane, aby pomóc ludziom zapamiętać, jaki jest typ zmiennej, gdy używany przez nich język nie jest wpisany statycznie. W żadnym statycznie wpisanym języku nie potrzebujesz dodanego balastu przedrostków, aby powiedzieć ci, jaki jest typ zmiennej. W wielu nietypowych językach skryptowych może to pomóc, ale często nadużywano go do tego stopnia, że ​​stał się całkowicie nieporęczny. Niestety, zamiast wracać do pierwotnej intencji węgierskiej notacji, ludzie właśnie przeszli do jednej z tych „złych” rzeczy, których powinieneś unikać.

Krótko mówiąc, zapis węgierski miał poprzedzać zmienne pewną semantyką. Na przykład, jeśli masz współrzędne ekranu (lewy, górny, prawy, dolny), prefiksujemy zmienne o bezwzględnych pozycjach ekranu za pomocą „ abs”, a zmienne o pozycjach względem okna za pomocą „ rel”. W ten sposób byłoby oczywiste dla każdego czytelnika, gdy przekazałeś współrzędną względną do metody wymagającej pozycji bezwzględnych.

aktualizacja (w odpowiedzi na komentarz delnan)

IMHO nadużywanej wersji należy unikać jak zarazy, ponieważ:

• komplikuje nazywanie. Gdy (ab) używa notacji węgierskiej, zawsze będą dyskusje na temat tego, jak szczegółowe powinny być prefiksy. Na przykład: listboxXYZlub MyParticularFlavourListBoxXYZ.
• wydłuża nazwy zmiennych, nie pomagając zrozumieć, do czego służy zmienna.
• w pewnym sensie pokonuje obiekt ćwiczenia, gdy w celu uniknięcia długich prefiksów skróca się je do skrótów i potrzebujesz słownika, aby wiedzieć, co oznacza każdy skrót. Czy uiliczba całkowita jest bez znaku? interfejs bez liczenia? coś wspólnego z interfejsami użytkownika? I te rzeczy mogą trwać długo . Widziałem prefiksy ponad 15 pozornie przypadkowych postaci, które mają przekazywać dokładny typ var, ale tak naprawdę tylko mistyfikować.
• szybko się zużywa. Kiedy zmieniasz typ zmiennej, ludzie niezmiennie (lol) zapomnij zaktualizować prefiks, aby odzwierciedlić zmianę, lub celowo nie aktualizuj go, ponieważ spowodowałoby to zmiany kodu wszędzie tam, gdzie używany jest var ...
• komplikuje mówienie o kodzie, ponieważ jako „@g”. powiedział: Nazwy zmienne z notacją węgierską są zwykle trudną do wymówienia zupą alfabetyczną. Utrudnia to czytelność i omawianie kodu, ponieważ nie można „powiedzieć” żadnej z nazw.
• ... wiele innych rzeczy, których w tej chwili nie pamiętam. Może dlatego, że miałem przyjemność nie radzić sobie z nadużywaną notacją węgierską przez długi czas ...

Notacja węgierska jest anty-wzorcem nazewnictwa we współczesnych środowiskach programistycznych i formie tautologii .

Bezużytecznie powtarza informacje bez korzyści i dodatkowych kosztów utrzymania. Co się stanie, gdy zmienisz swój inttyp na inny long, teraz musisz przeszukać i zastąpić całą bazę kodu, aby zmienić nazwy wszystkich zmiennych lub są one teraz semantycznie błędne, co jest gorsze, niż gdybyś nie powielił tego typu w nazwie.

To narusza zasadę SUCHEGO. Jeśli musisz poprzedzić tabele bazy danych skrótem, aby przypomnieć, że jest to tabela, to zdecydowanie nie nazywasz swoich tabel wystarczająco semantycznie opisowym. To samo dotyczy każdej innej rzeczy, z którą to robisz. To tylko dodatkowe pisanie i praca bez zysku lub korzyści w nowoczesnym środowisku programistycznym.

Wikipedia ma listę zalet i wad notacji węgierskiej i dlatego może prawdopodobnie zapewnić najbardziej wyczerpującą odpowiedź na to pytanie. Znane opinie są również dość interesującą lekturą.

Korzyścią z niestosowania węgierskiej notacji jest w zasadzie jedynie uniknięcie jej wad:

• Notacja węgierska jest zbędna, gdy kompilator dokonuje sprawdzania typu. Kompilatory dla języków zapewniające sprawdzanie typu zapewniają, że użycie zmiennej jest automatycznie zgodne z jej typem; kontrole wzrokowe są zbędne i podlegają błędom ludzkim.

• Wszystkie nowoczesne zintegrowane środowiska programistyczne wyświetlają zmienne typy na żądanie i automatycznie oflagują operacje, które wykorzystują typy niezgodne, przez co notacja jest w dużej mierze przestarzała.

• Notacja węgierska staje się myląca, gdy jest używana do reprezentowania kilku właściwości, takich jak a_crszkvc30LastNameCol: stały argument referencyjny, zawierający zawartość kolumny LastNametypu bazy danych, varchar(30)która jest częścią klucza podstawowego tabeli.

• Może to prowadzić do niespójności, gdy kod zostanie zmodyfikowany lub przeniesiony. Jeśli typ zmiennej zostanie zmieniony, albo dekoracja nazwy zmiennej będzie niezgodna z nowym typem, albo nazwa zmiennej musi zostać zmieniona. Szczególnie dobrze znanym przykładem jest WPARAMtyp standardowy i towarzyszący mu wParamparametr formalny w wielu deklaracjach funkcji systemu Windows. „W” oznacza „słowo”, gdzie „słowo” jest rodzimym rozmiarem architektury sprzętowej platformy. Pierwotnie był to 16-bitowy typ w 16-bitowych architekturach słów, ale został zmieniony na 32-bitowy w 32-bitowych architekturach słów lub 64-bitowy w 64-bitowych architekturach słów w późniejszych wersjach systemu operacyjnego, zachowując jego oryginalna nazwa (jej prawdziwy typ bazowy toUINT_PTR, czyli liczba całkowita bez znaku, wystarczająco duża, aby pomieścić wskaźnik). Impedancja semantyczna, a co za tym idzie zamieszanie programistów i niespójność między platformami, zakłada, że ​​„w” oznacza 16-bit w różnych środowiskach.

• Przez większość czasu znajomość użycia zmiennej oznacza znajomość jej typu. Ponadto, jeśli użycie zmiennej nie jest znane, nie można jej wywnioskować z jej typu.

• Notacja węgierska znacznie zmniejsza korzyści płynące z używania bogatych w funkcje edytorów kodu, które obsługują uzupełnianie nazw zmiennych, ponieważ programista musi najpierw wprowadzić specyfikator całego typu.

• Sprawia, że ​​kod jest mniej czytelny, zaciemniając cel zmiennej niepotrzebnymi prefiksami typu i zakresu.

• Dodatkowe informacje o typie mogą niewystarczająco zastąpić bardziej opisowe nazwy. Np. sDatabaseNie mówi czytelnikowi, co to jest. databaseNamemoże być bardziej opisową nazwą.

• Gdy nazwy są wystarczająco opisowe, dodatkowe informacje o typie mogą być zbędne. Np. firstNameNajprawdopodobniej jest łańcuchem. Tak więc nadanie mu nazwy sFirstNamedodaje bałaganu do kodu.

Ja sam nie używam tego zapisu, ponieważ nie lubię niepotrzebnego hałasu technicznego. Prawie zawsze wiem, z jakim typem mam do czynienia i chcę mieć czysty język w moim modelu domeny, ale piszę głównie w językach statycznych i silnie typowanych.

Jako problem specyficzny dla MS SQL Server:

Wszelkie procedury składowane z prefiksem „sp_” są najpierw wyszukiwane w głównej bazie danych, a nie w tej, w której zostały utworzone. Spowoduje to opóźnienie w wykonywaniu procedury przechowywanej.

Największą korzyścią IMO z niestosowania węgierskiego jest to, że zmusza cię do używania znaczących nazw . Jeśli poprawnie nazywasz zmienne, powinieneś natychmiast wiedzieć, jaki to typ, lub być w stanie dość szybko wydedukować je w dobrze zaprojektowanym systemie. Jeśli trzeba polegać na strlub blnlub gorszy od wszystkich objprefiksów wiedzieć, jakiego typu jest zmienna, będę argumentować, oznacza to problem nazewnictwa - albo biednych nazw zmiennych w sposób ogólny lub zbyt ogólne, aby przekazać znaczenie.

Jak na ironię, z własnego doświadczenia wynika, że ​​głównym scenariuszem, w którym widziałem język węgierski, jest albo program „kultu ładunków” (tzn. Używa go inny kod, więc używajmy go tylko dlatego, że tak się dzieje) lub w VB.NET, aby obejść ten fakt rozróżnianie wielkości liter (np. Person oPerson = new Personponieważ nie można użyć Person person = new Personi Person p = new Personjest zbyt niejasne); W tym przypadku widziałem też prefiks „the” lub „my” (jak w Person thePerson = new Personlub brzydsze Person myPerson = new Person).

Dodam, że jedyny raz, kiedy używam węgierskiego, jest formant ASP.NET i to jest naprawdę kwestia wyboru. Uważam, że pisanie TextBoxCustomerNamelub CustomerNameTextBoxprostsze jest bardzo brzydkie txtCustomerName, ale nawet to wydaje się „brudne”. Wydaje mi się, że do kontroli należy zastosować jakąś konwencję nazewnictwa, ponieważ może istnieć wiele formantów wyświetlających te same dane.

Skoncentruję się na SQL Server, odkąd o nim wspomniałeś. Nie widzę powodu, aby umieszczać „tbl” przed stołem. Możesz po prostu spojrzeć na dowolny kod tSQL i rozróżnić tabelę według sposobu jego użycia. Nigdy nie Select from stored_procedure.lub nie Select from table(with_param)chcesz UDF lub Execute tblTableOrViewNamejak procedura składowana.

Tabele można pomylić z widokiem, ale jeśli chodzi o sposób ich użycia; nie ma różnicy, więc o co chodzi? Notacja węgierska może zaoszczędzić czas na wyszukiwanie w SSMS (pod tabelą lub widokami?), Ale o to chodzi.

Zmienne mogą stanowić problem, ale należy je zadeklarować i jak daleko od instrukcji deklaracji zamierzasz używać zmiennej? Przewijanie kilku wierszy nie powinno być wielkim problemem, chyba że piszesz bardzo długie procedury. Dobrym pomysłem może być trochę rozbicie długiego kodu.

Opisujesz ból, ale rozwiązanie węgierskiej notacji tak naprawdę nie rozwiązuje problemu. Możesz spojrzeć na kod innej osoby i stwierdzić, że typ zmiennej może ulec zmianie, co wymaga teraz zmiany nazwy zmiennej. Jeszcze tylko jedna rzecz do zapomnienia. A jeśli użyję VarChar, i tak będziesz musiał spojrzeć na instrukcję deklaracji, aby poznać rozmiar. Nazwy opisowe zapewne doprowadzą cię dalej. @PayPeriodStartDate prawie się wyjaśnia.

Inną rzeczą do dodania jest to, jakich skrótów użyłbyś dla całego frameworku, takiego jak .NET? Tak, tak łatwo jest pamiętać, że btnreprezentuje przycisk i txtreprezentuje pole tekstowe. Co jednak masz na myśli StringBuilder? strbld? Co CompositeWebControl? Czy używasz czegoś takiego:

CompositeWebControl comWCMyControl = new CompositeWebControl();

Jedną z nieefektywności węgierskiej notacji było to, że posiadając coraz większe frameworki, okazało się nie tylko nieść dodatkowe korzyści, ale także zwiększyć złożoność dla programistów, ponieważ musieli oni teraz coraz częściej uczyć się niestandardowych prefiksów.

Według mojego spojrzenia na sprawy, notacja węgierska stanowi kłopot dla obejścia niewystarczająco wydajnego systemu pisma. W językach, które pozwalają definiować własne typy, tworzenie nowego typu, który koduje oczekiwane zachowanie, jest stosunkowo proste. W tekście Joela Spolsky'ego dotyczącym notacji węgierskiej podaje przykład wykorzystania go do wykrywania możliwych ataków XSS, wskazując, że zmienna lub funkcja jest albo niebezpieczna (my), albo bezpieczna (e), ale to wciąż programista musi sprawdzić wizualnie. Jeśli zamiast tego masz rozszerzalny system typów, możesz po prostu utworzyć dwa nowe typy, UnsafeString i SafeString, a następnie użyć ich odpowiednio. Jako bonus typ kodowania staje się:

SafeString encode(UnsafeString)

i brak dostępu do wewnętrznych elementów UnsafeString lub korzystanie z innych funkcji konwersji staje się jedynym sposobem na przejście z UnsafeString do SafeString. Jeśli wszystkie funkcje wyjściowe biorą tylko instancje SafeString, niemożliwe jest wyprowadzenie ciągów, które nie są znakami ucieczki [wykluczając shenanigany za pomocą konwersji takich jak StringToSafeString (someUnsafeString.ToString ())].

Powinno być oczywiste, dlaczego pozwolenie systemowi poczytalności na sprawdzenie poprawności kodu jest lepsze niż próba zrobienia tego ręcznie, a może w tym przypadku oko.

W języku, takim jak C, oczywiście wkręca cię to, że int jest int jest int, i nie możesz na to wiele poradzić. Zawsze możesz grać w gry ze strukturami, ale można się zastanawiać, czy to poprawa, czy nie.

Co do innej interpretacji notacji węgierskiej, prefiks IE z typem zmiennej, jest to po prostu głupie i zachęca do leniwych praktyk, takich jak nazywanie zmiennych uivxwFoo zamiast czegoś znaczącego, takiego jak countOfPeople.

Notacja węgierska jest prawie całkowicie bezużyteczna w języku pisanym statycznie. Jest to podstawowa funkcja IDE, która pokazuje typ zmiennej poprzez umieszczenie myszy nad nią lub w inny sposób; ponadto możesz zobaczyć, jaki jest typ, patrząc na kilka linii w górę tam, gdzie został zadeklarowany, jeśli nie ma wnioskowania o typie. Istotą wnioskowania o typie jest nie powtarzanie wszędzie takiego szumu, więc węgierska notacja jest zwykle postrzegana jako zła rzecz w językach z wnioskowaniem o typie.

W dynamicznie wpisywanych językach czasem może to pomóc, ale dla mnie wydaje się jednoznaczne. Już zrezygnowałeś z funkcji ograniczonych do dokładnych domen / kodomains; jeśli wszystkie twoje zmienne są nazwane węgierską notacją, to po prostu odtwarzasz to, co dałby ci system typów. Jak wyrazić zmienną polimorficzną, która może być liczbą całkowitą lub łańcuchem w notacji węgierskiej? „IntStringX”? „IntOrStringX”? Jedynym miejscem, w którym kiedykolwiek używałem węgierskiej notacji, był kod asemblera, ponieważ próbowałem odzyskać to, co dostanę, gdybym miał system pisma, i to była pierwsza rzecz, jaką kodowałem.

Tak czy inaczej, nie obchodzi mnie, jak ludzie nazywają swoje zmienne, kod prawdopodobnie nadal będzie tak samo niezrozumiały. Programiści marnują zbyt wiele czasu na takie rzeczy, jak styl i nazwy zmiennych, a pod koniec dnia wciąż masz mnóstwo bibliotek z zupełnie innymi konwencjami w Twoim języku. Rozwijam język symboliczny (tj. Nietekstowy), w którym nie ma nazw zmiennych, tylko unikalne identyfikatory i sugerowane nazwy zmiennych (ale większość zmiennych wciąż nie ma sugerowanych nazw, ponieważ po prostu nie istnieje rozsądna nazwa dla im); podczas kontroli niezaufanego kodu nie można polegać na nazwach zmiennych.

Jak zwykle w takim przypadku, opublikuję odpowiedź, zanim przeczytam odpowiedzi od innych uczestników. 

Widzę trzy „błędy” w twojej wizji: 

1) Jeśli chcesz poznać typ zmiennej / parametru / atrybutu / kolumny, możesz najechać myszą lub kliknąć ją, a zostanie wyświetlona w najnowocześniejszym IDE. Nie wiem, jakich narzędzi używasz, ale ostatnim razem byłem zmuszony do pracy w środowisku, które nie zapewniało tej funkcji, w XX wieku, językiem był COBOL, oops nie, to był Fortran, a mój szef nie rozumiem, dlaczego odszedłem. 

2 / Rodzaje mogą ulec zmianie w trakcie cyklu rozwoju. 32-bitowa liczba całkowita może w pewnym momencie stać się 64-bitową liczbą całkowitą, z dobrych powodów, których nie wykryto na początku projektu. Tak więc zmiana nazwy intX na longX lub pozostawienie go z nazwą wskazującą na niewłaściwy typ to zła karma. 

3) To, o co prosisz, to w rzeczywistości redundancja. Redundancja nie jest dobrym wzorcem projektowym ani nawykiem. Nawet ludzie są niechętni zbytniej redundancji. Nawet ludzie są niechętni zbytniej redundancji. 

Uważam, że bycie w potrzebie węgierskiego jest objawem .
Objaw zbyt wielu zmiennych globalnych ... lub zbyt długich funkcji, aby można je było utrzymać .

Jeśli Twoja definicja zmiennej nie jest widoczna, zazwyczaj masz problemy.
A jeśli twoje funkcje nie są zgodne z niezapomnianą konwencją , to znowu, duży problem.

To ... to chyba powód, dla którego wiele miejsc pracy tak go wyśmiewa.

Pochodzi z języków, które tego potrzebowały .
W czasach globalnych zmiennych bonanza . (z braku alternatyw)
Dobrze nam to służyło.

Jedynym prawdziwym użycie mamy za to dzisiaj jest Joel Spolsky jeden .
Aby śledzić niektóre szczególne atrybuty zmiennej, takie jak jej bezpieczeństwo .

( np. „Czy zmienna safeFoobarma zielone światło, które należy wprowadzić do zapytania SQL?
- Jak się nazywa safe, tak”)

Niektóre inne odpowiedzi mówiły o funkcjach edytora, które pomogły zobaczyć typ zmiennej podczas najechania na nią. Moim zdaniem, one również stanowią pewien problem dla bezpieczeństwa kodu . Uważam, że były one przeznaczone tylko do refaktoryzacji , podobnie jak wiele innych funkcji (takich jak składanie funkcji) i nie powinny być używane w nowym kodzie.

Myślę, że powody, dla których nie używano węgierskiej notacji, zostały dobrze omówione przez inne plakaty. Zgadzam się z ich komentarzami.

W bazach danych używam notacji węgierskiej dla obiektów DDL, które rzadko są używane w kodzie, ale w przeciwnym razie kolidowałyby w przestrzeniach nazw. Głównie sprowadza się to do prefiksowania indeksów i nazwanych ograniczeń ich typem (PK, UK, FK i IN). Użyj spójnej metody, aby nazwać te obiekty, a powinieneś być w stanie uruchomić sprawdzanie poprawności poprzez zapytanie do metadanych.

powodem tego jest to, że system węgierski narusza DRY (prefiks jest dokładnie tym typem, który może uzyskać kompilator i (dobre) IDE)

aplikacje węgierskie prefiksy OTOH za pomocą zmiennej (tj. scrxMouse jest współrzędną topora na ekranie może to być int, krótki, długi lub nawet niestandardowy typ (typedefs pozwoli nawet łatwo to zmienić))

nieporozumienie systemów zniszczyło węgierski kraj jako najlepszą praktykę

Powiedzmy, że mamy taką metodę (w C #):

int GetCustomerCount()
{
    // some code
}

Teraz w kodzie nazywamy to tak:

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

Int nie mówi nam bardzo wiele. Sam fakt, że coś jest intem, nie mówi nam, co w tym jest. Załóżmy teraz, że nazywamy to tak:

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

Teraz możemy zobaczyć, jaki jest cel zmiennej. Czy miałoby to znaczenie, gdybyśmy wiedzieli, że to int?

Pierwotnym celem Węgier było jednak zrobienie czegoś takiego:

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

Jest to w porządku, o ile wiesz, co oznacza c . Ale musiałbyś mieć standardową tabelę prefiksów i wszyscy musieliby je znać, a każda nowa osoba musiałaby się ich nauczyć, aby zrozumieć Twój kod. Natomiast customerCountlub countOfCustomersjest dość oczywiste na pierwszy rzut oka.

Węgierski miał jakiś cel w VB, zanim Option Strict Onistniał, ponieważ w VB6 i wcześniejszych (i w VB .NET z Option Strict Off) VB wymuszałoby typy, więc możesz to zrobić:

Dim someText As String = "5"
customerCount = customerCount + someText

To źle, ale kompilator by tego nie powiedział. Więc jeśli użyjesz węgierskiego, przynajmniej będziesz miał pewien wskaźnik tego, co się dzieje:

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

W .NET, przy wpisywaniu statycznym, nie jest to konieczne. A węgierski był zbyt często używany jako substytut dobrego imienia. Zapomnij o węgierskim i wybierz dobre imię.

Znalazłem wiele dobrych argumentów przeciwko, ale jednego nie widziałem: ergonomii.

W dawnych czasach, gdy wszystko, co miałeś, to string, int, bool i float, znaki sibf byłyby wystarczające. Ale z łańcuchem + krótkim zaczynają się problemy. Użyć całej nazwy dla prefiksu lub str_name dla ciągu? (Chociaż nazwy są prawie zawsze ciągami - prawda?) Co jest z klasą Street? Nazwy stają się coraz dłuższe i nawet jeśli używasz CamelCase, trudno jest powiedzieć, gdzie kończy się prefiks typu i gdzie zaczyna się nazwa zmiennej.

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

Okej - możesz użyć podkreśleń, jeśli nie używasz ich już do czegoś innego, lub użyć CamelCase, jeśli używasz podkreśleń tak długo:

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

To potworne, a jeśli zrobisz to konsekwentnie, będziesz miał

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

Albo skończysz na używaniu bezużytecznych prefiksów w trywialnych przypadkach, takich jak zmienne pętlowe lub count. Kiedy ostatnio używałeś krótkiego lub długiego licznika? Jeśli robisz wyjątki, często tracisz czas, myśląc o potrzebie prefiksu, czy nie.

Jeśli masz wiele zmiennych, zwykle są one pogrupowane w przeglądarce obiektów, która jest częścią twojego IDE. Teraz, jeśli 40% zaczyna się od i_ dla int, a 40% z s_ dla string, a są one posortowane alfabetycznie, trudno jest znaleźć znaczną część nazwy.

Jedynym miejscem, w którym wciąż regularnie używam węgierskich lub analogicznych sufiksów, są konteksty, w których te same dane semantyczne występują w dwóch różnych formach, takich jak konwersja danych. Może się tak zdarzyć w przypadkach, gdy istnieje wiele jednostek miary lub istnieje wiele form (np. Ciąg „123” i liczba całkowita 123).

Uważam, że podane tutaj powody, dla których nie używałem tego języka, nie zachęcają innych do narzucania węgierskiego, ale są jedynie lekko sugestywne, aby decydować o własnej praktyce.

Kod źródłowy programu jest sam w sobie interfejsem użytkownika - wyświetla algorytmom i metadanym opiekunowi - a nadmiarowość interfejsów użytkownika jest zaletą, a nie grzechem . Zobacz np. Zdjęcia w „ The Design of Everyday Things ” i spójrz na drzwi z napisem „Push”, które wyglądają, jakbyś je pociągnął, a na krany piwa operatorzy włamali się na ważne elementy sterowania reaktora jądrowego, ponieważ „unosiły się nad nim” w IDE ”nie było wystarczająco dobre.

„Po prostu najechanie na IDE” nie jest powodem, aby nie używać węgierskiego - tylko powodem, dla którego niektórzy ludzie mogą nie uznać go za użyteczny. Twój przebieg może się różnić.

Pomysł, że Węgier nakłada znaczne obciążenia konserwacyjne, gdy zmiana typów zmiennych jest głupi - jak często zmieniasz typy zmiennych? Poza tym zmiana nazw zmiennych jest łatwa:

Wystarczy użyć IDE, aby zmienić nazwę wszystkich wystąpień. -Gander, odpowiadając na Goose

Jeśli język węgierski naprawdę pomaga szybko odczytać fragment kodu i niezawodnie go zachować, użyj go. Jeśli nie, nie rób tego. Jeśli inni powiedzą ci, że mylisz się co do własnych doświadczeń, sugeruję, że to oni prawdopodobnie są w błędzie.