Eksperymenty saksońskie w konwencjach nazewnictwa?

Question

Jak nazywasz swoje funkcje, gdy nazwy zawierają dopełniacz saksonowy, np. "Zweryfikuj priorytet zadania" i "Zmień priorytet argumentu" lub "Zwiększ opóźnienie akcji"?

Czy upuszczasz apostrof? verifyTasksPriority(), changeArgumentsPriority(), increaseActionsDelay()

Czy upuszczasz apostrof i "s"? verifyTaskPriority(), changeArgumentPriority(), increaseActionDelay()

Czy zastępujesz dopełniacz saksonowy wartością "of"? verifyPriorityOfTask(), changePriorityOfArgument(), increaseDelayOfAction()?

Nie podoba mi się pierwsza opcja, ponieważ wygląda na to, że funkcja działa na wielu rzeczach, a nie tylko na jednej rzeczy. Nie podoba mi się druga opcja, ponieważ nie brzmi naturalnie. Nie podoba mi się trzecia opcja, ponieważ słowo, z, w nazwie funkcji po prostu nie brzmi dobrze.

Jakiej opcji używasz?

Answer 1

Używam drugiego. To brzmi dobrze dla mnie. Pomyśl o "Priorytecie zadań" jako złożonym słowie, takim jak "odkurzacz".

Answer 2

Uważam, że liczby dwa i trzy brzmią dobrze dla mnie i mają charakter opisowy. Używam drugiej opcji. Pierwsza opcja może być myląca, ponieważ wydaje się wskazywać, że działa ona na zbiorze, a nie na pojedynczym przedmiocie (na przykład Zadania zamiast zadania).

Nie byłem jednak świadomy, że robiłem saksofonistyczne programowanie dopełniające; Dodam to do mojego CV natychmiast.

Answer 3

Nie pamiętam, aby kiedykolwiek odczuwałem potrzebę użycia którejkolwiek z nich z ręki.

Piszę kod OO, głównie w językach OO, więc w celu sprawdzenia priorytetu zadania masz task.verifyPriority(), choć zwykle jako metodę publiczną masz tylko task.verify().

Weryfikacja priorytetu może obejmować inną logikę - powiedzmy, że priorytetem może być tylko 7, jeśli właścicielem zadania jest Bob. Ustawienie właściciela jednego z zadań Priorytetu Boba dla Anny spowodowałoby, że byłby niespójny, ale czy miałbyś wywołać verifyOwner(), gdy zmienisz właściciela, a także verifyPriority(), kiedy zmienisz priorytet, nawet jeśli mają taką samą logikę?

Stwierdziłem, że tworzenie interfejsów API mniej specyficznych dla szczegółów implementacji prowadzi do łatwiejszego kodu.

W językach spoza OO zwykle używam <library>_<Noun>_<Verb>, więc tman_task_verify (task_t* self), aby zweryfikować obiekt zadania w bibliotece menedżera zadań w celu zweryfikowania samego siebie.