Почему использование союзов в именах методов является плохим соглашением об именах? [закрыто]

В моей команде мы тесно сотрудничаем с несколькими архитекторами программного обеспечения. Они одобряют все проектные решения наших проектов, делают некоторые обзоры кода и т. Д.

Наши проекты состоят в основном из серверной функциональности, реализованной на PHP с использованием фреймворка Symfony 2. Таким образом, синтаксически код, соглашения об именах и структура проекта выглядят практически идентично тому, как будет выглядеть Java (Symfony 2 поддерживает такую ​​структуру). Я упоминаю об этом, потому что специфические для Java соглашения также применимы в нашем случае (если это возможно).

Недавно они предложили кое-что, что я нахожу очень странным: все методы должны иметь соединения в названии, например getEntityOrNull, setValueOrExceptionи т. Д.

Такое соглашение об именах кажется мне очень неправильным, но я не могу придумать какие-либо конкретные аргументы или онлайн-статьи / страницы, которые специально оспаривают это.

Единственное, что я придумал, это:

• такая информация должна присутствовать в аннотациях метода, например @returnили@throws
• использование союзов («и», «или» и т. д.) в именах методов обычно предполагает, что принцип единой ответственности должным образом не соблюдается

Какие еще конкретные аргументы против этого соглашения об именах?

Вероятно, они делают это из-за конфликтов имен. Я предполагаю, что у вас не может быть двух названных методов getEntity, один из которых, возможно, вызывает исключение, а другой возвращает null. Поэтому вы должны назвать их соответственно.

Мне, например, не нравится практика использования множества разных способов вызова одного и того же метода, если только он не выполняет некоторые изменения, которые может выполнять только этот конкретный класс.

Другими словами, если getValueOrNullэто просто вызов getValueOrException, захват исключения и, в этом случае, возврат null, это может выполнить вызывающая сторона. Он загромождает класс методами, которые не приносят ничего полезного. Скорее я бы предпочел getValue, и знаю, что это исключение. Более того, я бы предпочел знать, что все методы get потенциально генерируют исключения, и ни один из них не возвращает nullвзамен так, чтобы поведение было одинаковым во всем моем проекте, или наоборот, все потенциально возвращались null, и знал, что вызывающая сторона должна была бы генерировать исключение, если это было желательно.

Тем не менее, это также правда, что вы не отвечаете за это. Мой совет - поднимайте это, но не переживайте, мелочи. В конечном счете, ответственность за такие соглашения об именах ложится на их плечи, независимо от того, примут ли они ваш совет, и, поскольку это их ослы на кону, я считаю, что это их прерогатива сказать «нет», по моему скромному мнению.

Хотя использование союзов часто указывает на нарушение SRP, в этом случае оно просто указывает возвращаемое значение алгебраического типа данных бедного человека, которое может быть одним из двух значений, либо nullзначением «успеха».

Они используют своего рода венгерскую нотацию, чтобы компенсировать слабые места в системе типов, а именно отсутствие необнуляемых типов. Другими словами, в вашей @returnаннотации нет способа указать, что функция никогда не вернется null, и, наоборот, в вашей @returnаннотации нет способа указать, что функция может возвращать null.

Кроме того, я считаю, что @throwsаннотации не являются обязательными в php, поэтому отсутствие аннотации не указывает на отсутствие исключения, хотя это лучше решить, если сделать аннотацию обязательной в руководстве по стилю.

Учитывая те ограничения языка, который вы используете, это не совсем неразумный стиль.

В моем коде я иногда создаю пары методов с именами, такими как getEntity () и getEntityOrNull (). Название ясно показывает ожидаемое поведение. Если getEntity () не находит сущности, тогда генерируется исключение. getEntityOrNull () вернет ноль.

Благодаря этому вызывающий код становится немного понятнее. Если вызывающий код должен иметь сущность, тогда getEntity сделает свое дело. Если entity - это какая-то необязательная вещь, тогда getEntityOrNull является методом выбора.

То же самое может быть достигнуто с помощью одного метода, но это затем переносит часть нагрузки на вызывающую программу. Вам всегда нужно проверять на ноль, или вам нужен блок try / catch. В любом случае это дополнительный код, который необходимо дублировать при каждом вызове метода.

Если ваши архитекторы не используют такие пары методов, то да, я бы поставил под сомнение необходимость суффикса.

Никогда не видел метод setValueOrException. Не могу придумать хорошего варианта использования для этого.

Вы можете спросить архитекторов, почему. Те, кого я знаю, всегда рады объяснить свои решения. Часто в мельчайших (а иногда и мучительных) деталях.

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

Пока вы это делаете, вы должны убедить их не использовать части "get" и "set", если только эти методы не устанавливают непосредственно или не получают переменную-член.