Jakie istnieją anty-wzorce nazewnictwa? [Zamknięte]

Istnieje kilka nazw, w przypadku których sięgasz po te nazwy, wiesz, że już coś pomieszałeś.

Na przykład:

XxxManager
Jest to złe, ponieważ klasa powinna opisywać, co robi klasa. Jeśli najbardziej konkretnym słowem, jakie można wymyślić dla tego, co robi klasa, jest „zarządzać”, to klasa jest zbyt duża.

Jakie inne anty-wzorce nazewnictwa istnieją?

Aby wyjaśnić, nie pytam „jakie imiona są złe” - to pytanie jest całkowicie subiektywne i nie ma sposobu, aby na nie odpowiedzieć. Pytam: „jakie nazwy wskazują na ogólne problemy projektowe z systemem”. Oznacza to, że jeśli chcesz wywołać komponent Xyz, prawdopodobnie oznacza to, że komponent jest źle odbierany. Zauważ też, że istnieją wyjątki od każdej reguły - szukam tylko flag ostrzegawczych, kiedy naprawdę muszę się zatrzymać i przemyśleć projekt.

Następujące anty-wzorce nazewnictwa są powiązane z .NET, a zwłaszcza C #:

• Niespójności . Jeśli zdecydowałeś się zacząć każdą nazwę pola od wiodącego podkreślenia, trzymaj się tego .
• Skróty Ambiguos z brakującymi samogłoskami . Poważnie widziałem nazwy pól, takie jak cxtCtrlMngr. Trudno zgadnąć, co to ma oznaczać.
• Zbyt długie i pełne nazwy zmiennych . ILoginAttemptRepositoryjest w porządku i opisowy - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMappingjest opisowy, ale zdecydowanie nie jest w porządku.

Jednym z nich, na które często się natknęłam, jest po prostu brak jakiegokolwiek wzorca nazewnictwa. Zazwyczaj wskazuje to na ignorancję programisty (że wzorce nazewnictwa są dobrą rzeczą ), a także ten anty-wzorzec ma tendencję do rażącego naruszania SRP poprzez upychanie wszelkiego rodzaju metod związanych z klasą w samą klasę, na przykład klienta klasa ma właściwości, metody CRUD, wszystko zdalnie związane z klientem, czego potrzebuje część aplikacji.

Dodam też, że użycie „Engine” jako sufiksu jest mniej więcej tym samym, co użycie „Managera”. Jest to bardzo niejasne, a klasa o nazwie jest XxxEnginezwykle modułem w stylu VB zawierającym wiele metod, więc jest w jednym „łatwym w użyciu” miejscu, bez wiedzy ani pojęcia programowania obiektowego.

