Czy ktoś jeszcze uważa nazywanie klas i metod za jedną z najtrudniejszych części w programowaniu? [zamknięte]

Dobra konwencja nazewnictwa powinna zminimalizować liczbę możliwych nazw, których możesz użyć dla danej zmiennej, klasy, metody lub funkcji. Jeśli jest tylko jedno możliwe imię, nigdy nie będziesz miał problemów z zapamiętaniem go.

Dla funkcji i klas Singletona analizuję funkcję, aby sprawdzić, czy jej podstawową funkcją jest przekształcenie jednego rodzaju rzeczy w inny rodzaj rzeczy. Używam tego terminu bardzo luźno, ale odkryjesz, że ogromna liczba funkcji, które pisać zasadniczo wziąć coś w jednej formie i produkować coś w innej formie.

W Twoim przypadku brzmi to tak, jakby twoja klasa przekształciła adres Url w Dokument. To trochę dziwne myśleć o tym w ten sposób, ale doskonale poprawne, a kiedy zaczniesz szukać tego wzoru, zobaczysz go wszędzie.

Kiedy znajduję ten wzór, zawsze wymieniam funkcję xFromy .

Ponieważ twoja funkcja przekształca Url w Dokument, I would name it

DocumentFromUrl

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

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

Jedna lekcja, której się nauczyłem, to to, że jeśli nie możesz znaleźć nazwy dla klasy, prawie zawsze coś jest nie tak z tą klasą:

• you don ' t need it
• to robi za dużo

Czasami nie ma dobrej nazwy dla klasy lub metody, zdarza się to nam wszystkim. Często jednak niemożność wymyślenia nazwy może być wskazówką 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
      }
}

Nie ma wątku.sen(...) gdziekolwiek.

Spędzam również dużo czasu martwiąc się o nazwy czegokolwiek, co może mieć nazwę, gdy programuję. Powiedziałbym, że to bardzo dobrze się opłaca. Czasami, gdy utknąłem, zostawiam go na chwilę i podczas przerwy kawowej trochę pytam, czy ktoś ma dobrą propozycję.

Na Twoją klasę proponuję VendorHelpDocRequester.

The book Code Complete by Steve Mcconnell ma ładny rozdział na temat nazewnictwa zmiennych / klas / funkcji/...

Myślę, że to efekt uboczny.

To nie prawdziwe nazewnictwo jest trudne. Trudne jest to, że proces nazywania sprawia, że stajesz twarzą w twarz z okropnym faktem, że nie masz pojęcia, co do cholery robisz.

Właśnie wczoraj usłyszałam ten cytat, na blogu Signal vs. Noise na 37signals i na pewno się z tym Zgadzam:

" w informatyce są tylko dwie trudne rzeczy: unieważnianie pamięci podręcznej i nazywanie rzeczy." - Phil Karlton

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

Zgoda. Lubię, aby moje nazwy typów i zmienne były tak opisowe, jak to tylko możliwe, bez zbyt horrendalnie długie, ale czasami jest po prostu pewna koncepcja, na którą nie można znaleźć dobrego słowa.

W takim przypadku zawsze pomaga mi poprosić współpracownika o wkład - nawet jeśli ostatecznie nie pomogą, zazwyczaj pomaga mi to przynajmniej wyjaśnić na głos i sprawić, że moje koła się obracają.

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

Sedno sprawy:

VerbAdjectiveNounStructure - ze strukturą i przymiotnikiem jako części opcjonalne

Dla czasowników , trzymam się czasowników akcji: Zapisz, Usuń, powiadom, zaktualizuj lub Wygeneruj. Raz na jakiś czas, używam "proces", ale tylko konkretnie odnoszą się do kolejek lub zaległości pracy.

Dla rzeczowników , używam klasy lub obiekt wchodzący w interakcję. W web2project często są to zadania lub projekty. Jeśli jest to Javascript wchodzący w interakcję ze stroną, może to być body lub table. Chodzi o to, że kod wyraźnie opisuje obiekt, z którym wchodzi w interakcję.

Struktura jest opcjonalna, ponieważ jest unikalna dla danej sytuacji. Ekran listy może żądać listy lub tablicy. Jedną z podstawowych funkcji używanych w liście projektów dla web2project jest po prostu getProjectList. Nie modyfikuje podstawowych dane, tylko reprezentacja danych.

