2009-06-09 4 views
5

У меня трудное время с правилом StyleCop SA1503 (CurlyBracketsMustNotBeOmitted).Получение правила StyleCop SA1503 CurlyBracketsMustNotBeДобавлено, чтобы быть более гибким

В моем коде я довольно часто имеют шаблон таким образом:

public void SomeFunction(string someArg) 
{ 
    if (string.IsNullOrEmpty(someArg)) throw new ArgumentNullException("someArg"); 

    // rest of the function here 
} 

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

Однако, я бы никогда записи

if (someConditional) 
    DoSomeStuff(); 

Я всегда пишу

if (someConditional) 
{ 
    DoSomeStuff(); 
} 

Так что в итоге:

  • Используйте фигурные скобки, если если оператор разбит на несколько линий
  • Не используйте фигурные скобки для простой проверки аргументов и т. Д., Которые можно легко (и читаемо) поставить на одну строку

Может ли StyleCop помочь мне здесь?

+0

@Richard E: что вы в конечном итоге сделали? Я не хочу распускать правило, но я хочу написать свои предварительные условия, как описываемый вами образец. –

+0

@Lieven: На данный момент мы оставили это правило и решили использовать фигурные скобки на наших однострочных условиях. С этой целью мы отключили правило StyleCop SA1501. –

+0

OffTopic: не бросайте ArgumentNullException, если переменная пустая строка, вы должны использовать ее только для нулевых параметров. –

ответ

7

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

Способ, которым я использовал StyleCop, - это сосредоточиться на использовании как можно большего числа встроенных правил, и где у меня действительно есть фундаментальная проблема с правилом (например, документация кода), я просто отключу его. Я не слишком озабочен исключениями, чтобы идти в объеме написания пользовательских правил.

+1

полностью согласен; мы обнаружили, что через несколько недель после того, как вы настроились на «просто делаете то, что говорит стиль» и перестаете спорить с ним », отношение привело к многолетнему бесстрастному, высоко читаемому коду. –

3

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

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

+0

Размышление о том, что является хорошей причиной? Я предпочел использовать однострочные операторы if в начале функций в течение длительного времени. ex: 'if (data.empty) return;' Выглядит немного странно, как 3 строки. – basher

+0

@basher Как упоминалось, «это приводит к непоследовательному шаблону использования для операторов if» - является ли это проблемой или нет, является спорным, но это потенциально ценная причина. –

+0

Достаточно справедливо. Спасибо, Рид. – basher