Саксонский родительный падеж в именных соглашениях?

Question

Как называются ваши функции, когда имена, содержащие родительный падеж саксонского языка, такие как «Приоритет задачи проверки» и «Приоритет аргумента» или «Увеличение задержки действия»?

Вы бросаете апостроф? verifyTasksPriority(), changeArgumentsPriority(), increaseActionsDelay()

Вы отбрасываете и апостроф, и "с"? verifyTaskPriority(), changeArgumentPriority(), increaseActionDelay()

Заменили ли вы саксонский родительный падеж на "of"? verifyPriorityOfTask(), changePriorityOfArgument(), increaseDelayOfAction()

Мне не нравится первый вариант, потому что звучит так, как будто функция работает над несколькими вещами, а не над одной. Мне не нравится второй вариант, потому что он не звучит нормально. Мне не нравится третий вариант, потому что слово из в названии функции просто не звучит правильно.

Какой вариант вы используете?

Answer 1

Я пользуюсь вторым. Это звучит хорошо для меня. Думайте о «Приоритете задач» как о сложном слове, таком как «пылесос».

Answer 2

Я считаю, что числа два и три звучат хорошо для меня и носят описательный характер. Я использую второй вариант. Первый вариант может сбивать с толку, поскольку он, похоже, указывает на то, что он работает с коллекцией, а не с одним элементом (например, Задачи вместо Задачи).

Я, однако, не знал, что я занимаюсь саксонским родительным программированием; Я немедленно добавлю это в свое резюме.

Answer 3

Я не помню, чтобы когда-либо чувствовал необходимость использовать любой из них из рук.

Я пишу код OO, в основном на языках OO, поэтому для проверки приоритета задачи у вас будет task.verifyPriority(), хотя обычно в качестве открытого метода обычно используется task.verify().

Проверка приоритета может включать другую логику - скажем, приоритет может быть только 7, если владельцем задачи является Боб. Установка для владельца одной из приоритетных 7 задач Боба Анны может сделать его несовместимым, но вам нужно будет вызывать verifyOwner() при смене владельца, а также verifyPriority() при изменении приоритета, даже если у них был та же логика?

Я обнаружил, что, делая API менее специфичными для деталей реализации, мы получаем более гибкий код.

В не-OO языках я обычно использую <library>_<Noun>_<Verb>, поэтому tman_task_verify ( task_t* self ) для проверки объекта задачи в библиотеке диспетчера задач для проверки себя.