Как бороться с конфликтующими соглашениями о кодировании?

Question

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

Например, если мы используем переменные класса, StyleCop предложит нам использовать

this.Name = myName

вместо

Name = myName

Но при этом появится ошибка Resharper, «Избыточный квалификатор» и предложит не использовать «this».нотация.

Таким образом, в таких сценариях мне нужно проверить более последовательную ссылку, чтобы выбрать, что является правильным / Лучшим.Есть ли такой ресурс, который «определяет» правильные соглашения?

Answer 1

Не существует правильного соглашения, вы принимаете тот, который предпочитаете, и это ваш базовый уровень / ссылка.

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

Answer 2

Это субъективный вопрос, поэтому вот мой субъективный ответ: я согласен с Решарпером и считаю, что this является излишним. Лично я префикс имени поля с подчеркиванием:

public class Foo
{
    private readonly string _name;

    public Foo(string name)
    {
        _name = name;
    }
}

Затем я настраиваю инструменты статического анализа в соответствии с принятыми мною соглашениями.

Answer 3

Мне нужно проверить более последовательную ссылку, чтобы выбрать, что является правильным / Лучшим.Есть ли такой ресурс, который «определяет» правильные соглашения?

На эти вопросы невозможно ответить.Ссылки не могут помочь вам "выбрать то, что правильно".А условные обозначения по своей природе не обладают свойством «правильности» - мы используем условные обозначения для произвольного решения последовательного подхода к тем вопросам, на которые не имеют правильного ответа.

Если вы хотитеследуя указаниям StyleCop здесь, вы можете настроить ReSharper, чтобы он не жаловался на использование this.Это в ReSharper | Options | Code Inspection | Inspection Severity - или, я полагаю, есть специальный плагин 'StyleCop for ReSharper', который будет обрабатывать это для вас.

Answer 4

Я думаю, что использование FxCop более полезно, поскольку оно предоставляется Microsoft, так что может быть более аутентичным, чем Microsoft.http://msdn.microsoft.com/en-us/library/bb429476(v=vs.80).aspx

Answer 5

Различные инструменты предлагают разные вещи. Я бы предложил создать свой собственный документ с руководящими принципами кодирования и поделиться им со своей командой (начните с существующего соглашения о кодировании). Хорошей отправной точкой, однако, является книга «Руководство по проектированию рамок» ISBN: 978-0321545619

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

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

В любом случае они больше похожи на ориентиры;).