Walcząc o nieużywanie notacji węgierskiej

10

Widziałem argumenty za i przeciw systemowi węgierskiemu . Od kilku lat pracuję nad starszym projektem, który korzysta z tego systemu, nazywając każdą zmienną, funkcję prefiksem typu zmiennej np. (StrName, intAge, btnSubmit itp.) (Znam oryginalne prefiksy węgierskiej aplikacji według rodzaju zmienna, a nie typ). Chciałbym, aby mój następny projekt całkowicie go porzucił, ale trudniej mi nazwać podobne rzeczy w sposób jednoznaczny, bez uciekania się do nich.

Powiedzmy, że mam formularz internetowy do zbierania adresów e-mail i przechowywania ich w tabeli bazy danych oraz przycisk, który wywołuje funkcję zapisywania adresu do bazy danych.

Jeśli używam notacji w stylu węgierskim, mogę nazwać pole txtEmailprzyciskiem btnEmaili wartością zawartą w polu tekstowym strEmail. Mogę wtedy użyć funkcji storeEmail(strEmail)do przechowywania wiadomości e-mail. Mam tutaj jasną konwencję, jasne jest, czym jest każda zmienna.

Jaka byłaby najlepsza praktyka nazywania tych zmiennych

bez uciekania się do systemów węgierskich,
bez powodowania ich zbyt długich lub mylących
i z jasną konwencją do wykorzystania w całym moim projekcie?

naming hungarian

— strach
źródło

2

Być może coś jest nie tak z resztą konwencji nazewnictwa lub rozmiarem funkcji, jeśli masz problemy ze znalezieniem unikalnych nazw.

Jakiej technologii używasz? Te prefiksy wydają się nadawać do formularzy internetowych.

— StuperUser

