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

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

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

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

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

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

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

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

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

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

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

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

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