Jak nazwać zmienną, gdy słowo jest jednocześnie rzeczownikiem i czasownikiem

48

Zetknąłem się z problemem związanym z przypadkami narożnymi z ogólnymi wskazówkami:

rzeczowniki dla zmiennych
czasowniki dla funkcji

W szczególności mam przypadek, w którym słowo jest dwuznaczne - może to być czasownik lub rzeczownik. W niektórych przypadkach, gdy omawiamy aplikację, będzie ona używana w obie strony w tym samym zdaniu.

Moim celem jest upewnienie się, że program pozostanie czytelny zarówno dla przyszłych programistów, jak i dla mnie, gdy wrócę do części kodu później.

Jednym z przykładów jest battery. A batteryma chargei możesz także charge()baterię.

Myślę, że o obu Battery.Chargei Battery.Charge(value)będzie mylące dla przyszłych programistów.

Moje obecne rozwiązanie to po prostu wybrać inne słowo dla jednego lub obu tych przypadków (zmiennej i funkcji). Mój problem z tym podejściem polega na tym, Batteryże zmienna obiektu i funkcja chargenie są zgodne z dyskusjami projektowymi z udziałem Battery.

Moje pytanie brzmi, czy istnieje inny / lepszy sposób radzenia sobie z tym konfliktem w konwencji nazewnictwa?

Dodatkowe lektury na ten temat. Nikt tak naprawdę nie zajął się szczegółem mojego pytania.

naming variables

— Społeczność
źródło

3

dodaj funkcję ładowania i naładuj ją wystarczająco łatwo i wyraźnie

— maniak zapadkowy

2

Czy możesz poprzedzić zmienną rzeczownikową słowem „Current-”? Więc „CurrentCharge” vs „Charge ()”?

— Brian Snow,

6

lub po prostu ChargeLevel, aby uzyskać aktualne ładowanie

— maniak ratchet

5

Wymyśl słowo. WordNet nie wydaje enqueuesię słowem, ale jest czasownikiem w Javie. Jak o doCharge? Nadal nie powiedzie się test symetrii, ponieważ twoje inne metody nie będą miały tego prefiksu

— Nędzna Zmienna

5

„Prąd” = teraz lub „prąd” = przepływ ładunku. Jedynym prawdziwym rozwiązaniem jest zastąpienie angielskiego bardziej sensownym językiem!

— DarenW

38

W podobnych sytuacjach staram się znaleźć synonimy. W tym przypadku użyłbym „doładowania” dla czasownika. „Re” jest nieco zbędne, ale znaczenie jest jasne. Użycie prostego „ładowania” dla pozostałego ładunku w akumulatorze jest dwuznaczne, ponieważ nie określa żadnych jednostek fizycznych. Wolałbym „availableAmpHours”, „hoursUntilRecharge” lub coś podobnego. Jednostki będą zależeć od wszystkiego, co jest wygodne dla aplikacji.

Osobiście wolę używać czasowników tylko dla funkcji, które zmieniają stan. Używam rzeczowników do funkcji niemutujących. Przypuszczam, że to zależy od twojego punktu widzenia. Na poziomie maszyny funkcje niemutujące coś robią, ale na poziomie modelu nie.

— Kevin Cline
źródło

2

Doskonały punkt na jednostkach. W tym przypadku jednostki są wyraźnie pomijane, ponieważ mogą się zmieniać w zależności od przeprowadzanej przez nas analizy. To znaczy, używamy różnych skal czasowych, a Bateria dostosowuje swoje działania pod względem skali analizy.

1

Wolę czasowniki dla drogich, niemutujących funkcji. Np. Funkcje uruchamiające zapytanie w bazie danych.

— Brian

20

Po prostu to wyrzucamy, ale być może rozwiązaniem tego niejednoznacznego nazewnictwa jest całkowite usunięcie tej funkcjonalności z baterii. Nigdy nie widziałem samodzielnie ładującej się baterii i dla mnie sensowniejsze byłoby posiadanie klasy BatteryCharger. Pomogłoby to utrzymać Twoje obawy w większym stopniu oddzielone od siebie i uwydatnić działanie.

battery.Charge(50) vs batteryCharger.Charge(battery, 50)

Dla mnie druga forma jest znacznie bardziej zrozumiała i utrzymuje cały kod „Ładowanie” w jednym miejscu, zamiast posypywać go wszystkimi klasami akumulatorów.

— śmiertelnik
źródło

