Должен ли я использовать предложение охраны и пытаться избежать предложения else?

Я прочитал (например, от Мартина Фаулера), что мы должны использовать предложение guard вместо одного возврата в (коротком) методе в ООП. Я также читал (откуда-то, я не помню), что в противном случае следует избегать положения.

Но мои коллеги (я работаю в небольшой команде только с тремя парнями) заставляют меня не использовать несколько возвратов в методе и как можно больше использовать предложение else, даже если в else есть только одна строка комментариев блок.

Это затрудняет мне следовать их стилю кодирования, потому что, например, я не могу просмотреть весь код метода на одном экране. И когда я код, я должен сначала написать предложение охраны, а затем попытаться преобразовать его в форму без нескольких возвратов.

Я ошибаюсь или что мне с ним делать?

Ответ 1

Это спорный и чистый эстетический вопрос.

Раннее возвращение исторически избегалось на языках C и подобных языках, поскольку было возможно пропустить очистку ресурсов, которая обычно помещается в конце функции в случае раннего возврата.

Учитывая, что Java имеет исключения и пытается, поймать, наконец, нет необходимости бояться ранних возвратов.

Персоналий, я согласен с вами, так как я часто возвращаюсь часто - это обычно означает меньше кода и более простой поток кода с меньшим количеством вложенности if/else.

Ответ 2

Оговорка о защите - хорошая идея, потому что она ясно указывает, что текущий метод не интересуется определенными случаями. Когда вы очищаете в самом начале метода, что он не имеет дело с некоторыми случаями (например, когда какое-то значение меньше нуля), тогда остальная часть метода является чистой реализацией его ответственности.

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

Говоря о предложениях охраны, которые вызывают исключения, вот одна статья о том, как вы можете упростить их в С# с помощью методов расширения: Как уменьшить циклическую сложность: защита Статья. Хотя этот метод недоступен в Java, он полезен в С#.

Ответ 3

Попросите их прочитать http://www.cis.temple.edu/~ingargio/cis71/software/roberts/documents/loopexit.txt и посмотреть, не изменит ли он их мнение. (Есть история к их идее, но я рядом с вами.)

Изменить: вот критические моменты из статьи. Принцип одиночных выходов из контрольных структур был принят принципиально, а не наблюдательные данные. Но данные наблюдений говорят, что разрешение нескольких способов выхода из управляющих структур затрудняет точное решение определенных проблем и не ухудшает читаемость. Отказ от этого делает код более сложным и более вероятным. Это относится к широкому кругу программистов, от студентов до авторов учебников. Поэтому мы должны разрешать и использовать несколько выходов, если это необходимо.

Ответ 4

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

Это действительно сводится к стилю и, по большому счету, относительно второстепенному. В целом, вы более эффективный разработчик, если вы можете адаптироваться к любому стилю. Если это действительно "затрудняет... следовать их стилю кодирования", то я предлагаю вам работать над ним, потому что в итоге вы получите лучшего инженера.

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