Stackoverflow には、最適なコーディング規則/スタイルに関する調査や研究があるかどうかについて、いくつかの質問があります。それはこの質問の目的ではありません。この質問は、組織全体のコーディング規則とスタイルを持つことに利点、生産性の向上、またはその他のプラスの副作用があるかどうかを調査する研究があるかどうかに関するものです。
私はこれについて私自身の意見を持っています。それは基本的に、そのような基準を整備することには大きな利点があるということです. 正直なところ、使用する必要のあるすべてのコードで一貫している限り、どのスタイルを使用する必要があるかはあまり気にしませんでした。
私の意見を支持する、またはそれらと矛盾する研究があるかどうかを知りたいだけです.
一貫したビジュアル スタイルを厳密に順守することで、経験豊富なプログラマーが問題の個々の要素を記憶する必要なく、局所的な問題をより多く記憶しておくことができることを示すいくつかの研究があります。
それは、人間の記憶の仕組みに関係しています。これはチャンキングと呼ばれます。たとえば、よく研究されている現象として、チェスの達人はチェスに慣れていない人よりもチェスの位置を覚えるのが得意です。ただし、それは駒が通常のゲームで発生する可能性のある「自然な位置」にある場合に限られます。チェスの駒をランダムな位置に配置した場合、チェスの達人は、ボードの位置を記憶する点で非チェス プレイヤーよりも優れているわけではありません。
同じ概念がプログラマーにも当てはまります。コーディング スタイルが一貫している場合、コーディング構造はプログラマーにとって「自然」に見え、コードの大部分が理解しやすくなります。私たちの短期記憶は、約「7 プラスマイナス 2」のチャンクの容量を持っているため、これらの使い慣れたチャンクが大きいほど、私たちの心はより多くの生データをアクティブにメモリに保持できます ( George Miller )。
ランダムにフォーマットされたコードに直面すると、プログラマーは、取り組んでいる問題の個々の部分を手動で解析するために、精神的なエネルギーをさらに費やす必要があります。これにより、問題のより大きな部分をメモリに保持して作業する能力が失われます。また、プログラマーが目の前の問題を生産的に解決できるようになるまでに時間がかかることも意味します。
作業を続けている間は問題が非常に明確に見えても、後でその問題に戻ったときに「情報を失っている」ように見えることに気付いたことはありませんか? すなわち、あなたの流れの時間を破る？フロー時間については、Peoplewareで十分に文書化されています (すべてのプログラマーが読む必要があります)。フロー時間とは、プログラマーが大部分の作業を完了する時間であり、中断されることなく長時間にわたって問題に取り組んでいる場合にのみ達成されます。これは、プログラマーが問題に効果的に取り組むのに十分な量の問題を認知記憶に同化するには、一定の時間がかかるためです。適切にフォーマットされたコードは視覚的な画像処理に役立ちます。つまり、プログラマーはフロー時間にはるかに早く到達できます。
私はいくつかのソフトウェア会社でコーディング標準を作成しました。残念なことに、コーディング標準は自分たちのやり方を不必要に制御するための手段に過ぎないと感じているプログラマーがどれだけ多いかは残念です。クリエイティブ検閲の一形態。正直なところ、実際の基準が何であるかが問題になることはめったにありません。価値があるのは、チームの全員が一貫性を保てるようにすることです。たとえそれが、自分のやり方で行うか、自分のやり方で行うかの間でしばしば恣意的な決定を下すことを意味するとしてもです。
ここで私が上で述べたいくつかの参照があります:
私たちの研究は、プログラミング計画とプログラミング言説のルールに関する知識がプログラムの理解に大きな影響を与える可能性があるという主張を支持しています。[The] Elements of [Programming] Style という本で、Kernighan と Plauger は、私たちが言説規則と呼ぶものを特定しています。私たちの経験的な結果は、これらのルールに歯を入れます: プログラムが特定のスタイルで書かれるべきであるということは、単なる美学の問題ではありません。むしろ、従来の方法でプログラムを書くことには心理的な根拠があります。プログラマーは、他のプログラマーがこれらの談話規則に従うことを強く期待しています。ルールに違反すると、プログラマーが時間をかけて築き上げてきた期待によってもたらされる効用が事実上無効になります。
この問題について私が最も洞察を得た場所：
C++ コーディング標準: 101 のルール、ガイドライン、ベスト プラクティス(Sutter、Alexandrescu)
C++ を使用していない場合でも、読む価値があります。