6

Nie jest to zła myśl, ale w tym przypadku Batteryjest to abstrakcja dla akumulatora + systemu ładowania. Nasza aplikacja nie wymaga dzielenia dwóch aspektów na osobne obiekty, więc Batterydla wygody są one łączone w jeden (aka ). Ostatecznie fizyka akumulatorów narzuca, że ma on jakąś funkcję akceptowania ładunku.

W takim przypadku uważam, że odpowiedź Kevina Cline'a jest tym, czego szukasz. Dla jasności użyłbym ładowania i rozładowania dla funkcji mutacji i ładowania dla nazwy właściwości. Być może ChargePercent również byłby dobry.

— mortalapeman

Czy jesteś programistą Java? Jest to oczywiście naruszenie zasady „Nie powtarzaj się”. W rzeczywistości powtarzasz WSZYSTKO oprócz parametru „50”. Gdybym spróbował, nie mogłem wymyślić gorszego przykładu naruszenia zasad SUCHEJ.

— zapakowane w pudełko

@boxed Czy bierzesz pod uwagę mój przykład? Ponieważ nie jestem pewien, jak możesz twierdzić, że naruszam DRY, gdy nie mam implementacji. Jestem wielkim zwolennikiem zasad SOLID i po prostu nie widzę, jak doszedłeś do tego wniosku.

— mortalapeman

Naruszasz DRY, tworząc niepotrzebną klasę BatteryCharger, która w jakiś sposób spowoduje zmianę stanu baterii. Dlatego BatteryCharger zaakceptuje pewne dane wejściowe, które następnie natychmiast przekaże na Baterię.

— kevin cline

9

Unikaj podwójnego znaczenia

Celowo wybrałeś słowo, które ma więcej niż jedno znaczenie, i ta pierwsza decyzja jest problemem. Istnieje mnóstwo słów, które są problematyczne dla programistów. Innym przykładem może być phone. Możesz phonekogoś lub możesz mieć phonew kieszeni.

Użyj Getters i Setters

Standardowe nazewnictwo większości obiektów to metody pobierające / ustawiające właściwości.

Battery.Charge            // would be a property
Battery.setCharge(value)  // would set the property
Battery.getCharge()       // would get the property

Właściwości są stanami, a nie rzeczownikami

Myślę, że mylisz się, klasyfikując właściwości obiektu jako rzeczowniki, a zmienne można również traktować jako stany. Są to stany związane z lokalnym zakresem ich istnienia.

Możesz opisać wartość, którą mają jako rzeczownik, ale nie jestem pewien, czy tak jest we wszystkich przypadkach.

W terminologii OOP właściwości obiektu opisują stan tego obiektu. W twoim przypadku Batteryjest to obiekt i Chargejest stanem. To byłaby właściwość obiektu, ale zależy to od kontekstu jego użycia.

Jeśli musisz być w stanie Chargenaładować baterię, a także wiedzieć, co to jest prąd Charge, masz problem.

Używanie zakresu do wymuszania kontekstu

Kontekst wyjaśnia, jakie znaczenie słowa ma przekazać metoda lub właściwość. Zakres określa ustawienie właściwości / metody spoza obiektu.

Batter._charge            // a hidden private property
Battery.setCharge(value)  // would set the private property
Battery.getCharge()       // would get the private property
Battery.Charge()          // would perform the Charge action

Metody to czasowniki

Możesz opisać metodę obiektu jako czasownik, ale lepiej nadaje się akcja słowo. W terminologii OOP wykonujesz działania na obiektach przy użyciu ich metod. Zła forma modyfikowania właściwości obiektu spoza obiektu. Preferowane jest wywołanie metody, która wykonuje wymagane działania, które powodują zmianę stanu.

Słowo Chargejest czasownikiem, ale także rzeczownikiem. W przypadku wywołania metody akcji staje się jasne, że czasownik jest używany Battery.Charge(....).

Ale kontekst jest bardzo ważny. Chociaż słowo Charge()jest czasownikiem, nie jest tak znaczące jak startCharging().

Prawidłowe metody Batterymogą obejmować Charging, Discharging, setCharge, getCharge, hasCharge, Dischargei Charged.

Proste metody jedno słowo często nie wyraźnie stwierdzić jasno swoje działania, ale są pewne przypadki, jak openi closegdzie wymagana jest trochę wyjaśnień.

