WPF UI elementu konwencji nazewnictwa

Question

Chociaż Hungarian notation jest uważana za złą praktyką w dzisiejszych czasach, to nadal dość powszechne zakodować typ w imię elementów interfejsu użytkownika, albo za pomocą prefiksu (lblTitle, txtFirstName, ...) lub przyrostek (TitleLabel, FirstNameTextBox, ...).

W mojej firmie robimy to również, ponieważ sprawia, że ​​kod napisany przez współpracowników (lub przeze mnie dawno temu) jest łatwiejszy do odczytania (z mojego doświadczenia). Argument zwykle przemawia przeciwko temu - musisz zmienić nazwę zmiennej, jeśli typ się zmienia - nie jest zbyt mocny, ponieważ zmiana typu elementu interfejsu użytkownika zwykle wymaga przepisania wszystkich części kodu, jeśli i tak się do niego odwołuje .

Tak, myślę o zachowaniu tej praktyki, gdy zaczyna się od rozwoju WPF (hmmm ... powinniśmy użyć prefiksu txt dla TextBlocks lub TextBoxes?). Czy jest jakaś duża wada, którą przeoczyłem? To jest Twoja szansa, aby powiedzieć "Nie rób tego, ponieważ ...".

EDYTOWANIE: Wiem, że z wiązaniem danych trzeba zmniejszyć nazwy elementów interfejsu użytkownika. Niemniej czasami konieczne jest, np. przy opracowywaniu niestandardowych elementów sterujących ...

Answer 1

Osobiście uważam, że WPF zmienia zasady, jeśli chodzi o to. Często można odejść z niewielkim lub zerowym kodem, więc posiadanie przedrostków do rozróżniania nazw sprawia, że ​​rzeczy stają się bardziej zagmatwane, a nie mniej mylące.

W Windows Forms każda kontrolka była przywoływana przez nazwę w kodzie. Przy dużym interfejsie użyto notacji pół-węgierskiej - łatwiej było odróżnić to, z czym pracowałeś.

W przypadku WPF jest to rzadka kontrola, która wymaga nazwy. Kiedy musisz uzyskać dostęp do kontroli za pomocą kodu, często najlepiej jest użyć dołączonych właściwości lub zachowań, aby to zrobić, w takim przypadku nigdy nie masz do czynienia z więcej niż jedną kontrolą. Jeśli pracujesz w kontrolerze UserControl lub Window, po prostu używałbym "Title" i "Name" zamiast "txtTitle", zwłaszcza że teraz będziesz miał do czynienia tylko z kilkoma, ograniczonymi kontrolami, zamiast tego z nich wszystkich.

Nawet niestandardowe elementy sterujące nie powinny w większości przypadków wymagać nazw.Będziesz chciał szablonować nazwy zgodnie z konwencją (np. PART_Name), ale nie faktyczne x: Elementy nazw dla twoich interfejsów użytkownika ...

Answer 2

Lubię używać konwencji (ogólnie rzecz biorąc jest to dobry pomysł), ale w przypadku interfejsu użytkownika podoba mi się to, aby mieć typ kontrolki z przodu, a następnie opisową nazwę - LabelSummary, TextSummary, CheckboxIsValid, itp.

Brzmi to mało, ale głównym powodem wprowadzenia tego typu jest to, że pojawią się razem na liście Intellisense - wszystkie etykiety razem, pola wyboru i tak dalej.

Answer 3

Z mojego doświadczenia - W WPF, gdy zmieniasz typ kontrolki, zwykle nie musisz przepisywać żadnego kodu, chyba że zrobiłeś coś nie tak. W rzeczywistości przez większość czasu nie odwołujesz się do kontrolek w kodzie. Tak, w końcu to robisz, ale większość odniesień do elementu UI w WPF jest przez inne elementy w tym samym XAML.

Osobiście uważam, że "lblTitle, lblCompany, txtFirstName" jest trudniejsze do odczytania niż "Tytuł". Nie mam .intWidth i .intHeight (do widzenia lpzstrName!). Dlaczego .lblFirstName? Mogę zrozumieć TitleField lub TitleInput lub cokolwiek o wiele więcej, ponieważ opisują one co, a nie w jaki sposób.

