Czy ktoś jeszcze uważa klasy i metody nazewnictwa za jedną z najtrudniejszych części w programowaniu? [Zamknięte]

Pracuję więc nad tą klasą, która ma żądać dokumentacji pomocy od dostawcy za pośrednictwem usługi internetowej. Staram się go nazwać DocumentRetriever, VendorDocRequester, DocGetter, ale po prostu nie brzmi dobrze. Skończyło się przeglądając dictionary.com przez pół godziny próbując wymyślić odpowiedniego słowa.

Rozpoczęcie programowania przy złych nazwach jest jak bardzo zły dzień z rana, a reszta dnia zaczyna się stokiem. Poczuj mnie?

To, co teraz robisz, jest w porządku i gorąco polecam trzymanie się obecnej składni, ponieważ:

kontekst + czasownik + jak

Używam tej metody do nazywania funkcji / metod, przechowywanych procedur SQL itp. Zachowując tę ​​składnię, utrzymasz twoje Intellisense / Code Panes o wiele bardziej czyste. Więc chcesz EmployeeGetByID () EmployeeAdd (), EmployeeDeleteByID (). Kiedy użyjesz bardziej poprawnej gramatycznie składni, takiej jak GetEmployee (), AddEmployee (), zobaczysz, że staje się to naprawdę bałagan, jeśli masz wiele Gets w tej samej klasie, ponieważ niezwiązane ze sobą rzeczy zostaną zgrupowane razem.

Przypominam to nadawaniu nazw plikom z datami, chcesz powiedzieć 2009-01-07.log, a nie 1-7-2009.log, ponieważ po ich zgrupowaniu zamówienie staje się całkowicie bezużyteczne.

Nauczyłem się jednej lekcji, że jeśli nie możesz znaleźć nazwy klasy, prawie zawsze coś jest z nią nie tak:

• nie potrzebujesz tego
• robi za dużo

Dobra konwencja nazewnictwa powinna minimalizować liczbę możliwych nazw, których możesz użyć dla dowolnej zmiennej, klasy, metody lub funkcji. Jeśli istnieje tylko jedna możliwa nazwa, nigdy nie będziesz mieć problemów z jej zapamiętaniem.

W przypadku funkcji i klas singletonowych analizuję funkcję, aby sprawdzić, czy jej podstawową funkcją jest transformacja jednego rodzaju rzeczy w inny rodzaj rzeczy. Używam tego terminu bardzo swobodnie, ale odkryjesz, że OGROMNA liczba funkcji, które piszesz, zasadniczo przyjmuje coś w jednej formie i tworzy coś w innej formie.

W twoim przypadku wygląda na to, że twoja klasa przekształca adres URL w dokument. To trochę dziwne myśleć o tym w ten sposób, ale całkowicie poprawne, a kiedy zaczniesz szukać tego wzoru, zobaczysz go wszędzie.

Kiedy znajduję ten wzorzec, zawsze nazywam funkcję x Fromy .

Ponieważ twoja funkcja przekształca adres URL w dokument, nazwałbym go

DocumentFromUrl

Ten wzór jest niezwykle powszechny. Na przykład:

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

Możesz także użyć, UrlToDocumentjeśli czujesz się bardziej komfortowo z tym zamówieniem. Czy powiesz xFrom y czy y Tox, jest prawdopodobnie kwestią gustu, ale wolę Fromkolejność, ponieważ w ten sposób początek nazwy funkcji mówi ci, jaki typ zwraca.

Wybierz jedną konwencję i trzymaj się jej. Jeśli starasz się używać tych samych nazw, co nazwy klas w xFrom funkcjach y , o wiele łatwiej będzie zapamiętać, jakich nazw używałeś. Oczywiście ten wzorzec nie działa na wszystko, ale działa tam, gdzie piszesz kod, który można uznać za „funkcjonalny”.

Czasami nie ma dobrego imienia dla klasy lub metody, zdarza się to nam wszystkim. Często jednak niemożność wymyślenia nazwy może wskazywać na coś złego w twoim projekcie. Czy twoja metoda ma zbyt wiele obowiązków? Czy twoja klasa zawiera spójny pomysł?

Wątek 1:

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

Wątek 2:

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

Nigdzie tutaj nie ma Thread.sleep (...).

