Мне нравится идея иметь только один оператор return для каждого метода.
Что вы делаете в этой ситуации?
public static string ChopText(string Text)
{
if (String.IsNullOrEmpty(Text))
{
// return here ?????
}
}
Единственная альтернатива, о которой я могу думать, это установить флаг, а затем проверить флаг.
Проблема в том, что мне не нравятся огромные операторы if, которые охватывают больше, чем страницу. Я также видел уродливые вложенные операторы if в результате этого.
Честно говоря, такие ситуации, почему слишком жесткие правила плохие.
Точка правил, подобная этой, состоит в том, чтобы сделать код более удобочитаемым и поддерживаемым, поэтому, когда они делают код более трудным для чтения, их следует игнорировать.
Это не означает, что правило должно быть полностью отброшено, потому что большую часть времени он делает код более удобочитаемым.
Код, который пытается иметь только один возврат на одну функцию, намного сложнее. Обычно это гнездо крыс if-thens и заданий. Я призываю вас взглянуть на такой код и знать, что правильное значение всегда возвращается с этих разных путей. Ни в коем случае.
Сказав это, большие функции указывают, что вам может понадобиться реорганизовать код на более мелкие более простые функции.
Лично я думаю
public static string ChopText(string Text))
{
if(String.IsNullOrEmpty(Text)
return Text;
...
}
абсолютно нормально, если вам не нравятся те, и если он становится большим.
Это случай, когда правило следует игнорировать. Обычно в точке входа есть несколько защитных предложений для метода, возвращающего или генерирующего исключение ArgumentException, если переданные аргументы не в правильном формате. Просто сохраните эти утверждения, сгруппированные в начале ваших методов.
"Мне нравится идея иметь только 1 оператор возврата для каждого метода". Объясните?
Как только вы знаете, что параметры, переданные вашему методу, недействительны, вы должны вернуть или выбросить исключение.
Плохо:
if (Valid) { do lots of stuff}
else {return};
Clean:
if (invalid) { return; }
if (invalid2) {return; }
Другой подход:
if (invalid) {
throws IllegalArgumentException();
Вам действительно нужно взвесить затраты и выгоды, связанные с этим. Будут ли преимущества наличия только одного оператора возврата перевешивать недостатки, связанные с необходимостью использовать метод, который должен быть достаточно простым для записи?
В этом случае я бы не пошел.
При наличии исключений в любом случае правила "единственной записи - один выход" больше не существует, поэтому абсолютно не нужно следовать строжайшему правилу "одного возврата". Поток управления может - теоретически - выходить из функции в любое время, бросая исключение и разматывая стек, поэтому, даже если вы выполняете строгую политику "одиночной записи - один выход", нет никакой гарантии, что она будет выполняться вообще.
Не забудьте выйти из функции в любое время, если она вам подходит!
Ваши методы должны в общих чертах не охватывать больше "одного экрана". Если они это сделают, вы должны (в общем, снова) попытаться разбить их на несколько методов. Это, вероятно, гораздо важнее, чем иметь "только один оператор возврата"...
В конце концов, то, что мы ищем, является читабельностью.
Я очень верю в "один вход/один выход", за исключением проверки входов в верхней части функции. Это должно произойти до того, как начнется реальная работа функции.
Я думаю, что это правило предназначалось для того, чтобы люди не выходили в середине кода, что делали настоящую работу просто потому, что они думают, что они "сделаны".
Проблема с несколькими возвратами заключается в том, что вы не можете быть уверены, что будет выполнена требуемая обработка завершения, например, закрытие сокета или освобождение другого ресурса.
public static string ChopText(string Text)
{
string returnString = "";
if(String.IsNullOrEmpty(Text))
{
returnString = "return string text";
}
return returnString;
}
Это правило устарело. Легко и просто. Он существует, чтобы помочь плохим программистам написать более читаемый код... и он обернулся. Сделайте свой код маленьким и читаемым, и избавитесь от этого глупого правила.
Я категорически не согласен с идеей, что "один вход один выход" приводит к сложному коду. Я только что написал приложение для телефонов Blackberry и Android на Java, которое состоит из примерно 100 файлов и не существует ни одного метода, который не будет завершен в конце. Хотя это приложение для графического интерфейса и многопоточное, ни один из них не является сложным. Мало, если какие-либо подпрограммы не отображаются полностью на экране. Я занимаюсь разработкой и написанием программного обеспечения в течение 46 лет, кроме нескольких языков и операционных систем, и для меня "один вход с одним выходом" позволяет очень просто, легко читать и поддерживать код. Мой 0,02 доллара. Извините, если я взъерошил любые перья.