Więc tak naprawdę nie ma poprawnej odpowiedzi na pytanie, jak nazwać tego rodzaju właściwości / metody. Tyle, że musisz mądrze stosować powyższe techniki, aby upewnić się, że nie ma zamieszania.

— Reactgular
źródło

2

Dla przypomnienia, to klient używa niejednoznacznej terminologii. I nie stworzył ten bałagan. :-) Podniosłem pytanie, ponieważ myślałem, że nie jestem jedyną osobą, która wpadła w taką sytuację. Masz kilka ważnych punktów w swojej odpowiedzi. W tym konkretnym przypadku, nie pracujemy na ziarnistości czasie StartCharge()i EndCharge()wiązałoby. W rzeczywistości ta terminologia spowodowałaby znaczne obciążenie związane z obsługą systemu akumulatorów. W każdym przedziale to może albo Charge()albo Discharge().

1

Podstawową trudnością jest utrzymanie synchronizacji semantyki programowania wewnętrznego z terminologią używaną przez klienta. Chargeokazuje się być najłatwiej zrozumiałym niejednoznacznym słowem dla tej domeny. Istnieje kilka innych.

6

Przygotuj je czasownikami, które uczynią z nich czasownik lub rzeczownik.

Battery.doCharge()

Battery.getCharge()

— Jürgen Paul
źródło

4

W przypadku czasownika myślę, że Chargejest OK. W przypadku rzeczownika, czy getCurrentChargeLevelzadziałałoby dla ciebie?

— FrustratedWithFormsDesigner
źródło

Nie jestem tego pewien. Ponieważ używamy C #, możemy zadeklarować get i set we właściwości zamiast potrzebować osobnych funkcji. Niezależnie od tego martwię się o konserwację i to, jak to będzie wyglądać, gdy zapomnę tego, co napisałem. Czy getCurrentChargeLevel()nadal nie musiałbym odwoływać się do wewnętrznej zmiennej Batteryi jaka byłaby nazwa tej zmiennej?

czy ładowanie jest napięciem czy procentem?

— mhoran_psprep

1

@ GlenH7: Ach, rozumiem. Nie podałeś C #, a mój mózg jest w trybie Java. Cóż, tak czy inaczej, myślę, że w przypadku rzeczownika reprezentującego ilość ładunku znajdującego się obecnie w akumulatorze coś w tym rodzaju Battery.currentChargeLevelmoże działać. Można spróbować użyć Battery.coloumbsalbo Battery.ampereHoursale to może nie być tak oczywiste ...

— FrustratedWithFormsDesigner

1

@mhoran_psprep - żaden. ;-) Chargejest Energyco Power(V * wzmacniacze == W) pomnożonej przez czas. W takim przypadku opłata to liczba. Istnieje również stan naładowania, który stanowi procent.

@FrustratedWithFormsDesigner - tak, opuściłem C #, ponieważ myślałem, że szerszy przypadek narożny ma zastosowanie bez względu na język. Watt*timena pewno nie pasowałby do rozmów projektowych, ale tak ChargeLevelby było.

0

W większości przypadków dodanie czasownika pomocniczego, przysłówka lub przymiotnika jest wystarczająco dobre, aby je rozróżnić i może pomóc w zrozumieniu. W przypadku Charge i Charge () na akumulatorze DeltaCharge () może pokazywać, że jest to funkcja, która może obsługiwać ładowanie lub rozładowywanie.

Delta (w przypadkach, w których występuje zmiana, ale niejednoznaczna) jest modyfikatorem, którego używam i polecam innym przez cały czas do przekazywania zmiany stanu (nawet jeśli czasownik jest półoczywisty).

— Jeff Langemeier
źródło

0

Notacja węgierska na ratunek. Możesz mieć intChargei fcnCharge(value), co pozwala uniknąć nieporozumień i nie dodając szalony długą nazwę, kiedy trzy litery będzie działać dobrze.

Lub możesz po prostu użyć tej samej nazwy i pozwolić IDE sobie z tym poradzić. W każdym razie tworzenie dłuższej lub innej nazwy może być równie mylące na dłuższą metę.

— Ryathal
źródło

+1 za unikalną perspektywę odpowiedzi. Niestety, węgierski zapis jest wyraźnie słowny zgodnie z naszymi wytycznymi dotyczącymi stylu kodu. To nie zmienia potencjalnej wartości twojej odpowiedzi, tylko że nie mogę jej użyć jako mojego rzeczywistego rozwiązania.