Sporo czasu spędzam też martwiąc się nazwami czegokolwiek, co można nazwać podczas programowania. Powiedziałbym, że to się bardzo opłaca. Czasami, kiedy utknęłam, zostawiam to na chwilę, a podczas przerwy na kawę pytam trochę, czy ktoś ma dobrą sugestię.

Dla twojej klasy sugerowałbym VendorHelpDocRequester.

Książka Code Complete autorstwa Steve Mcconnell zawiera ładny rozdział nazywania zmiennych / klas / funkcji / ...

Myślę, że to efekt uboczny.

To nie jest prawdziwe nazewnictwo, które jest trudne. Trudne jest to, że proces nazywania sprawia, że ​​stajesz wobec okropnego faktu, że nie masz pojęcia, co do cholery robisz.

Właśnie wczoraj usłyszałem ten cytat za pośrednictwem Signal vs. Noise bloga na 37Signals iz pewnością się z nim zgadzam:

„W informatyce są tylko dwie trudne rzeczy: unieważnienie pamięci podręcznej i nadawanie nazw”. - Phil Karlton

Dobrze, że to trudne. Zmusza cię do zastanowienia się nad problemem i tym, co klasa powinna właściwie zrobić. Dobre nazwy mogą prowadzić do dobrego projektu.

Zgoda. Lubię, aby moje nazwy i zmienne typów były jak najbardziej opisowe, ale nie były zbyt strasznie długie, ale czasami istnieje tylko pewna koncepcja, dla której nie można znaleźć dobrego słowa.

W takim przypadku zawsze pomaga mi poprosić współpracownika o dane wejściowe - nawet jeśli ostatecznie nie pomagają, zwykle pomaga mi przynajmniej wyjaśnić to na głos i spowodować, że moje koła się obracają.

Właśnie pisałem o konwencjach nazewnictwa w zeszłym miesiącu: http://caseysoftware.com/blog/useful-naming-conventions

Istota tego:

verbAdjectiveNounStructure - ze strukturą i przymiotnikiem jako częściami opcjonalnymi

W przypadku czasowników trzymam się czasowników czynności: zapisuj, usuwaj, powiadamiaj, aktualizuj lub generuj. Od czasu do czasu używam „procesu”, ale tylko w celu odniesienia się do kolejek lub zaległości roboczych.

W przypadku rzeczowników korzystam z interakcji klasy lub obiektu. W web2project jest to często Zadania lub Projekty. Jeśli JavaScript obsługuje interakcję ze stroną, może to być treść lub tabela. Chodzi o to, że kod wyraźnie opisuje obiekt, z którym wchodzi w interakcje.

Struktura jest opcjonalny, ponieważ jest unikatowy dla danej sytuacji. Ekran listy może poprosić o listę lub tablicę. Jedną z podstawowych funkcji używanych na liście projektów dla web2project jest po prostu getProjectList. Nie modyfikuje podstawowych danych, tylko reprezentację danych.

The przymiotniki to coś zupełnie innego. Są używane jako modyfikatory rzeczownika. Coś tak prostego, jak getOpenProjects, można łatwo wdrożyć za pomocą getProjects i parametru przełącznika, ale zwykle generuje to metody, które wymagają sporego zrozumienia podstawowych danych i / lub struktury obiektu ... niekoniecznie coś, co chcesz zachęcać. Mając bardziej wyraźne i specyficzne funkcje, możesz całkowicie owinąć i ukryć implementację przed kodem, używając go. Czy to nie jeden z punktów OO?

Bardziej niż nazywanie klasy, tworzenie odpowiedniej struktury pakietu może być trudnym, ale satysfakcjonującym wyzwaniem. Musisz rozważyć oddzielenie obaw modułów i ich związku z wizją aplikacji.

Zastanów się teraz nad układem swojej aplikacji:

• App
  • VendorDocRequester (odczyt z serwisu internetowego i podanie danych)
  • VendorDocViewer (użyj requestera, aby dostarczyć dokumenty dostawcy)

Zaryzykowałbym przypuszczenie, że w kilku klasach wiele się dzieje. Jeśli przełożysz to na podejście bardziej oparte na MVC i pozwolisz małym klasom poradzić sobie z indywidualnymi obowiązkami, możesz skończyć z czymś takim:

