Стиль кодирования: как улучшить стили и стандарты кодирования в компании - PullRequest
13 голосов
/ 22 сентября 2009

Каковы наилучшие способы улучшения стандартов стиля кодирования в компании? Давайте использовать C # в качестве примера здесь.

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

Как можно оправдать, что что-то правильно над чем-то другим?

Один человек может сказать: " Я перемещаю свое тело в то место, где я зарабатываю деньги на своем 4-колесном транспортном средстве ". Так почему же «правильнее» говорить: « Я еду на машине в мою машину »?

Некоторым людям может понравиться более явный код с большим количеством строк кода. Кому-то может понравиться более жесткий код.

// Explicit
string text = defaultValue;
if (string.IsNullOrEmpty(text)) {
   text = fallbackValue;
}
// Tighter
string text = defaultValue ?? fallbackValue;

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

public string ChangeText(string text)
{
    if (!string.IsNullOrEmpty(text))
    {
        // Do a lot of stuff 
    }
    else {
        throw new Exception();
    }
}
// vs.
public string ChangeText(string text)
{
    if (string.IsNullOrEmpty(text)) {
        throw new Exception();
    }
    // Do a lot of stuff
}

Допустимо ли здесь старое "У меня проблемы с чтением этого кода"? Это та же самая ситуация, когда Generics была представлена ​​в C #, у людей возникли проблемы с ее чтением.

Где проходит граница между нечитаемым кодом и кодом, к которому некоторые разработчики не привыкли?

Какая часть из Phil Haacks " 7 Этапы горя нового ключевого слова " имеет здесь действительные баллы?

Существуют ли простые способы установить стандарты кодирования и поддержать их в компании?

ОБНОВЛЕНИЕ : Учитывайте такие вещи, как именование переменных , которые не могут быть определены в документе. Или это может?

Ответы [ 7 ]

6 голосов
/ 22 сентября 2009

Самый простой способ установить стандарты кодирования в компании:

Создать документ по стандартам и обеспечить его соблюдение.

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

5 голосов
/ 22 сентября 2009

Вы всегда можете использовать бесплатные инструменты, такие как StyleCop от Microsoft.

Вы можете отключить или изменить правила, которые вам не нравятся

4 голосов
/ 22 сентября 2009

Существует две основные стороны стиля кодирования:

  1. "Куда мне положить открывающую скобку?" проблемы с типами - обычно они не важны, т. е. нет реальных причин предпочитать один стиль другому.
  2. Актуальные правила кодирования, как если бы мы использовали возврат в середине функции.

На мой взгляд, для проблем типа 1 нет никакого смысла в спорах. Просто установите стандарт в документе стандартов и применяйте его (подробнее об этом позже).

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

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

Например, даже будучи совершенно новым Java-программистом, я знал, когда мои идентификаторы должны быть в верхнем и нижнем регистре просто потому, что Eclipse позволил мне (тихо, незаметно) узнать, что такое стандарт.

3 голосов
/ 22 сентября 2009

Во-первых, вам всегда придется применять стили кодирования - согласия никогда не будет.
Вот почему я бы попытался автоматизировать проверку на согласованность. В зависимости от вашего языка вы можете использовать StyleCop (для .Net) или что-то вроде indent под linux.

Каждый разработчик может работать со своим собственным стилем кода в своей среде (переформатирование может быть очень простым, в зависимости от вашей среды), но весь проверенный код должен быть в стиле компании.

Какой стиль вы выбираете? Ну, часто уже есть популярные стили - в зависимости от языка. Для вашего примера (C #) я бы выбрал стиль Microsoft. Напоследок: только менеджер проекта (старший программист) имеет право настраивать его.

1 голос
/ 22 сентября 2009

Как можно оправдать, что что-то прямо над чем-то другим?

Легко: просто не надо. Выберите стиль кодирования, сообщите ему и применяйте его.

1 голос
/ 22 сентября 2009

Большинство компаний используют Coding-Style-Guidelines / Conventions. Это документы, в которых говорится, что вы всегда должны заключать в скобки тело if даже для одной команды, делать отступы для символов табуляции / пробелов и т. Д.

Существует множество инструментов для (автоматической) проверки и применения стиля кодирования. (Примером для java-мира является checkstyle, который можно интегрировать в eclipse, а также в решение для непрерывной интеграции, такое как 'hudson'.)

0 голосов
/ 22 сентября 2009

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

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

...