Dla mnie, chcąc mieć ten rodzaj separacji, zwykle oznacza to, że mój kod UI próbuje za dużo zrobić - oczywiście ma do czynienia z elementem interfejsu użytkownika, jest w kodzie okna! Jeśli nie mam do czynienia z kodem wokół elementu interfejsu użytkownika, dlaczego na świecie miałbym go tutaj kodować?

Answer 4

W WPF praktycznie nigdy nie potrzebujesz (lub nawet chcesz) wymieniać kontrolek. Jeśli więc korzystasz ze sprawdzonych metod WPF, nie będzie miało znaczenia, jakie jest twoje imię i nazwisko, , jeśli masz jakiś powód, by je nazwać.

W tych rzadkich sytuacjach, w których faktycznie chcesz nadać nazwę (np. Dla elementu Nazwa elementu = lub Nazwa docelowa = odwołanie), wolę wybrać nazwę opisującą na podstawie celu nazwy, na przykład:

<Border x:Name="hilightArea" ...> 
    ... 

<DataTrigger> 
    ... 
    <Setter TargetName="hilightArea" ... 

Answer 5

Nawet z perspektywy Winforma nie lubię pół węgierskich.

Największą wadą, według mnie, i napisałem DUŻO kodu ui jest to, że węgierski sprawia, że ​​błędy są trudniejsze do wykrycia. Kompilator będzie zazwyczaj go podnieść, jeśli starają się zmienić sprawdzone nieruchomości na pole tekstowe, ale nie będzie podnieść coś takiego:

lblSomeThing.Visible = someControlsVisible; 
txtWhatThing.Visible = someControlsVisible; 
pbSomeThing.Visible = someControlsVisible; 

I dużo łatwiej do debugowania:

someThingLabel.Visible = someControlsVisible; 
whatThingTextBox.Visible = someControlsVisible; 
someThingPictureBox.Visible = someControlsVisible; 

Wydaje mi się również, że lepiej jest pogrupować element addCommentsButton z elementem addCommentsTextBox, niż grupować polecenie btnAddComments za pomocą pliku btnCloseWindow. Kiedy zamierzasz użyć dwóch ostatnich razem?

Jeśli chodzi o znalezienie odpowiedniej kontroli, zgadzam się z Philipem Rieck. Często chcę zajmować się wszystkimi kontrolami, które odnoszą się do konkretnej koncepcji logicznej (np. Tytuł lub dodawanie komentarzy). Nie chcę nigdy znaleźć żadnego lub wszystkich pól tekstowych, które znajdują się pod kontrolą.

Jest to prawdopodobnie nieistotne w WPF, ale uważam, że węgierski powinien być unikany przez cały czas.

Answer 6

Zgadzam się z innymi odpowiedziami, że to głównie osobiste preferencje, a najważniejsze jest po prostu być konsekwentnym.

Jeśli chodzi o potrzebę nazewnictwa, biorąc pod uwagę rozpowszechnienie powiązania danych ... jedną z rzeczy, które warto rozważyć, jest to, czy Twój interfejs użytkownika jest kiedykolwiek poddawany testom automatycznym. Coś takiego jak QTP znajduje elementy wizualne w aplikacji według nazwy, a zatem inżynier automatyzacji piszący skrypty testowe bardzo doceni, gdy rzeczy takie jak zakładki, przyciski itp. (Jakikolwiek interaktywny kontroler) będą dobrze nazwane.

Answer 7

Przedrostek każdej nazwy interfejsu użytkownika z dwoma podkreśleniami, jak w __, więc jest sortowany przed innymi właściwościami podczas debugowania. Kiedy potrzebuję użyć IntelliSense do znalezienia kontroli, po prostu wpisuję __ i wyświetlam listę kontrolek. Kontynuuje to konwencję nazewnictwa przedrostka pojedynczego podkreślenia na zmienne poziomu modułu, tak jak w przypadku int _id;.

Answer 8

Możesz użyć oficjalnej strony Microsoftu dla konwencji nazewnictwa kontroli Visual Basic 6 i być może połączyć je z zalecanymi konwencjami nazewnictwa C#. Jest bardzo specyficzny, jest szeroko stosowany przez programistów w języku C#, jak również w przypadku nazw kontrolek i nadal może być używany w kontekście WPF lub Windows Forms.

Visual Basic 6 kontroli konwencje nazewnictwa: Object Naming Conventions

C# polecane konwencje nazewnictwa w ogóle: General Naming Conventions