• App
  • VendorDocs
    • Model
      • Dokument (zwykły obiekt przechowujący dane)
      • WebServiceConsumer (radzić sobie z nitty gritty w serwisie internetowym)
    • Kontroler
      • DatabaseAdapter (obsłużyć obsługę przy użyciu ORM lub innej metody)
      • WebServiceAdapter (wykorzystaj Konsumenta, aby pobrać dokument i umieścić go w bazie danych)
    • Widok
      • HelpViewer (użyj DBAdapter, aby wypluć dokumentację)

Następnie nazwy klas polegają na przestrzeni nazw, aby zapewnić pełny kontekst. Same klasy mogą być nieodłącznie związane z aplikacją, bez potrzeby jawnego mówienia o tym. W rezultacie nazwy klas są prostsze i łatwiejsze do zdefiniowania!

Jeszcze jedna bardzo ważna sugestia: zrób sobie przysługę i podnieś kopię Wzorów Głównego Projektu. To fantastyczna, łatwa w czytaniu książka, która pomoże ci uporządkować aplikację i napisać lepszy kod. Docenianie wzorców projektowych pomoże ci zrozumieć, że wiele napotkanych problemów zostało już rozwiązanych, a będziesz w stanie wprowadzić rozwiązania do swojego kodu.

Leo Brodie w swojej książce „Thinking Forth” napisał, że najtrudniejszym zadaniem dla programisty było dobre nazywanie rzeczy i stwierdził, że najważniejszym narzędziem programistycznym jest tezaurus.

Spróbuj użyć tezaurusa na stronie http://thesaurus.reference.com/ .

Poza tym nie używaj NIGDY notacji węgierskiej, unikaj skrótów i zachowaj spójność.

Wszystkiego najlepszego.

Krótko mówiąc:
zgadzam się, że dobre nazwiska są ważne, ale nie sądzę, że trzeba je znaleźć przed wdrożeniem za wszelką cenę.

Oczywiście lepiej mieć dobre imię od samego początku. Ale jeśli nie możesz wymyślić jednego w ciągu 2 minut, zmiana nazwy później będzie kosztować mniej czasu i jest właściwym wyborem z punktu widzenia produktywności.

Długi:
Generalnie często nie warto zbyt długo zastanawiać się nad nazwą przed wdrożeniem. Jeśli zaimplementujesz swoją klasę, nadając jej nazwę „Foo” lub „Dsnfdkgx”, podczas implementacji zobaczysz, co powinieneś nazwać.

Zwłaszcza w przypadku Java + Eclipse zmiana nazwy rzeczy nie jest wcale trudna, ponieważ dokładnie obsługuje wszystkie odwołania we wszystkich klasach, ostrzega przed kolizjami nazw itp. I dopóki klasa nie znajduje się jeszcze w repozytorium kontroli wersji, nie „ sądzę, że jest coś złego w zmianie nazwy 5 razy.

Zasadniczo chodzi o to, jak myślisz o refaktoryzacji. Osobiście podoba mi się, chociaż czasami denerwuje moich kolegów z zespołu, ponieważ wierzą, że nigdy nie dotykają działającego systemu . A ze wszystkiego, co możesz refaktoryzować, zmiana nazw jest jedną z najbardziej nieszkodliwych rzeczy, jakie możesz zrobić.

Dlaczego nie HelpDocumentServiceClient w rodzaju kęsa lub HelpDocumentClient ... nie ma znaczenia, że ​​to sprzedawca, chodzi o to, że jest klientem usługi internetowej, która zajmuje się dokumentami pomocy.

I tak, nazywanie jest trudne.

Jest tylko jedna rozsądna nazwa dla tej klasy:

HelpRequest

Nie pozwól, aby szczegóły implementacji odwróciły uwagę od znaczenia.

Zainwestuj w dobre narzędzie do refaktoryzacji!

Trzymam się podstaw: VerbNoun (argumenty). Przykłady: GetDoc (docID).

Nie musisz się fantazjować. Za rok będzie łatwo zrozumieć, czy to ty, czy ktoś inny.

Dla mnie nie obchodzi mnie, jak długo nazwa metody lub klasy jest tak długa, jak jej opisowa i poprawna biblioteka. Dawno minęły czasy, w których należy pamiętać, gdzie znajduje się każda część interfejsu API.

Intelisense istnieje dla wszystkich głównych języków. Dlatego podczas korzystania z interfejsu API innej firmy lubię używać jego inteligencji do dokumentacji, a nie używać „rzeczywistej” dokumentacji.