Cóż, najpierw proste odpowiedzi: wpisz węgierski ( http://mindprod.com/jgloss/unmainnaming.html , ma też inne świetne pomysły. Bardziej zrównoważony pogląd na to, kiedy węgierski nie jest zły, http://www.joelonsoftware.com /articles/Wrong.html )

Prefiks „I” w nazwie interfejsu lub „Abstract” w nazwie klasy abstrakcyjnej. Może to być usprawiedliwione w językach, które nie mają pojęcia klas abstrakcyjnych lub które nie rozróżniają interfejsów i klas abstrakcyjnych - ale na przykład w Javie jest to zawsze zły pomysł.

Nie zgadzam się również z tobą w kwestii menedżera. Czasami używam tego wzorca i oznacza to po prostu, że gdybym spróbował nazwać go czymś innym, nazwa nie byłaby bardziej opisowa niż XxxxxManager. Istnieją pewne zadania (niekoniecznie złożone), których po prostu nie można streścić w jednym lub dwóch słowach.

Mowa:

Mam chudą niepełnosprawność i nie mogę przeliterować. Bez sprawdzania pisowni jestem bezsilny. Próbuję skopiować wszystkie utworzone przeze mnie nazwy do edytora tekstu w celu weryfikacji, ale zawsze brakuje mi niektórych. Podczas mojego ostatniego projektu napisałem dużą część interfejsu API i wydaje mi się, że nie sprawdziłem pisowni za pierwszym razem, gdy użyłem słowa „odpowiedz” i założyłem, że to prawda, ponieważ nikt mi nie powiedział. Mieliśmy co najmniej 50 funkcji z odpowiedzią. W zespole pojawiła się nowa osoba i zapytała, dlaczego używamy odpowiedzi. Czułam się naprawdę głupia.

Obawiam się, że moje opinie są nieco kontrowersyjne. Ale spróbujmy ...

Jeśli o mnie chodzi, muszę zgodzić się z Mikiem Baranczakiem, nazwy takie jak XxxController, XxxHandler to coś, czego naprawdę często używamy. Dla nas Kontroler jest czymś w rodzaju punktu wejścia dla czegoś „enkapsolowanego”, np. Zarządzania transakcjami, radzenia sobie z nieoczekiwanymi błędami, dzwonienia do XxxHandler w celu wykonania rzeczywistej pracy. Powiedziałbym, że XxxManager jest synonimem kontrolera. Myślę, że ważne jest, aby nie używać Menedżera w jednym przypadku, a Kontrolera w innym. Bycie konsekwentnym jest bardzo ważne, jeśli pracujesz w zespole.

Znalezienie lepszych nazw dla takich rzeczy byłoby naprawdę trudne, a może nawet niemożliwe. Xxx powinien być dobrze wybrany, aby sytuacja była bardziej przejrzysta.

Osobiście nie lubię, gdy metoda o nazwie get ... lub set ... jest czymś więcej niż zwykłym akcesorium. Lubię det ... na determinację.

Inna rzecz, która przychodzi mi na myśl: według wuja Boba. „I” w nazwie metody jest oznaką robienia zbyt wiele. Ale życie nie zawsze jest tylko czarno-białe - są sytuacje, w których myślę, że jest w porządku - np. z powodu problemów z wydajnością (gdy masz już dane, aby sprawdzić, dlaczego ich nie przetworzyć) ...

Osobiście jestem także wielkim fanem węgierskiej notacji systemowej - przez większość czasu masz do czynienia z kodem źródłowym w IDE ok. Ale często używasz tylko edytora lub przeglądasz repozytorium w przeglądarce. Wadą może być obsługa narzędzi z powodu prefiksów typów ...

Myślę, że najważniejszą rzeczą jest być konsekwentnym - konwencja nieoptymalna - dla mnie - jest lepsza niż brak konwencji ...

Być może najgorszym anty-wzorem nazewnictwa jest ten:

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

Mamy trzyelementową listę par [foo, bar]. Jeśli potrzebujemy czwartego, będziemy musieli dodać nowe kolumny do tabeli.

Prowadzi do kodu w ten sposób:

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

Oddzielna tabela powinna zostać utworzona z kolumnami foo i bar i połączona z tabelą rzeczy:

create table fubar(foo string, bar string, stuff_id long)

Drugie najgorsze to:

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

Tutaj mamy sześć pól zamiast dwóch instancji klasy Address.

Ten anty-wzór jest oznaczony serią dwuczęściowych nazw zawierających każdą kombinację dwóch zestawów, np. [Foo, bar] x [1,2,3] lub [home, perm] x [ulica, miasto, stan]

Wszelkie nazewnictwo klas lub interfejsów, które jest tautologią, jest złe, nie tylko w Javie, o której mówi łącze, ale w dowolnym języku.

Tautologia (retoryka), używając różnych słów, aby powiedzieć to samo, nawet jeśli powtórzenie nie zapewnia jasności.

Często spotykam biblioteki oprogramowania o nazwach ogólnych, takich jak Librarylub Common. Wskazują na nieoptymalny projekt: programiści starają się unikać duplikacji kodu, ale bez żadnej próby stworzenia projektu rozłożonego na podstawie funkcjonalności.

Od Microsoft w sprawie nazewnictwa, mogę podać tę listę dla złych nazw:

1. Nie są semantyczne, co oznacza, że ​​mają nazwy, które zamiast kłaść nacisk na to, co robi, kładą nacisk na używaną technologię lub wzorzec, na którym się opiera .
2. Nie zachowują spójności syntaktycznej. Na przykład część nazw jest wielbłąda, a inna część jest pascal.
3. Są to skróty, które są trudne do zrozumienia, jak ScrollableX zamiast CanScrollHorizontally
4. Są tak dobrani, że mieszają się ze słowami kluczowymi tego środowiska.