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

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

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

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

ОТВЕТЫ

Ответ 1

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

Согласование стиля кодирования с привязкой

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

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

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

Время потока

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

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

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

Ответ 2

Наши исследования подтверждают утверждение о том, что знание планов программирования и правил программирования может оказать существенное влияние на понимание программ. В своей книге под названием [The] Elements of [Programming] Style, Kernighan и Plauger также определяют то, что мы будем называть правилами дискурса. Наши эмпирические результаты вносят зубы в эти правила: не просто вопрос эстетики, что программы должны быть написаны в определенном стиле. Скорее, существует психологическая основа для написания программ обычным образом: у программистов есть большие надежды, что другие программисты будут следовать этим правилам дискурса. Если правила нарушены, то полезность, обеспечиваемая ожиданиями, которые программисты создали с течением времени, фактически аннулируется. Результаты экспериментов с новичками и продвинутыми студенческими программистами и с профессиональными программистами, описанными в этом документе, обеспечивают четкую поддержку этих заявлений.

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