Должен ли я использовать пункт охраны, и попытаться избежать пункта еще?

Question

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

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

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

Я не прав или что мне с этим делать?

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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