Używam ASP.NET (z C # z tyłu)

— Strachoffours

@ delnan - czy możesz to wyjaśnić? Dlaczego rozmiar funkcji sprawia, że nadawanie nazw jest wyjątkowo łatwiejsze?

— terroroffours

@fearofours: Mniejsza funkcja potrzebuje mniej zmiennych, a mniej zmiennych oznacza oczywiście mniej zderzeń zmiennych. Zakłada się oczywiście, że umieścisz każdą zmienną w możliwie najmniejszym zakresie.

8

Twój ostatni punkt jest najważniejszy - cokolwiek potrzebujesz, aby zachować spójność w całym projekcie i ze współpracownikami. Istnieją dwa główne sposoby osiągnięcia spójności i jeśli to możliwe, powinieneś użyć obu. Najpierw użyj narzędzia do sprawdzenia konwencji nazewnictwa podczas kompilacji. W świecie .Net StyleCop byłby dobrym przykładem takiego narzędzia. Drugim sposobem na uzyskanie spójności jest przeglądanie całego kodu, aby wszyscy mogli się rozejrzeć.

Twoje pozostałe dwa punkty wydają się pytać o alternatywę. Nie jestem pewien, czy potrzebujesz alternatywy; chodzi o to, że język węgierski nie jest już popularny, ponieważ był używany do opisywania typu, gdy system typów i narzędzia były nieco, powiedzmy, mniej surowe. To znaczy, jeśli programowałeś w C i przekazywałeś wskaźniki, jedynym sposobem na śledzenie tego typu był węgierski. Teraz, jeśli używasz języka takiego jak C # lub Java, nie będziesz używać wskaźników (lub bardzo rzadko), więc potrzeba jakiegokolwiek węgierskiego zniknie. Ponadto nowoczesne środowiska IDE pozwalają bardzo łatwo zobaczyć typ, najeżdżając kursorem na zmienną lub, w najgorszym wypadku, używając skrótu, aby zobaczyć oryginalną deklarację. Więc nie sądzę, że potrzebujesz jakiejkolwiek notacji, po prostu nazwij zmienną tym, co robi. Jeśli jest to adres e-mail, użyj „e-mail” lub „

— Steve
źródło

2

Robi się trochę trudniejsze, gdy / strona / okno forma / cokolwiek posiada przycisk do e-mail, pole tekstowe do e-mail, a może inny widżet / kontroli na email ...

— FrustratedWithFormsDesigner

7

@FrustratedWithFormsDesigner Niekoniecznie. Pole tekstowe może być emailAddressInput, gdzie jako przycisk może być emailAddressSubmit, a wewnętrzna reprezentacja to po prostu emailAddress.

— Jonathan

@Jathanathan: Dobra uwaga.

— FrustratedWithFormsDesigner

3

W przypadku formularzy internetowych / formularzy Windows / innych elementów graficznych warto używać Systems Hungarian, ponieważ można mieć bardzo ściśle powiązane elementy sterujące - na przykład pole tekstowe i etykietę, które pasują do siebie; możesz nazwać je txtEmaili lblEmailrozróżnić. Z mojego doświadczenia wynika, że jest to powszechne i faktycznie przydatne.

Ale w twoim kodzie takie nazewnictwo jest niepotrzebne. Jeśli masz zmienną typu, stringktóra jest używana do przechowywania wiadomości e-mail, po prostu ją nazwij email. Jeśli z jakiegoś powodu się zdezorientujesz, większość IDE powinna pozwolić na najechanie na nią myszką i zobaczenie jej typu. (Idealnie, w przypadku OO, może to być atrybut jakiegoś obiektu i user.Emailjest jeszcze bardziej wyraźny.)

Wydaje mi się, że jeśli w kodzie zadeklarowano więcej niż jeden obiekt, który nie jest formantem GUI, który można poprawnie nazwać email, coś jest z natury nie tak z twoim projektem.

— Andrew Arnold
źródło

1

W rzeczywistości txt i lbl nie są węgierskie, txt jest po prostu krótkie dla Text, a lbl jest skrótem dla Label, nie ma powodu, aby nie używać tylko pełnej długości słowa, np. EmailText i EmailLabel w formularzu. Węgierski byłby typem, który w obu przypadkach jest ciągiem.

— Steve

1

@ Steve Haigh - Nie, mówię o samych elementach sterujących. Masz obiekt typu „textbox” o nazwie txtEmail i obiekt typu „label” o nazwie lblEmail. Żaden z nich nie jest łańcuchem. Mogą mieć właściwości łańcuchowe, ale same nie są łańcuchami.

— Andrew Arnold

1

O przepraszam. Tak oczywiście. Mimo to nie ma powodu, aby nie używać bardziej opisowej nazwy, takiej jak EmailTextBox. To, że VS generuje złe imię, nie oznacza, że musisz je zachować. Jednak w kontekście formularzy skróty txt i lbl są tak dobrze zrozumiałe, że prawdopodobnie nie martwiłbym się w tym przypadku.

— Steve,

3

Co sprawia, że zmienna jest „długa”?

Zamiast txtEmail , btnEmailmożna użyć UserEmailText, UserEmailButtonoraz AdminEmailText,AdminEmailButton

Problem polega na tym, że możesz zacząć odczuwać, że zmienna zaczyna być długa:

AdminEmailIsValid zaczyna graniczyć, jak długo pozwolę, by zmienna była.

Ponadto możesz zacząć zauważać, że ponownie używasz zestawu zmiennych i zestawu operacji na tych zmiennych. Do tego jest przeznaczony OOP . Zamiast zestawu zmiennych utwórz obiekt ogólny:

class EmailForm
  var textBox, button, text
  function storeEmail()

Następnie możesz utworzyć nową zmienną jako klasę i użyć tej samej notacji kropkowej, aby uzyskać dostęp do swoich danych:

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

Oczywiście jest to ukierunkowane na języki, które wykorzystują paradygmat OOP, ale większość popularnych języków programowania WWW jest obiektowa lub pozwala na kod obiektowy (PHP, Python, C #, C ++, Java, JavaScript, ActionScript itp. ).

— zzzzBov
źródło

Nie widzę przewagi UserEmailText w stosunku do txtEmail - po prostu dodajesz typ, a nie prefiks. Lubię jednak „Do tego właśnie służy OOP”.

— terroroffours

@fearoffours, OP przyznał, że ma problem z unikalnymi nazwami, dodałem ten przykład jako opisowy sposób rozróżnienia dwóch podobnych zmiennych ( UserEmailTexta AdminEmailTextkonkretnie). Zazwyczaj używam typów przyrostków, ponieważ można przejść do klasy UserEmailText-> UserEmail.text-> w User.email.textzależności od tego, ile abstrakcji / funkcjonalności jest konieczne.

— zzzzBov 04

OK, zobacz, skąd pochodzisz. +1 za porównanie sufiksu / klasy. Aha, i jestem OP!

— terroroffours

@fearoffours, lol whoops ...

— zzzzBov,