Исследование преимуществ стандартного стиля кодирования

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

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

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


person Fostah    schedule 24.08.2009    source источник
comment
огромные преимущества? Или преимущества? Что вы имеете в виду под огромным? Является ли стандартный стиль более ценным, чем автоматизированное модульное тестирование? Более ценный, чем хороший язык? Более ценный, чем простой, эффективный дизайн?   -  person S.Lott    schedule 25.08.2009
comment
@ S.Lott - просто немного гиперболы. Я сам предпочитаю недосказанность, и люди иногда это тоже неправильно понимают.   -  person pavium    schedule 25.08.2009
comment
Я подозреваю, что вам все равно. Что, если бы стиль кодирования для C включал в себя такие вещи, как отсутствие ненужных пробелов (включая новые строки)? или комментарии из нескольких слов, описывающие использование переменной, должны смешиваться с каждой буквой объявления: например, int t/*height*/a/*of*/l/*character*/l; Это крайние примеры, но я подозреваю, что это преувеличение. :)   -  person William Pursell    schedule 25.08.2009
comment
@S.Lott Это не сравнение различных частей или технологий процесса разработки программного обеспечения. Я придерживаюсь того факта, что я думаю, что это имеет ОГРОМНЫЕ преимущества с точки зрения обслуживания, межкомандной гибкости и возможности понимать чужой код без необходимости тратить время на адаптацию вашего встроенного распознавания образов к незнакомому стилю кодирования.   -  person Fostah    schedule 25.08.2009
comment
@William Pursell «Может быть, все равно» немного силен. Скажем так, в пределах разумного. Вы говорите о крайних случаях, которые никогда не сработают, когда компания в целом намеревается разработать стандартную конвенцию. С учетом сказанного, я думаю, что мне было бы легче адаптироваться к одному плохому соглашению, которое строго соблюдается, чем к сотням отдельных соглашений.   -  person Fostah    schedule 25.08.2009


Ответы (3)


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

Последовательный стиль кодирования помогает разделять на части

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

Та же концепция применима и к программистам. Когда стили кодирования согласованы, конструкции кодирования кажутся программисту естественными, и большие части кода легче усваиваются. Наша кратковременная память имеет емкость около семи плюс-минус два фрагмента, поэтому, чем крупнее эти знакомые фрагменты, тем больше необработанных данных наш разум может активно хранить в памяти (Джордж Миллер).

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

Время потока

Вы когда-нибудь замечали, что проблема кажется такой ясной, пока вы продолжаете над ней работать, но затем вы теряете информацию, когда возвращаетесь к проблеме позже; т.е. сломать ваше время потока? Время потока хорошо задокументировано в Peopleware (обязательно читать всем программистам). Время потока — это когда программисты выполняют большую часть работы, и достигается только тогда, когда вы работаете над проблемой в течение длительного периода времени без перерыва. Это связано с тем, что программисту требуется определенный период времени, чтобы усвоить достаточно проблемы в когнитивной памяти, чтобы эффективно работать над проблемой. Хорошо отформатированный код помогает нашей обработке визуальных изображений, что означает, что программисты намного быстрее достигают времени потока.

Я разработал стандарты кодирования в нескольких компаниях-разработчиках программного обеспечения. К сожалению, многие программисты считают, что стандарты кодирования — это просто средство утверждения ненужного контроля над тем, как они что-то делают; форма творческой цензуры. По правде говоря, фактические стандарты редко имеют значение. Ценность заключается в том, чтобы заставить всех в команде быть последовательными, даже если это означает принятие часто произвольного решения между тем, чтобы делать это моим способом или делать это вашим способом.

Вот несколько ссылок, которые я упомянул выше:

person Robert Cartaino    schedule 25.08.2009
comment
Это отличный ответ, Роберт. Спасибо. Я уверен, что мы все испытали чанкинг. Я знаю, что когда я смотрю на правильно отформатированный код, относительно того, что я считаю правильным, конечно, я могу понять код в целом. Но как только код немного по-другому отформатирован (т. е. фигурная скобка открывается не там, где я ожидаю), способность понять его целиком исчезает, в результате чего мне приходится проходить каждую строку. Разорвать иллюзорный поток — еще один важный момент. - person Fostah; 25.08.2009
comment
По моему опыту, фрагментация имеет тенденцию быть скорее отрицательной, чем положительной, потому что она заставляет программистов делать предположения, основанные на определенных последовательностях, которые являются ложными. Утверждение, что согласованность ведет к лучшему коду, неубедительно и не связано с настоящими двойными слепыми исследованиями. Подтверждение смещения. - person Jim Pedid; 27.06.2017

Наши исследования подтверждают утверждение о том, что знание планов программирования и правил программирования может оказать существенное влияние на понимание программы. В своей книге под названием «Элементы стиля [программирования]» Керниган и Плаугер также определяют то, что мы бы назвали правилами дискурса. Наши эмпирические результаты подтвердили эти правила: программа должна быть написана в определенном стиле не только с эстетической точки зрения. Скорее, существует психологическая основа для написания программ традиционным способом: у программистов есть сильные ожидания, что другие программисты будут следовать этим правилам дискурса. Если правила нарушаются, то полезность ожиданий, которые программисты создавали с течением времени, фактически сводится на нет. Результаты экспериментов с начинающими и продвинутыми студентами-программистами, а также с профессиональными программистами, описанные в этой статье, явно подтверждают эти заявления.

Эмпирические исследования знаний в области программирования. Солоуэй и Эрлих.

person Firas Assaad    schedule 25.08.2009

Место, где я получил наибольшее представление о проблеме:

Стандарты кодирования C++: 101 правило, рекомендации и рекомендации (Саттер, Александреску)

Ее стоит прочитать, даже если вы не работаете с C++.

person Sam Harwell    schedule 25.08.2009