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

Разработчик пишет if/elseблоки с однострочными кодами, например:

if (condition)
   // Do this one-line code
else
   // Do this one-line code

Другой использует фигурные скобки для всех из них:

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

Разработчик сначала создает объект, а затем использует его:

HelperClass helper = new HelperClass();
helper.DoSomething();

Другой разработчик создает и использует объект в одной строке:

new HelperClass().DoSomething();

Разработчику проще с массивами и forциклами:

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

Другой пишет:

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

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

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

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

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

Опять же, то, что стандарты, не так важны, как наличие какого-то простого, простого стандарта. Итак, поместите всех ваших разработчиков в комнату и позвольте им спорить о том, какими должны быть стандарты. Эта встреча может продолжаться бесконечно, поэтому правила таковы:

• Все, что не решено к концу встречи, будет решать менеджер.
• Встреча заканчивается через два часа, или когда кто-то начинает кричать или плакать, в зависимости от того, что наступит раньше.
• Весь стандарт поместится (при разумном размере шрифта!) На листе или двух листах бумаги, двусторонний только в случае крайней необходимости.

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

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

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

Примечание. Идея «стандартов кодирования» не уникальна для программирования. «Стандарты кодирования» используются во многих областях, иногда внутри организации, чаще всего в рамках всей отрасли или профессии. Несколько примеров:

• Юридические документы, такие как судебные документы и стенограммы, придерживаются определенных форматов.
• Сценарии и сценарии должны быть написаны в определенном стиле, чтобы к ним относились серьезно.
• Технические чертежи часто должны иметь заголовок в стандартной форме.
• Бибилографические форматы стандартизированы.

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

Стиль не имеет значения.

Там я это сказал.

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

Получите это на работу, в первую очередь.

Заставьте его использовать оптимальный объем ресурсов (т. Е. Правильную структуру данных, правильный алгоритм).

Суета над "стилем" после того, как все остальное было решено. Суета "стиля" только с инструментами, а не вручную.

Есть стили кодирования и есть запахи кодирования. Это был не один раз, что я нашел:

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

Мой предыдущий работодатель строго запрещал использование мультилинии if()без скобок. Это считалось ошибкой типа «сделай это снова, и тебя уволят». Разрешенные конструкции были

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

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

Есть вещи, которые вы просто должны всегда делать. Нравится switch():

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

Тем временем набираю:

     case 1:
         something();
     case 2:
         something();
     break;

без закрытия caseс //fallthroughсчитается ошибкой.

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

Создайте согласованность с хорошим предварительным дизайном. То, что вы описываете в вопросе, есть не что иное, как микроуправление. Я много занимаюсь веб-разработкой. Поэтому я поддерживаю разработку RESTful и CRUD в виде сервисов. Это обеспечивает простые, четко определенные объекты, которые можно использовать различными способами.

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

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

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

ИМХО это зависит ...

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

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(без скобок) = более подвержен ошибкам, если позже будет добавлено больше кода:

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

И это менее удобно для отладки:

new HelperClass().DoSomething(GetSomeData()); // etc.

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

Что касается вашего третьего примера (для foreach), я считаю это делом вкуса.

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

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

Используйте стандартный инструмент для рисования (очевидно, FxCop для C #). Хотя это не конец всего, все-, последовательность является важным в крупных проектах , которые имеют целый ряд людей , работающих на них.

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

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

Обеспечение единого стиля кодирования всегда сложно. В идеале такую ​​обычную задачу следует оставить на усмотрение инструмента. Я приветствую языковое сообщество Go за это.

Это смесь обоих. Тот факт, что это стандарт, не делает его читабельным и понятным. Если еще не внедрен стандарт, или если в нем есть ошибочные и нечитаемые аспекты, пересмотр уместен.

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

Полезно дать программистам НЕКОТОРЫЕ рекомендации по стилю. Это можно / нужно сделать до того, как программисты приступят к работе, особенно если они являются относительными новичками в среде или в самом программировании. Учитывая это, некоторые программисты будут очень стеснительны, другие менее. Руководство, данное в начале проекта, поможет первой группе программистов, тем самым облегчая общую задачу. Это может мало что сделать для второй группы, которая (будем надеяться) восполнит творческий потенциал, чего им не хватает в соответствии.

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

if() {}
else() {}

Или даже:

if() {} else () {}

Но одной строкой if не следует использовать интервал мультилинии if. Это просто, как я делаю вещи. Я не против того, как объект вызывается, и это зависит от того, сколько раз он вызывается. если его вызывают несколько раз, то я скорее запускаю объект и зависит, есть ли у него конструкторы, а что нет. Потому что, если у вас есть конструктор и вы вызываете:

Object.method();
Object.method2();

Затем вы в итоге дважды вызываете метод constructor объекта, когда этого можно было бы избежать, полностью создав экземпляр объекта.

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

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

После работы с кодом других членов команды, иногда в течение нескольких месяцев, он, по сути, начинает работать в строке git blame. Пробыв в моей компании более 10 лет, я, вероятно, могу сказать вам с точностью до 80%, кто написал какой-либо данный класс где-нибудь в наших 500-тысячных строках кода, просто взглянув на него.

Несмотря на то, что время, когда вы начинаете смотреть на код, использующий стиль, с которым вы не согласны, незначительно, «то, что вы действительно делаете в это время, говорит:« О, это похоже на код Джона Доу (потому что он использует стиль X, но не стиль Y и т. д.) ". И это приносит с собой целую кучу контекста. В первом приближении вы знаете, чего ожидать от кода Джона - какие другие части кодовой базы он хорошо понимает, а какие - нет, будь то гуру SQL или новичок в GUI и т. Д. И т. Д. И т. Д.

Выполнение кода каждого через средство форматирования, по существу, удаляет эту информацию, скрывая ее за git blame, что вы можете не потрудиться запустить.

Это действительно зависит от типа организации.

Если вы небольшая группа супергероев, тогда подойдет любой тип стиля. Если у каждого свой стиль, и он хорош и внутренне непротиворечив, то это все, что вам нужно. Супергерои скажут: «У Джейн есть квадратные скобки, так что это то, что она имеет в виду» или «Джек использует camelCase для переменных».

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

Многие из вас, кстати, "Но подождите, почему бы не покончить с игроками B и C?"

Реальность такова, что не так много супергероев. Несмотря на то, что он может заплатить, чтобы найти и вырастить их в Google, внедрение новой биллинговой системы для Ma Bell может оказаться более экономичным с последней командой. (И если у вас действительно есть Супергерои, 4 или 5 из них будут в два раза дороже дюжины юниоров)