Przymiotniki są czymś zupełnie innym. Są one używane jako modyfikatory rzeczownika. Coś tak prostego jak getOpenProjects może być łatwo zaimplementowane z getProjects i parametrem switch, ale to ma tendencję do generowania metod, które wymagają dość dużo zrozumienia podstawowych danych i / lub struktury obiektu... niekoniecznie coś, co chcesz zachęcić. Mając bardziej wyraźne i konkretne funkcje, można może całkowicie owinąć i ukryć implementację przed używającym go kodem. Czy to nie jest jeden z punktów OO?

Bardziej niż nazwanie klasy, stworzenie odpowiedniej struktury pakietów może być trudnym, ale satysfakcjonującym wyzwaniem. Należy rozważyć oddzielenie obaw dotyczących modułów i ich związku z wizją aplikacji.

Rozważ układ swojej aplikacji teraz:

• App
  • VendorDocRequester (odczyt z serwisu internetowego i podanie danych)
  Vendordocviewer (use requester to provide Vendor docs)

Zaryzykowałbym przypuszczenie, że wiele się dzieje w kilku klasach. Jeśli zmienisz to w podejście bardziej oparte na MVC i pozwolisz małym klasom obsługiwać indywidualne zadania, możesz skończyć z czymś takim:

• App
  • VendorDocs
    • Model
      • Document (zwykły obiekt przechowujący dane)
      WebServiceConsumer (deal with nitty gritty in web service)
  • Kontroler
    • DatabaseAdapter (obsługa persistance przy użyciu ORM lub innej metody)
    WebServiceAdapter (wykorzystaj klienta, aby pobrać Dokument i umieścić go w bazie danych)
• widok
  • HelpViewer (użyj DBAdapter, aby wypluć dokument)

Wtedy nazwy klas zależą od przestrzeni nazw, aby zapewnić pełny kontekst. Same klasy mogą być z natury związane z aplikacją bez konieczności wyraźnie tak powiedzieć. W rezultacie nazwy klas są prostsze i łatwiejsze do zdefiniowania!

Jeszcze jedna bardzo ważna sugestia: zrób sobie przysługę i odbierz kopię wzorców projektowych Head First. To fantastyczna, łatwa do czytania książka, która pomoże Ci zorganizować aplikację i napisać lepszy kod. Docenianie wzorców projektowych pomoże Ci zrozumieć, że wiele problemów, które napotkasz, zostało już rozwiązanych, a Ty będziesz w stanie włączyć rozwiązania do twojego kod.

Leo Brodie w swojej książce "Thinking Forth" napisał, że najtrudniejszym zadaniem programisty było nazwanie rzeczy dobrze i stwierdził, że najważniejszym narzędziem programistycznym jest tezaurus.

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

Poza tym, nigdy nie używaj Węgierskiej notacji, unikaj skrótów i bądź konsekwentny.

Najlepsze życzenia.

W skrócie:
Zgadzam się, że dobre nazwy 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, późniejsza zmiana nazwy będzie kosztować mniej czasu i jest właściwym wyborem z punktu widzenia wydajności.

Long:
Ogólnie rzecz biorąc, często nie warto zbyt długo zastanawiać się nad nazwą przed wdrożeniem. Jeśli wdrożysz swój klasy, nazywając ją " Foo " lub "Dsnfdkgx", podczas implementacji widzisz, co powinieneś był nazwać.

Szczególnie w przypadku Javy + Eclipse, zmiana nazwy nie jest żadnym bólem, ponieważ ostrożnie obsługuje wszystkie odwołania we wszystkich klasach, ostrzega przed kolizjami nazw itp. I tak długo, jak klasa nie jest jeszcze w repozytorium kontroli wersji, nie sądzę, że jest coś złego w zmienianiu jej nazwy 5 razy.

Zasadniczo jest to pytanie, jak myślisz o refaktoryzacji. Osobiście podoba mi się, chociaż czasami denerwuje to moich kolegów z drużyny, ponieważ wierzą w nigdy nie dotykają systemu działającego . I ze wszystkiego, co możesz zmienić, zmiana nazw jest jedną z najbardziej nieszkodliwych rzeczy, które możesz zrobić.

