Czy poprzedzasz nazwy zmiennych skrótem typów zmiennych? (Notacja węgierska) [zamknięte]

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 boollub floatnie istnieje).

Co myślisz o notacji węgierskiej? Czy używasz tego? Czemu?

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, ale pxWidthlub emWidth(odpowiednio dla „szerokość w pikselach” lub „szerokość w ems”). Nie, strNameale sNamelub usName(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 * emHeightoczywiste).

Zobacz także artykuł Joela „ Sprawianie, że zły kod wygląda źle ”.

zaimek Czasownik powinien przysłówek Czasownik nigdy Używać przymiotnika Rzeczownik węgierski Notacja, przyimek Czasownik Sprawia, że ​​zbieramy rzeczownik Wszystko przysłówek

Po pierwsze:

Wiesz, to firma inżynierska, więc style kodowania nie mają tak naprawdę znaczenia, dopóki algorytmy są prawidłowe.

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.

Nie używaj tego. Jest redundantny i utrudnia odczytanie kodu.

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, s16ADCValuemoż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.

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 #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

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:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

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 :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

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ś:

Co więcej, większość naszego kodu musi działać na niektórych dziwnych procesorach DSP, w których i tak nie ma koncepcji typu bool lub float

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 :-)

Nie ma to sensu w języku zorientowanym obiektowo - wszystko jest typem, który jest widoczny, gdy próbuje się go użyć.

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.

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 :

• Unikaj zbyt ogólnych nazw. Nie nazywaj go, zgdy jest to zmienna klasowa reprezentująca nazwany obiekt, powiedzmy rachunek telefoniczny. Nazwij to phoneBilllub PhoneBill.

• 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ń Poslub nawet ijeś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 rwTabPositioni względem dokumentu rdTabPosition. 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:

vrbDo advnot vrbuse nou Węgierski rzeczownik cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrb powinien zalecać czasownik nouusing "rzeczownik" prpfor proour imiona zmienne.

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

Zachowaj nazwy zmiennych tak krótkie, jak to możliwe, tak istotne, jak to konieczne i zawsze jednoznaczne .

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. isConnectedjest zawsze bardziej czytelny i łatwy do zrozumienia niż boolConnected.

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:

1. ctrl-home
2. Ctrl-F
3. nazwa zmiennej
4. wchodzić

To miało znaczenie. Ale gdzieś około 2000 roku wydarzyło się kilka rzeczy:

• redaktorzy stali się wystarczająco inteligentni, aby wyświetlić typ zmiennej jako etykietkę narzędzia
• redaktorzy mieli skrót „przejdź do deklaracji” i szybki sposób na przeglądanie wstecz
• C ++ był używany rzadziej, a większość innych języków ma mniej typów zmiennych. Na przykład w języku C # masz pewność, że lastNamejest System.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.

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:

void f(int a, char b);
int a = b + 4 / (3 + 4);

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:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

Zgadzam się z większością, to stary styl.

W przypadku nowoczesnych IDE szybkie najechanie kursorem na zmienną pokazuje typ.