Если вы считаете, что это не так, объясните, почему.
Если да, насколько глубоки должны быть ваши рекомендации? Например, нужно указать отступ кода?
Я думаю, что команда (а не компания) должна согласиться с набором руководящих принципов для разумно последовательного стиля. Это делает его более простым для обслуживания.
Как глубоко? Как мелко, как вы можете договориться. Чем короче и яснее, тем более вероятно, что все члены команды согласятся на это и будут соблюдать это.
Вы хотите, чтобы все читали и записывали код стандартным образом. Это можно сделать двумя способами:
Чем больше вы покидаете undefined, тем выше вероятность того, что один из разработчиков столкнется с стилем.
Компания должна установить, что нужно придерживаться определенного стиля. Какой стиль и насколько глубокие руководящие принципы должны решаться коллективно сообществом разработчиков в компании.
Я бы определенно сформулировал рекомендации по фигурным скобкам, отстукам, именованию и т.д. Вы пишете код для удобочитаемости и ремонтопригодности. Всегда предполагайте, что кто-то еще прочитает ваш код. Есть инструменты, которые будут автоматически настраивать ваш код, и вы можете указать, что каждый использует этот инструмент.
Если вы находитесь на .Net, посмотрите на стиль, fxcop и Resharper
Считаете ли вы, что компания-разработчик программного обеспечения должна навязывать разработчикам стиль кодирования?
Не сверху вниз. Разработчики в компании-разработчике программного обеспечения должны согласовать общий стиль кодирования.
Если да, насколько глубоко должны руководствоваться ваши рекомендации?
Они должны описывать только отличия от известных конвенций, пытаясь сохранить минимальное отклонение. Это легко для языков, таких как Python или Java, несколько размытых для C/С++ и почти невозможных для Perl и Ruby.
Например, необходимо указать отступ кода?
Да, он делает код более читаемым. Сохраняйте отступы согласованными с точки зрения пробелов и вкладок и (если вы выбираете пробелы) количество пробелов. Кроме того, соглашайтесь с краем (например, 76 символов или 120 символов) для длинных строк.
Да, но в пределах разумного.
Все современные IDE предлагают один-кнопочный код довольно-печатный, поэтому точка "отступов", по-моему, не имеет значения.
Что более важно, так это установить лучшие практики: например, используйте как можно меньше параметров "out" или "ref"... В этом примере у вас есть 2 преимущества: улучшает читаемость, а также фиксирует много ошибок (многие параметры являются запахом кода и, вероятно, должны быть рефакторированы).
Идя дальше, по моему честному мнению, немного "анальный" и излишне раздражающий для разработчиков.
Хорошая точка Хэмиш Смит:
Стиль отличается от лучших практики. Это позор, что "кодирование стандарты", как правило, вместе. Если бы люди могли стиль до минимума и сосредоточить внимание на вероятно, добавит больше значения.
Я не считаю, что команда разработчиков должна иметь правила стиля, которым они должны следовать в качестве общего правила. Существуют исключения, например использование < > vs. "" в операторах #include, но эти исключения должны исходить из необходимости.
Наиболее распространенная причина, по которой я слышу, как люди используют объяснения, почему нужны руководящие принципы стиля, заключается в том, что код, написанный в общем стиле, легче поддерживать этот код, написанный в отдельных стилях. Я не согласен. Профессиональный программист не увязнет, когда увидит это:
for( int n = 0; n < 42; ++42 ) {
// blah
}
... когда они используются для этого:
for(int n = 0; n < 42; ++42 )
{
// blah
}
Кроме того, я нашел, что на самом деле проще поддерживать код в некоторых случаях, если вы можете определить программиста, который написал оригинальный код, просто узнав свой стиль. Пойдите, спросите их, почему они осуществили gizmo таким запутанным способом за 10 минут вместо того, чтобы провести большую часть дня, выясняя техническую причину, почему они сделали что-то неожиданное. Правда, программист должен был прокомментировать код, чтобы объяснить свои рассуждения, но в реальном мире программисты часто этого не делают.
Наконец, если он займет 10 минут назад и переместит фигурные фигурные скобки, чтобы Билл мог потратить 3 секунды на просмотр кода, действительно ли это сэкономило время, чтобы заставить Билла сделать что-то, что не пришло ему в голову?
Я считаю, что важно иметь последовательную кодовую базу. Это увеличивает ремонтопригодность кода ur. Если каждый ожидает такой же код, он может легко его прочитать и понять.
Кроме того, это не так много проблем, связанных с современными IDE и их возможностями автоформатирования.
P.S: У меня есть эта досадная привычка поместить мои фигурные скобки на следующую строку:). Никому больше не нравится это
Я думаю, что программисты должны уметь адаптироваться к стилю других программистов. Если новый программист неспособен адаптироваться, это обычно означает, что новый программист слишком упрям, чтобы использовать стиль компании. Было бы хорошо, если бы мы все могли сделать свое дело; однако, если мы все кодируем некоторые рекомендации, это облегчает отладку и обслуживание. Это справедливо только в том случае, если стандарт хорошо продуман и не слишком ограничительный.
Пока я не согласен со всем, эта книга содержит отличную отправную точку для стандартов
Лучшим решением для IDE было бы рассмотреть такое форматирование, как метаданные. Например, открытие фигурной скобки (текущая строка или следующая строка), отступы и пробелы вокруг операторов должны быть настраиваемыми без изменения исходного файла.
По-моему, я считаю, что это крайне необходимо для стандартов и руководств по стилю. Потому что, когда ваша кодовая база растет, вы захотите ее согласовать.
В качестве побочного примечания, поэтому я люблю Python; потому что он уже накладывает довольно много правил о том, как структурировать ваши приложения и т.д. Сравните это с Perl, Ruby или тем, где у вас есть крайняя свобода (что в данном случае не так уж и хорошо).
Существует множество веских оснований для того, чтобы стандарты определяли способ разработки приложений и способ, которым должен выглядеть код. Например, когда все используют один и тот же стандарт, автоматическая проверка стиля может использоваться как часть проекта CI. Использование тех же стандартов улучшает читаемость кода и помогает уменьшить напряженность между членами команды в отношении повторного факторинга одного и того же кода по-разному. Поэтому:
В аутсорсинговой компании может быть сделано исключение для команды, работающей для клиента, если клиент хочет обеспечить соблюдение собственного стандарта. В этом случае команда принимает стандарт клиента, который может быть несовместим с тем, который используется их компанией.
Как и многие другие, я думаю, что это должно быть инженерами или командой - компания (т.е. бизнес-единицы) не должна участвовать в таком решении.
Но еще одна вещь, которую я бы добавил, - это любые правила, которые должны быть реализованы инструментами, а не людьми. В худшем случае, ИМО, есть какой-то чрезмерно усердный грамматический сноб (да, мы существуем, я знаю, потому что мы можем чувствовать себя как собственный) пишет некоторую документацию, в которой излагается набор правил кодирования, которые абсолютно никто не читает или не следует. С течением времени они устаревают, и, когда в команду добавляются новые люди, а старые люди уходят, они просто становятся устаревшими.
Затем возникает некоторый конфликт, и кто-то оказывается в неудобном положении, когда ему приходится сталкиваться с кем-то другим по поводу стиля кодирования - такого рода конфронтация должна быть сделана инструментами, а не людьми. Короче говоря, этот метод принуждения является наименее желательным, на мой взгляд, потому что его слишком легко игнорировать и просто умоляет программистов спорить о глупости.
Лучшая опция (опять же, IMO) заключается в том, чтобы предупреждения отображались во время компиляции (или что-то подобное), если ваша среда сборки поддерживает это. Это не сложно настроить в VS.NET, но я не знаю других сред разработки, которые имеют схожие функции.
Руководства по стилю чрезвычайно важны, независимо от того, предназначены ли они для разработки или разработки, потому что они ускоряют общение и производительность людей, которые работают совместно (или даже в одиночку, последовательно, как при наборе частей старого проекта). Не имея системы соглашения внутри компании, просто просят людей быть такими же непродуктивными, как они могут. Большинство проектов требуют сотрудничества, и даже те, кто этого не делает, могут быть уязвимы для нашего естественного желания выполнять наши программные отбивные и поддерживать актуальность. Наше стремление учиться мешает нашей последовательности - это само по себе само по себе, но может заставить нового сотрудника сходить с ума, пытаясь изучить системы, в которые они вскакивают.
Как и любая другая система, которая предназначена для добра, а не для зла, реальная сила проводника лежит в руках его людей. Сами разработчики будут определять, какие основные и полезные части есть, а затем, надеюсь, их использовать.
Как и закон. Или английский язык.
Руководства по стилям должны быть такими же глубокими, какими они хотят быть - если это происходит в сеансе мозгового штурма, оно должно быть включено. Странно, как вы сформулировали вопрос, потому что в конце дня невозможно "навязать" руководство по стилю, потому что это только РУКОВОДСТВО.
RTFM, затем подберите хороший материал и продолжите его.
Да, думаю, компании должны. Разработчику, возможно, придется привыкнуть к стилю кодирования, но, на мой взгляд, хороший программист должен иметь возможность работать с любым стилем кодирования. Как сказал Мидхат: Важно иметь последовательную кодовую базу.
Я думаю, что это также важно для проектов с открытым исходным кодом, нет супервизора, чтобы рассказать вам, как писать свой код, но на многих языках есть спецификации того, как должно быть указано имя и организация вашего кода. Это очень помогает при интеграции компонентов open source в ваш проект.
Конечно, рекомендации хороши, и если это плохо используемое венгерское обозначение (ha!), это, вероятно, улучшит согласованность и упростит чтение других людей. Руководящие принципы должны быть только руководящими принципами, но не строгие правила, применяемые к программистам. Вы могли бы рассказать мне, где поставить фигурные скобки или не использовать имена типа temp, но то, что вы не можете сделать, это заставить меня иметь пробелы вокруг значений индекса в скобках массива (они пытались один раз...)
Да.
Стандарты кодирования - это общий способ обеспечения того, чтобы код внутри определенной организации выполнял Принцип наименьшего удивления: согласованность стандартов, начиная от переменной именования до отступов до фигурного скобки.
Кодеры, имеющие свои собственные стили и собственные стандарты, будут создавать кодовую базу, которая несовместима, запутанна и расстраивает чтение, особенно в крупных проектах.
Эти являются стандартами кодирования для компании, для которой я работал. Они хорошо определены, и, хотя мне потребовалось некоторое время, чтобы привыкнуть к ним, это означало, что код был удобочитаемым всеми нами и был равномерным на всем протяжении.
Я считаю, что стандарты кодирования важны внутри компании, если они не установлены, между разработчиками будут возникать конфликты и проблемы с читабельностью.
Наличие единой формы кода обеспечивает лучший код для конечного пользователя (поэтому он выглядит так, как будто он написан одним человеком - который, с точки зрения конечных пользователей, должен - это лицо, являющееся "компанией" "и это также помогает с удобочитаемостью в команде...
Обычный стиль кодирования способствует согласованности и облегчает для разных людей легко понимать, поддерживать и расширять всю базу кода, а не только их собственные части. Это также облегчает для новых людей более быстрый поиск кода. Таким образом, любая команда должна иметь рекомендации по написанию кода.
Важные рекомендации включают (в определенном порядке):
Кроме того, будьте осторожны с программистами, которые не могут или не будут адаптироваться к стилю команды, какими бы яркими они ни были. Если они не играют по одному из правил команды, они, вероятно, также не будут играть по другим командам.
Я бы согласился с тем, что последовательность является ключевой. Вы не можете полагаться на довольно печатную печать IDE, чтобы сохранить этот день, потому что некоторым из ваших разработчиков может не нравиться использование среды IDE, и потому что, когда вы тратитесь через базу кода из тысяч исходных файлов, это просто не представляется возможным распечатывайте все файлы, когда вы начинаете работать над ними, и выполняйте откат после этого, чтобы ваш VCS не пытался зафиксировать все изменения (забирая репозиторий ненужными обновлениями, которые обременяют всех).
Я бы предложил стандартизировать, по крайней мере, следующее (в порядке убывания важности):
Мое мнение:
Современные IDE позволяют определить шаблон форматирования. Если есть корпоративный стандарт, то создайте файл конфигурации, который определяет все значения форматирования, о которых вы заботитесь, и убедитесь, что каждый запускает форматировщик, прежде чем проверять свой код. Если вы хотите быть более строгим в этом вопросе, вы можете добавить крючок фиксации для вашей системы управления версиями, чтобы отступать код до его принятия.
Да с точки зрения использования общего стандарта именования, а также общий макет классов и кода за файлами. Все остальное открыто.
Каждая компания должна. Согласованный стиль кодирования обеспечивает более высокую степень удобочитаемости и поддерживаемости кодовой базы всей вашей команды.
В магазине, в котором я работаю, нет единого стандарта кодирования, и я могу сказать, что мы (как команда) сильно страдают от этого. Когда от людей нет воли (например, в случае некоторых моих коллег), руководитель команды должен ударить кулаком по столу и навязать некоторые формы стандартизованных правил кодирования.
Язык на всех языках имеет общие стандарты, которые используются сообществом. Вы должны следовать за ними, насколько это возможно, чтобы ваш код мог поддерживаться другими людьми, используемыми на этом языке, но там не нужно быть диктаторским.
Создание официального стандарта неверно, потому что стандарт кодирования компании обычно является слишком жестким и не может протекать с общим сообществом с использованием языка.
Если у вас возникла проблема с членом команды, действительно присутствующим в стиле кодирования, то отличная идея для группы, которую следует мягко предложить, не является хорошей идеей при просмотре кода.
Стандарты кодирования: ДА. По причинам, уже затронутым в этой теме.
Стандарты стилизации: НЕТ. Ваш читаемый, мой сбивающий с толку барахло, и наоборот. Хороший комментарий и кодовый факторинг имеют гораздо большую выгоду. Также gnu indent.
Мне нравится ответ Илья, потому что он включает в себя важность читаемости и использование непрерывной интеграции в качестве механизма обеспечения соблюдения. Хибри упомянул FxCop, и я думаю, что его использование в процессе сборки в качестве одного из критериев для определения того, будет ли сборка или неудача сборки более гибкой и эффективной, чем просто документирование стандарта.
Я полностью согласен с тем, что стандарты кодирования должны применяться, и что он должен почти всегда находиться на уровне команды. Однако есть несколько исключений.
Если команда пишет код, который должен использоваться другими командами (и здесь я имею в виду, что другим командам придется смотреть на источник, а не просто использовать его в качестве библиотеки), тогда есть преимущества для создания общих стандартов в все команды используют его. Аналогичным образом, если политика компании заключается в том, чтобы часто перемещать программистов из одной команды в другую или находится в положении, когда одна команда часто хочет повторно использовать код из другой команды, тогда, вероятно, лучше всего навязывать стандарты всей компании.
Существует два типа условных обозначений.
Соглашения типа A: "пожалуйста, сделайте это, это лучше"
и типа B: "пожалуйста, двигайтесь по правой стороне дороги", в то время как с другой стороны все в порядке, пока все делают то же самое.
Нет такой вещи, как отдельная команда. Весь код в хорошей фирме каким-то образом связан, и стиль должен быть последовательным. Легче привыкнуть к одному новому стилю, чем к 20 различным стилям.
Кроме того, новый разработчик должен уметь уважать практику существующей кодовой базы и следить за ней.