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?
coding-style
coding-standards
naming
user29981
źródło
źródło
Odpowiedzi:
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ż:
listboxXYZ
lubMyParticularFlavourListBoxXYZ
.ui
liczba 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ć.źródło
AbsoluteXType
i aRelativeYType
, to nie możesz omyłkowo przekazać współrzędnej względnej Y dla absolutnej X. Wolę, aby zmienne reprezentujące niekompatybilne byty były niekompatybilnych typów, zamiast mieć niekompatybilne prefiksy. Kompilator nie dba o prefiksy (lub sufiksy).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
int
typ na innylong
, 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.
źródło
int
typ, na przykładlong
...” Proste: <sarkazm> Nie zmieniaj nazwy, ponieważ nie wiadomo, ile miejsc zmiana będzie falować. </sarkazm> Więc teraz masz zmienną, której Węgierska nazwa jest w konflikcie z jej implementacją. Nie ma absolutnie żadnego sposobu, aby powiedzieć, jak powszechne będą skutki zmiany nazwy, jeśli zmienna / funkcja będzie widoczna publicznie.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:
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.
źródło
Jako problem specyficzny dla MS SQL Server:
źródło
sp_
więc po prostu trzymałem się konwencji.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
str
lubbln
lub gorszy od wszystkichobj
prefiksó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 Person
ponieważ nie można użyćPerson person = new Person
iPerson p = new Person
jest zbyt niejasne); W tym przypadku widziałem też prefiks „the” lub „my” (jak wPerson thePerson = new Person
lub brzydszePerson 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
TextBoxCustomerName
lubCustomerNameTextBox
prostsze jest bardzo brzydkietxtCustomerName
, 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.źródło
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 nieSelect from table(with_param)
chcesz UDF lubExecute tblTableOrViewName
jak 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.
źródło
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
btn
reprezentuje przycisk itxt
reprezentuje pole tekstowe. Co jednak masz na myśliStringBuilder
?strbld
? CoCompositeWebControl
? Czy używasz czegoś takiego: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.
źródło
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ę:
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.
źródło
int[]
które mogą być dowolnie modyfikowane, ale nigdy nie mogą być udostępniane” lub „int[]
które mogą być swobodnie udostępniane tylko między rzeczami, które nigdy go nie modyfikują”? Jeśliint[]
polefoo
zawiera wartości, to czy{1,2,3}
można je kapsułkować,{2,2,3}
nie wiedząc, który „typ”int[]
reprezentuje? Sądzę, że Java i .NET byłyby znacznie lepsze, gdyby - przy braku obsługi systemu typów, przyjęły przynajmniej konwencję nazewnictwa w celu rozróżnienia tych typów.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.
źródło
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.
źródło
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
safeFoobar
ma 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.
źródło
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.
źródło
TABLE SomeStringById(int somestringId, varchar somestring)
indeks, logicznie byłoby,SomeStringById
ale to powoduje kolizję. Więc to nazywamidx_SomeStringById
. Następnie, aby pójść w ich ślady, zrobię toidx_SomeStringByValue
tylko dlatego, że głupotą jest miećidx_
jedną z nich, a nie drugą.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ę
źródło
Powiedzmy, że mamy taką metodę (w C #):
Teraz w kodzie nazywamy to tak:
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:
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:
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
customerCount
lubcountOfCustomers
jest dość oczywiste na pierwszy rzut oka.Węgierski miał jakiś cel w VB, zanim
Option Strict On
istniał, ponieważ w VB6 i wcześniejszych (i w VB .NET zOption Strict Off
) VB wymuszałoby typy, więc możesz to zrobić: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:
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ę.
źródło
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.
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:
To potworne, a jeśli zrobisz to konsekwentnie, będziesz miał
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.
źródło
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:
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.
źródło