Исследование преимуществ стандартного стиля кодирования
есть несколько вопросов о Stackoverflow о том, есть ли какие-либо исследования или исследования в том, что является лучшим соглашением/стилем кодирования. Вопрос не об этом. Этот вопрос заключается в том, существуют ли какие-либо исследования, которые исследуют, есть ли какие-либо преимущества, повышение производительности или другие положительные побочные эффекты от наличия общеорганизационного соглашения и стиля кодирования.
У меня есть свое мнение по этому поводу, которое в основном заключается в том, что есть огромный преимущества наличия таких стандартов. Честно говоря, мне все равно, какой стиль я должен использовать, если он соответствует всему коду, с которым мне придется работать.
Я просто хочу знать, есть ли какие-либо исследования, которые поддерживают мои мнения или противоречат им.
3 ответов
было несколько исследований, показывающих, что строгое соблюдение последовательного визуального стиля помогает опытным программистам хранить больше локальной проблемы в памяти без необходимости запоминать отдельные элементы проблемы.
Последовательный Стиль Кодирования Помогает Chunking
Это связано с тем, как работает человеческая память. Она называется отрывов. Например, это хорошо изученное явление, которое шахматисты намного лучше запоминание шахматные позиции, чем люди, которые не знакомы с игрой. Но это только в том случае, если фигуры происходят в "естественных позициях", которые могут произойти в обычной игре. Если вы поместите шахматные фигуры в случайных позициях, шахматные мастера не лучше чем не шахматисты на запоминание позиций на доске.
то же самое относится и к программистам. Когда стили кодирования согласованы, конструкции кодирования выглядят "естественными" для программиста и большие части кода легче усваиваются. Наша краткосрочная память имеет емкость около" семи плюс-или-минус два " куска, поэтому, чем больше эти знакомые куски, тем больше сырых данных наш ум может активно удерживать в памяти (Джордж Миллер).
столкнувшись с произвольно отформатированным кодом, программисты должны тратить дополнительную умственную энергию на вручную разобрать отдельные произведения проблемы они работают. Что отнимает у возможность держать большие части проблемы в памяти, чтобы работать над ней. Это также означает, что требуется больше времени, чтобы достичь точки, где программист продуктивно решает проблему.
Поток Времени
вы когда-нибудь находили, что проблема кажется настолько ясной, пока вы продолжаете работать над ней, но затем вы, похоже, "теряете информацию", когда возвращаетесь к проблеме позже; т. е. прерываете свое время потока? Время потока хорошо документировано в Peopleware (обязательный чтение для всех программистов). Время потока-это когда программисты выполняют большую часть работы и достигается только тогда, когда вы работаете над проблемой в течение длительного периода времени. Это происходит потому, что программисту требуется определенный период времени, чтобы усвоить достаточно проблем в когнитивной памяти, чтобы эффективно работать над проблемой. Хорошо отформатированный код помогает нашей визуальной обработке изображений, что означает, что программисты достигают времени потока намного быстрее.
Я автор стандарты кодирования в нескольких программных компаниях. К сожалению, многие программисты считают, что стандарты кодирования-это всего лишь средство утверждения ненужного контроля над тем, как они делают вещи; форма творческой цензуры. По правде говоря, редко имеет значение, каковы фактические стандарты. Ценность в том, чтобы заставить всех в команде быть последовательными, даже если это означает принятие часто произвольного решения между этим мой способ или сделать это код путь.
здесь несколько ссылок я упомянул выше:
наши исследования подтверждают утверждение, что знание планов программирования и правил дискурса программирования может оказать значительное влияние на понимание программы. В своей книге "элементы стиля программирования" Керниган и Плаугер также определяют то, что мы назвали бы правилами дискурса. Наши эмпирические результаты вонзают зубы в эти правила: не только вопрос эстетики в том, что программы должны быть написаны в определенном стиле. А есть психологическая основа для написание программ традиционным способом: программисты возлагают большие надежды на то, что другие программисты будут следовать этим правилам дискурса. Если правила нарушаются, то полезность, обеспечиваемая ожиданиями, которые программисты создали с течением времени, фактически аннулируется. Результаты экспериментов с начинающими и продвинутыми программистами, а также с профессиональными программистами, описанные в настоящей статье, ясно подтверждают эти утверждения.
эмпирическая Изучение знаний программирования. Соловей и Эрлих.
место, где я получил наибольшее представление о проблеме:
стандарты кодирования C++: 101 правила, рекомендации и рекомендации (Саттер, Александреску)
Это стоит прочитать, даже если вы не работаете в C++.