Mając to na uwadze, mogę stworzyć nazwę metody, taką jak

StevesPostOnMethodNamesBeingLongOrShort

Długi - ale co z tego. Kto obecnie nie używa ekranów 24-calowych!

Muszę się zgodzić, że nazywanie to sztuka. To staje się trochę łatwiejsze, jeśli twoja klasa postępuje zgodnie z pewnym „wzorcem desigh” (fabryka itp.).

Jest to jeden z powodów posiadania standardu kodowania. Posiadanie standardu pomaga wymyślać nazwiska, gdy jest to wymagane. Pomaga uwolnić umysł od innych ciekawych rzeczy! (-:

Poleciłbym przeczytać odpowiedni rozdział Kodeksu Steve'a McConnella ( link Amazon ), który zawiera kilka zasad ułatwiających czytelność, a nawet łatwość konserwacji.

HTH

Twoje zdrowie,

Obrabować

Nie, debugowanie jest dla mnie najtrudniejszą rzeczą! :-)

Moduł pobierania dokumentów? Trudno powiedzieć bez kontekstu.

Może pomóc zachowywać się jak matematyk i pożyczać / wymyślać leksykon dla swojej domeny w drodze: zadowalaj się krótkimi, prostymi słowami, które sugerują tę koncepcję, bez wypowiadania jej za każdym razem. Zbyt często widzę frazy długo latinate który się zamienił akronimów, co trzeba słownika dla akronimów i tak .

Językiem używanym do opisania problemu jest język, którego należy używać dla zmiennych, metod, obiektów, klas itp. Luźno rzeczowniki pasują do obiektów, a metody do czasowników. Jeśli brakuje słów do opisania problemu, brakuje również pełnego zrozumienia (specyfikacji) problemu.

Jeśli po prostu wybiera między zestawem nazw, powinien być oparty na konwencjach używanych do budowy systemu. Jeśli znalazłeś się w nowym miejscu, odkrytym przez poprzednie konwencje, zawsze warto poświęcić trochę wysiłku, aby spróbować je rozszerzyć (odpowiednio, konsekwentnie), aby objąć tę nową sprawę.

W razie wątpliwości śpij na nim i wybierz pierwsze najbardziej oczywiste imię następnego dnia rano :-)

Jeśli obudzisz się pewnego dnia i zdasz sobie sprawę, że się mylisz, zmień to natychmiast.

Paweł.

BTW: Document.fetch () jest dość oczywiste.

Uważam, że mam najwięcej problemów ze zmiennymi lokalnymi. Na przykład chcę utworzyć obiekt typu DocGetter. Więc wiem, że to DocGetter. Dlaczego muszę nadać mu inną nazwę? Zwykle nadaję mu nazwę dg (dla DocGetter) lub temp lub coś równie nieopisowego.

Nie zapominaj, że wzorce projektowe (nie tylko GoF) to dobry sposób na zapewnienie wspólnego słownictwa, a ich nazwy powinny być używane zawsze, gdy pasuje do sytuacji. Pomoże to nawet początkującym, którzy znają się na nomenklaturze, w szybkim zrozumieniu architektury. Czy ta klasa, nad którą pracujesz, powinna działać jak pełnomocnik, czy nawet fasada?

Czy dokumentacja dostawcy nie powinna być przedmiotem? Mam na myśli, że ten jest namacalny, a nie tylko jako antropomorfizacja części twojego programu. Więc możesz miećVendorDocumentation klasę z konstruktorem, który pobiera informacje. Myślę, że jeśli nazwa klasy zawiera czasownik, często coś poszło nie tak.

Zdecydowanie cię czuję. I czuję twój ból. Każde imię, o którym myślę, wydaje mi się śmieciem. Wszystko wydaje się takie ogólne i chcę w końcu nauczyć się, jak wprowadzić odrobinę talentu i kreatywności w moje nazwiska, dzięki czemu naprawdę odzwierciedlają to, co opisują.

Jedną z moich sugestii jest skonsultowanie się z tezaurusem. Słowo ma dobre, podobnie jak Mac OS X. To naprawdę może mi pomóc wydostać głowę z chmur i dać mi dobre miejsce startu, a także trochę inspiracji.

Jeśli nazwa wyjaśniłaby się laikowi, to prawdopodobnie nie trzeba jej zmieniać.