Только один оператор возврата на метод, даже в этом сценарии?
Причина в stri_sub(..., -2). Вам нужно указать от 1 до -2 символов, т.е.
library(stringi)
with(df, ifelse(stri_sub(PlayerName, -1, -1) %in% c('Q', 'Z'),
stri_sub(PlayerName, 1, nchar(PlayerName)-2), PlayerName))
#[1] "Joh" "Robert" "Alber" "Jef"
ДАННЫЕ
structure(list(PlayerName = c("JohnQ", "Robert", "AlbertZ", "JeffQ"
), Score = c(75L, 80L, 67L, 88L)), row.names = c(NA, -4L), class = "data.frame")
12 ответов
Откровенно говоря, такие ситуации - то, почему чрезмерно твердые правила плохи.
Точка правил как это должна сделать код более читаемым и удобным в сопровождении, поэтому когда они делают код тяжелее для чтения, они должны быть проигнорированы.
Это не означает, что правило должно быть отброшено полностью, потому что большую часть времени оно действительно делает код более читаемым.
Код, который пытается только иметь один возврат на функцию, намного более сложен. Это обычно - вложенное множество крыс если-thens и присвоения. Я бросаю вызов Вам смотреть на такой код и знать, что правильное значение всегда, возвратился из тех различных путей.Ни за что.
Однако большие функции указывают, что Вы, возможно, должны осуществить рефакторинг код в меньшие более простые функции так или иначе.
Лично я думаю
public static string ChopText(string Text))
{
if(String.IsNullOrEmpty(Text)
return Text;
...
}
прекрасен полностью, если Вам не нравятся они И если это становится большим.
"Мне нравится идея наличия только 1 оператора возврата на метод". Объяснить?
Как только Вы знаете, что параметры, переданные Вашему методу, недопустимы, необходимо возвратить или выдать исключение.
Плохо:
if (Valid) { do lots of stuff}
else {return};
Чисто:
if (invalid) { return; }
if (invalid2) {return; }
Другой подход:
if (invalid) {
throws IllegalArgumentException();
За исключениями на месте нет никакого "однократного въезда - единственный выход" правило больше так или иначе, таким образом, нет абсолютно никакой потребности следовать за строгим "один оператор возврата" правило. Поток управления может - теоретически - выходят из функции любое время путем выдачи исключения и раскручивания стека, поэтому даже если Вы реализуете строгий "однократный въезд - единственный выход" политика нет никакой гарантии, что это будет сопровождаться вообще.
Не стесняйтесь выходить из функции в любое время, если она подходит Вам!
Ваши методы не должны в общих чертах охватывать более затем "один экран". Если они делают Вы должны (в целом снова), пытаются разделить их на несколько методов. Это, вероятно, намного более важно, чем иметь "только один оператор возврата"...
В конце концов, то, что мы ищем, является удобочитаемостью.
Я сильно верю в "одну запись / один выход", за исключением проверки исходных данных во главе функции. Это должно произойти, прежде чем реальная работа функции начинается все же.
Я думаю, что это правило было предназначено, чтобы мешать людям выйти посреди кода, это делает реальную работу просто, потому что они думают, что "сделаны".
Проблема с несколькими возвратами состоит в том, что Вы не можете быть уверены, что необходимая обработка выхода будет выполнена, такие как закрытие сокета или выпуск некоторого другого ресурса.
Это - случай, где правило должно быть проигнорировано. Распространено иметь несколько защитных пунктов в точке входа к методу, которые возвращают или бросают ArgumentException, если аргументы передали в, не находятся в правильном формате. Просто сохраните эти операторы кластеризируемыми в начале Ваших методов.
Действительно необходимо взвесить расходы и доходы выполнения чего-то вроде этого. Будут преимущества наличия только одного оператора возврата перевешивают оборотные стороны необходимости исказить метод, который должен быть довольно прост записать?
Я пошел бы без для этого случая.
Правило вытеснено. Простой и простой. Это существует, чтобы помочь плохим программистам написать больше читаемого кода..., и это имело неприятные последствия. Сделайте свой код маленьким и читаемым, и избавьтесь от того глупого правила.
Я категорически не согласен с идеей, что «один вход - один выход» приводит к сложному коду. Я только что написал приложение для телефонов Blackberry и Android на Java, которое состоит примерно из 100 файлов, и нет ни одного метода, который не завершился бы в конце. Хотя это приложение с графическим интерфейсом и многопоточное, ни один код не является сложным. Немногие, если какие-либо процедуры, не отображаются на экране полностью. Я занимаюсь проектированием и написанием программного обеспечения на протяжении 46 лет на всех языках и операционных системах, кроме нескольких, и для меня «один вход - один выход» делает код очень простым, легким для чтения и сопровождения. Моя стоимость 0,02 доллара. Извините, если я взъерошил перья.