если/другое, хороший дизайн

Question

Приемлемо/хороший стиль, чтобы упростить эту функцию:

bool TryDo(Class1 obj, SomeEnum type) 
{ 
    if (obj.CanDo(type)) 
    { 
     return Do(obj); 
    } 
    else 
    { 
     return false; 
    } 
} 

как:

bool TryDo(Class1 obj, SomeEnum type) 
{ 
    return obj.CanDo(type) && Do(obj); 
} 

Второй вариант короче, но, возможно, менее интуитивным.

Answer 1

Что бы код:

return obj.CanDo(type) ? Do(obj) : false; 

Answer 2

Никогда не делайте этого. Держите его простым и интуитивно понятным.

Answer 3

Версия с кронштейнами:

bool TryDo(Class1 obj, SomeEnum type) 
{ 
    if (obj.CanDo(type)) 
    { 
     return Do(obj); 
    } 

    return false; 
} 

или версия без скобок (в ответе комментарии высокие дебаты по этому поводу):

bool TryDo(Class1 obj, SomeEnum type) 
{ 
    /* 
    * If you want use this syntax of 
    * "if", this doing this on self 
    * responsibility, and i don't want 
    * get down votes for this syntax, 
    * because if I remove this from my 
    * answer, i get down votes because many 
    * peoples think brackets i wrong. 
    * See comments for more information. 
    */ 
    if (obj.CanDo(type)) 
     return Do(obj); 

    return false; 
} 

Вашего первый пример кода лучше , но я думаю, что моя версия еще лучше.

Answer 4

В этом случае, я бы с первым вариантом - это гораздо более читаемым и намерение код гораздо понятнее.

Answer 5

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

Answer 6

else бесполезен, и &&, как бы это ни было очевидно, не так читается, как чистый текст.

Я предпочитаю следующее:

bool TryDo(Class1 obj, SomeEnum type) 
{ 
    if (obj.CanDo(type)) 
    { 
     return Do(obj); 
    } 
    return false; 
} 

Answer 7

Да.

Особенно с именами, похожими на выбранные имена, т.е. CanDoSomething и DoSomething это совершенно ясно любому компетентному программисту, что второй код делает: «тогда и только тогда, когда условие выполняется, сделать что-то и вернуть результат ». «Тогда и только тогда, когда» является основным значением короткозамкнутого оператора &&.

Первый код свернут и излишне длинный, не указав больше информации, чем второй код.

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

Многие люди заявляют, что первая версия «намного понятнее». Я бы очень хотел услышать их аргументы. Я не могу думать ни о чем.

С другой стороны, есть это тесно связано (хотя и не вполне тот же код):

if (condition) 
    return true; 
else 
    return false; 

это должно всегда быть преобразованы к этому:

return condition; 

Нет исключение. Это краткое и более читаемое для того, кто компетентен на этом языке.

Answer 8

Другой вариант, который может быть немного более удобным для чтения используется условный оператор:

bool TryDo(Class1 obj, SomeEnum type) { 
    return obj.CanDo(type) ? Do(obj) : false; 
} 

Answer 9

мне не нравится этот дизайн, и, возможно, не по той очевидной причине. Меня это беспокоит. return Do (obj); Для меня нет смысла, чтобы функция Do имела тип возврата bool. Является ли это заменой ошибок, вызывающих ошибку? Скорее всего, эта функция должна быть недействительной или возвращать сложный объект. Сценарий просто не должен появляться. Также, если bool как-то имеет смысл сейчас, он может легко перестать иметь смысл в будущем. С изменением кода вам потребуется больше исправлять ошибки

Answer 10

Укороченная версия скрывает тот факт, что Do делает что-то. Похоже, вы просто делаете сравнение и возвращаете результат, но вы на самом деле делаете сравнение и выполняете действие, и не очевидно, что код имеет этот «побочный эффект».

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

Answer 11

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

Это может быть достигнуто либо путем:

return obj.CanDo(type)? Do(obj) : false; 

Или,

if(obj.CanDo(type)) return Do(obj); 
return false; 

Я считаю это выше, потому что этот же стиль может быть воспроизведен независимо от типа возврата. Например,

return (array.Length > 1)? array[0] : null; 

Или

return (curActivity != null)? curActivity.Operate() : 0; 

Тот же стиль также может быть расширена до ситуаций, которые не имеют возвращаемого значения:

if(curSelection != null) 
    curSelection.DoSomething(); 

Мои два цента.

Answer 12

я мог бы получить ненависть за это, но как насчет:

if (obj.CanDo(type)) return Do(obj); 
return false; 

Я не люблю, когда брекеты лайнеры.

Answer 13

Я думаю, что Class1 Type должен определить, может ли он это сделать, учитывая значение SomeEnum.

Я хотел бы оставить решение о том, может ли она справиться вход для того, чтобы решить:

bool TryDo(Class1 obj, SomeEnum type) 
{ 
    return obj.Do(type));  
} 

Answer 14

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

Answer 15

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

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

Answer 16

IMO это только ОК, если вторая функция не имеет побочных эффектов. Но поскольку Do() имеет побочные эффекты, я бы пошел с if.

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

См. Eric Lippert's Blog для более подробного объяснения.

Answer 17

Проблема побочного эффекта, которую некоторые люди упоминают, является фиктивной. Никто не должен удивляться тому, что метод «Do» имеет побочный эффект.

Дело в том, что вы вызываете два метода. Оба эти метода имеют bool как возвращаемое значение. Ваш второй вариант очень ясный и лаконичный. (Хотя я бы избавиться от внешней скобки и вы забыли концовки запятой.)

Answer 18

No. Второй версия

return (obj.CanDo(type) && Do(obj)) 

зависит от поведения короткого замыкания на & & оператора, который оптимизация, а не метод управления потоком программы. На мой взгляд, это немного отличается от использования исключений для потока программы (и почти так же плохо).

Я ненавижу умный код, это сука, чтобы понимать и отлаживать. Целью функции является «если мы сможем это сделать, тогда сделаем это и вернем результат, иначе возвращаем false». Исходный код делает это очень понятным.

Answer 19

Ни то, что, когда TryDo возвращает False, вы не можете определить, было ли это потому, что 'Not CanDo' или 'Do False'.

Я полностью понимаю, что вы можете проигнорировать результат, но способ его выражения подразумевает, что результат имеет смысл.

Если результат не имеет смысла, цель будет понятнее с

void TryDo(Class1 obj, SomeEnum type) 
{ 
    if (obj.CanDo(type)) 
     Do(obj); 
    return; 
} 

Если результат действительно имеет значение, то должно быть так, чтобы различать между двумя «ложными» возвращается. И.Е. Что означает «If (! TryDo (x))» означает?

Edit: Для того, чтобы поместить это иначе, код OP является говоря, что «я не умею плавать» так же, как «я пытался плавать и утонул»

Answer 20

Есть несколько хороших ответов уже, но я подумал, что я покажу еще один пример (что я считаю) хорошего, читаемого кода.

Держат или удаляем фигурные скобки назад по корпусу инструкции if в соответствии со вкусом.

Мне нравится этот подход, поскольку он показывает, что результат false если что-то еще не происходит, и я думаю, что это более ясно показывает, что Do() делает что-то и возвращает логическое значение, которое TryDo() использует в качестве возвращаемого значения.