Dlaczego by nie pomóc? HelpDocumentClient...it nie ma znaczenia, że to sprzedawca chodzi o to, że to klient serwisu internetowego, który zajmuje się dokumentami pomocy.

I tak nazewnictwo jest trudne.

Jest tylko jedna sensowna nazwa dla tej klasy:

HelpRequest

Nie pozwól, aby szczegóły implementacji odciągnęły Cię od znaczenia.

Zainwestuj w dobre narzędzie do refaktoryzacji!

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

Nie ma potrzeby wymyślać. To będzie łatwe do zrozumienia za rok, 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 we właściwej bibliotece. Dawno minęły czasy, w których powinieneś pamiętać, gdzie znajduje się każda część API.

Intelisense istnieje dla wszystkich głównych języków. Dlatego podczas korzystania z API 3rd party lubię używać jego intelisense dla dokumentacji w przeciwieństwie do korzystania z "rzeczywistej" dokumentacji.

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

StevesPostOnMethodNamesBeingLongorshort

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

Muszę się zgodzić, że nazewnictwo to sztuka. Staje się to trochę łatwiejsze, jeśli twoja klasa podąża za pewnym "wzorcem desigh" (fabryka itp.).

Jest to jeden z powodów posiadania standardu kodowania. Posiadanie standardu zwykle pomaga wymyślać nazwy, gdy jest to wymagane. Pomaga uwolnić umysł, aby używać go do innych ciekawszych rzeczy! (-:

Polecam przeczytanie odpowiedniego rozdziału kodu Steve ' a McConnella Complete (Amazon link ), który obejmuje kilka zasad, aby pomóc w czytelności, a nawet konserwacji.

HTH

Pozdrawiam,

Rob

Nie, debugowanie jest dla mnie najtrudniejsze! :-)

DocumentFetcher? Trudno powiedzieć bez kontekstu.

Może pomóc zachowywać się jak matematyk i pożyczać / wymyślać leksykon dla swojej domeny: rozliczać się na krótkich prostych słowach, które sugerują pojęcie bez pisowni go za każdym razem. Zbyt często widzę długie łacińskie zwroty, które zamieniają się w akronimy, co sprawia, że potrzebujesz słownika dla akronimów w każdym razie.

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

Jeśli jest to tylko wybór pomiędzy zestawem nazw, to powinien być kierowany przez konwencje, których używasz do budowania systemu. Jeśli trafiłeś w nowe miejsce, odkryte przez poprzednie konwencje, wtedy zawsze warto poświęcić trochę wysiłku, aby je rozszerzyć (odpowiednio, konsekwentnie), aby objąć ten nowy przypadek.

Jeśli masz wątpliwości, prześpij się z tym i wybierz pierwszą najbardziej oczywistą nazwę następnego ranka: -)

Jeśli pewnego dnia obudzisz się i uświadomisz sobie, że się myliłeś, zmień to od razu.

Paweł.

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

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

Nie zapominaj, że wzorce projektowe (nie tylko te GoF) są dobrym sposobem na zapewnienie wspólnego słownictwa i ich nazwy powinny być używane, gdy ktoś pasuje do sytuacji. Pomoże to nawet nowicjuszom, którzy są zaznajomieni z nomenklaturą, szybko zrozumieć architekturę. Czy ta klasa, na której pracujesz, ma działać jak Pełnomocnik, czy nawet Fasada ?

Czy dokumentacja sprzedawcy nie powinna być przedmiotem? Ten jest namacalny, a nie tylko jako jakaś 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ę beznadziejne. To wszystko wydaje się tak ogólne i chcę w końcu nauczyć się, jak wprowadzić odrobinę talentu i kreatywności do moich imion, aby naprawdę odzwierciedlały to, co opisują.

Jedną z sugestii jest sprawdzenie tezaurusa. Word ma dobry, podobnie jak Mac OS X. To naprawdę może pomóc mi wydostać się z chmur i daje mi dobre miejsce startowe, a także inspirację.

Jeśli nazwa tłumaczyłaby się świeckiemu programiście, to prawdopodobnie nie ma potrzeby jej zmieniać.