2009-10-01 5 views
0

Я всегда склонен группировать все материалы, принадлежащие имуществу зависимостей (регистрация, свойство clr, изменение обратного вызова, коллинг обратной связи и т. Д.) В один регион. Но это нарушает правила упорядочения членов стиля. Это также общая проблема с кодами, которые генерируют несколько членов, поскольку фрагменты не могут генерировать код в разных местах моего файла. В чем вы философия? Вы раскалываете правила стиля или ставите все в «правильное» место?StyleCop vs DependencyProperties

Кроме того, я лично считаю, что stylcop не должны жаловаться на это:

/// <summary> 
/// RepeatX Dependency Property 
/// </summary> 
public static readonly DependencyProperty RepeatXProperty = 
    DependencyProperty.Register(
     "RepeatX", 
     typeof(int), 
     typeof(GeometryViewbox), 
     new FrameworkPropertyMetadata 
      { 
       DefaultValue = 1, 
       AffectsRender = true, 
       AffectsParentMeasure = true, 
       PropertyChangedCallback = OnRepeatXChanged, 
       CoerceValueCallback = CoerceRepeatXValue 
      }); 

Stylcop должны генерировать Addtional работу для нас, чтобы сделать. В приведенном выше примере придерживание стилескопа делает вас менее продуктивным, а код становится менее читаемым, потому что вы вынуждены помещать вышеуказанный код в статическую ctor (вместо инициализации поля), чтобы сделать FrameworkPropertyMetadata в переменной temp. Одна дополнительная временная переменная для каждого свойства зависимостей не делает код более удобочитаемым/поддерживаемым, и вы больше не можете использовать коды.

ответ

5

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

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

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

+0

+1 для указания свободной воли. –

+1

Конечно, мы не вынуждены использовать stylecp, но я думаю, мы все согласны с тем, что это очень полезно. Особенно, если мы пишем код, открытый или используемый многими членами команды. Существует только одно или другое правило, которое должно работать несколько иначе. Конечно, мы можем отключить правила и написать собственные правила. Но правила по умолчанию существуют для определенной цели. Их можно рассматривать как подсказки для лучших практик. Вот почему было бы неплохо сделать их максимально возможными. – bitbonk

+1

Некоторые из правил по умолчанию также устраняют недостатки в Microsoft diff. Если вы используете другой (не предназначенный для каламбур), то следует ли использовать обновленные правила? Возможно нет. Правила по умолчанию есть, потому что они обеспечивают стиль дома MS. Лучше ли использовать комментарий для стиля Microsoft в верхней части каждого исходного файла? Неа. Это не лучшие советы. Это средство проверки стиля, не более того. Это не FXCop, где они определенно являются правилами лучшей практики. – blowdart

4

Мы склонны вкладывать все, что предлагает Stylecop. Это просто проще. Меньше хлопот. И если вы соблюдаете правила во всех случаях, вы всегда знаете, где искать вещи. Кроме того, вы можете использовать это выпадающее меню, чтобы перейти прямо к объявлениям участников.

FWIW, мы также никогда не используем регионы. Вещи менее загромождали этот путь.

+0

+1 100% согласен! Останавливает бесконечные дискуссии о том, как это делается или так делается. –

+0

+1 Пойдите с тем, что он говорит, это удивительно, как скоро вы начнете писать код, который любит стиль. –

Смежные вопросы