コーディングスタイルの原則に関する科学的に厳密な研究はありますか？[閉まっている]

コーディングスタイルの原則（たとえば、単一出口の原則）は本当に良いことですか？常にですか、それとも時々ですか？それは実際にどのくらい違いますか？

あなたの意見がどうであれ、これらは明らかに主観的な質問です。それとも彼らですか？

コーディングスタイルの原則について客観的で科学的に厳密な研究を試みた人はいますか？

誰がどのように読みやすさの二重盲検研究を行うか想像できませんが、おそらく二重無知が可能かもしれません-被験者として研究されている原則を知らない学生と、研究を管理する非プログラマーを使用してください。

deadalnixのコメントをエコーし​​ています：Code Complete 2を読んでください。著者（Steve McConnell）は、コーディングスタイルについて詳細に議論し、論文やデータの参照を頻繁に行っています。

客観的な結果をもたらす主題の研究の可能性を非常に疑っており、説得力のある研究が示されるまで私は懐疑的なままです。

特定のコーディングスタイルに従ったコードを読み書きするのに何年も費やしたプログラマーは、人生で初めて見た完璧なコーディングスタイルよりも明らかに読みやすいと感じるでしょう。

最も一般的なQWERTYのタイピングレイアウトとまったく同じです-人間工学の点で非常に最適でないことを証明するのは簡単です（単語TYPEWRITERのすべての文字が私たちの日常の利便性を念頭に置いて最上行に置かれたと思いますか？） 。

しかし、ドヴォルザークやコレマクなどの改善された代替案は決して流行りません。そのため、人々は彼らとの生産性を高めていません -事実。たとえ抽象的な意味で優れていても。

また、事前にプログラミングにさらされていない被験者を見つけることは困難です（これは私たちの研究の結果を汚染するため）、しかしプログラミングの適性、そして両方を短時間で示すために十分な期間研究に参加する意志相互に重みを付けることができるように、時間の利点と長期の利点...（それらが相互に排他的であるかどうかはわかりませんが、研究者は単純にそれらが決して絶対ではないと仮定できませんでした）

答えは決定的なNOです！「ブレーク」と「継続」は悪いプログラミング慣行ですか？はこの質問のサブセットであるため、それに対するかろうじて修正された答えから始めます...

breakステートメント（または同じことをするループの途中から戻る）なしでプログラムを[再]作成できます。しかし、そうすることで、追加の変数やコードの重複を導入する必要があり、どちらも通常はプログラムを理解しにくくします。パスカル（1960年代後半のプログラミング言語）は、特に初心者プログラマーにとって非常に悪いものでした。

コサラジュの制御構造の階層と呼ばれるコンピューターサイエンスの結果があります。これは、1973年に遡り、1974年のKnuthの有名な論文Structured programming with go toステートメントに記載されています。深さnのマルチレベルブレークがあるすべてのプログラムを、追加の変数を導入せずに、ブレーク深度がn未満のプログラムに書き換えることができます。しかし、それは単なる理論上の結果だとしましょう。（追加の変数をいくつか追加するだけです！確かに、stackexchangeで3K以上のユーザーとグループ内であると感じることができます...）

ソフトウェアエンジニアリングの観点からはるかに重要なのは、1995年のEric S. Robertsによる最近の「ループ出口と構造化プログラミング：討論の再開（doi：10.1145 / 199688.199815）」という論文です。ロバーツは、彼の前に他の人によって行われたいくつかの実証研究を要約しています。たとえば、CS101タイプの学生のグループに、配列で順次検索を実装する関数のコードを書くように依頼した場合、調査の著者は、ブレークからの復帰を使用して順次から終了する学生について次のように述べました要素が見つかったときの検索ループ：

間違った解決策を生み出した[このスタイル]を使ってプログラムを試みた人をまだ見つけていません。

ロバーツは次のようにも言っています。

forループからの明示的な戻り値を使用せずに問題を解決しようとした学生の方がはるかにうまくいきませんでした。この戦略を試みた42人の学生のうち、正しいソリューションを生成できたのは7人だけでした。その数字は、20％未満の成功率を表しています。

はい、CS101の学生よりも経験が豊富かもしれませんが、breakステートメント（または同等にループの途中からreturn / goto）を使用しなければ、最終的には、名目上はうまく構造化されていても、追加のロジックに関しては十分に毛深いコードを書くことになります変数とコードの複製。誰かが、おそらく自分自身が、「正しい」コーディングスタイルという一般的なアイデアを追求しようとしているときに、その中に論理的なバグを入れます。

ここには、return / break-typeステートメントのほかに1つの大きな問題があるため、この質問はbreakの問題よりも少し広範です。例外処理メカニズムは、いくつかの方法に従って、単一出口ポイントのパラダイムに違反しています

• http://msmvps.com/blogs/peterritchie/archive/2008/03/07/single-entry-single-exit-should-it-still-be-applicable-in-object-oriented-languages.aspx
• http://pragprog.com/magazines/2012-04/the-pragmatic-defense

そのため、基本的には、この最後のリンクで説明されている非常に厳密な方法で使用されない限り、単一出口の原則が今日でも有用であると上記の誰もが例外処理パラダイムに反対しています。これらのガイドラインは基本的に、関数からのすべての例外をthrow（）に制限します。つまり、関数間の例外の伝播はまったく許可されません。C ++のような構文で新しいPascalをお楽しみください。

私から見るの概念「1・リターンのみ」どこから来ましたの？このサイトでの一般的な意見はここに投稿したものとは反対であるため、質問が求めたものを実際に提供する最初の回答であるにもかかわらず、私はなぜすでに投票されたのかを完全に理解しています：実際のユーザビリティテストに関するいくつかの情報は、単一出口の問題に焦点を当てています。特にゲーミフィケーションサイトでは、知識を先入観の邪魔にすべきではないと思います。これからもウィキペディアの編集に固執するつもりです。少なくとも、良い情報源からの情報は高く評価され、情報源に裏付けられたふりをした曖昧または誤った主張は最終的に禁止を獲得します。このサイトでは、まったく逆のことが起こります。事実に裏付けられていない意見が支配的です。私はMODがこの最後の部分を削除することを完全に期待していますが、少なくともその男はあなたがここで貢献者として永遠に私を失った理由を知っています。

http://dl.acm.org/citation.cfm?id=1241526

http://www.springerlink.com/content/n82qpt83n8735l7t/

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=661092

[あなたの質問は、「はい」という一言で答えられるようです。しかし、短い答えを提供することは質問を「却下する」と言われました。却下されたと感じたら、回答にフラグを立てて、モデレーターが削除できるようにしてください。]

コーディングスタイルの原則です。たとえば、単一出口の原則です。

1つの出口か複数の出口かを考えている人々は、まだ1960年代後半に立ち往生しています。当時、このような議論は構造化プログラマーの初期段階にあったため重要であり、Bohm-Jacopini構造化プログラム定理の背後にある発見はすべてのプログラミング構造に普遍的に適用できるわけではないことを宣言する多くのキャンプがありました。

それはずっと前に解決されるべきものでした。まあ、それは解決しました（アカデミアと業界の両方で、正確にはほぼ40年）が、人々（絶対に賛成か反対か）は注意を払っていません。

私の残りの答えに関しては、それはすべて相対的です（ソフトウェアにはないものは何ですか？）：

• 本当にいいこと？

はい。ほとんどの場合、一般的なケースでは、エッジケースおよび言語固有のプログラミング構成に固有の注意事項があります。

常にですか、それとも時々ですか？

ほとんどの時間。

それは実際にどのくらい違いますか？

依存します。

読み取り可能なコードと読み取り不可能なコード。複雑さの増加（これでエラーが発生する可能性が増加する）と単純な複雑さ（そしてエルゴ、エラーの可能性が小さくなる）コンパイラーが暗黙的な戻り値を追加しない言語（Pascal、Java、C＃など）とデフォルトはint（CおよびC ++）。

結局、それはキーボードの後ろの人/時間で磨かれたスキルです。次のように、複数のreturnステートメントを使用しても問題ない場合があります（一部のPascal風の擬似コード）。

function foo() : someType
  begin
  if( test1 == true )
  then
    return x;
  end
  doSomethignElseThatShouldnHappenIfTest1IsTrue();
  return somethingElse();
end;

意図は明確であり、アルゴリズムは十分に小さく複雑ではないため、単一の戻り点で使用される最終的な戻り値を保持する「フラグ」変数の作成を保証しません。アルゴリズムにエラーがある可能性がありますが、その構造は非常に単純であるため、エラーを検出する労力は（ほとんどの場合）無視できます。

時々そうではありません（ここではCのような擬似コードを使用しています）：

switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
   doSomething(); // no return statement yet
}

ここで、アルゴリズムは単純な構造を持たず、switchステートメント（Cスタイルのステートメント）は、アルゴリズムの一部として意図的に実行される場合とされない場合のフォールスルーステップを許可します。

アルゴリズムは正しいかもしれませんが、不完全に書かれています。

あるいは、プログラマの能力を超えた外力によって、これは合法的に必要なアルゴリズムの実際の（そして正しい）表現です。

たぶんそれは間違っています。

これのいずれかの真実を明らかにするには、はるかに多くの努力が必要です、前の例よりもがです。そして、ここに私が強く信じるものがあります（これをバックアップする正式な研究がないことに注意してください）：

正しいと想定されるコードスニペットを想定：

1. 複数のreturnステートメントは、スニペットが本質的に単純なフロー構造を持つ単純なアルゴリズムを表す場合、そのようなコードスニペットの読みやすさと単純さを向上させます。簡単に言うと、私は小さいという意味ではありませんが、本質的に理解できるまたは自明であることを意味します。これは、不均衡な読書努力を必要としません（また、人々がそれを読む必要があるときに嘔吐させたり、誰かの母親を呪ったり、弾丸を飲み込んだりすることもありません）。 ）

2. 戻り値がアルゴリズムの実行中に計算される場合、または計算の責任を負うアルゴリズムのステップがアルゴリズムの構造内の1つの場所にグループ化できる場合、単一のreturnステートメントにより、そのようなコードの可読性と単純さが向上します。

3. 単一のreturnステートメントは、1つまたは複数のフラグ変数への割り当てが必要で、そのような割り当ての場所がアルゴリズム全体に均一に配置されていない場合、そのようなコードの可読性と単純さを低下させます。

4. 複数のreturnステートメントは、returnステートメントがアルゴリズム全体に均一に分散されておらず、サイズや構造が均一ではない相互に排他的なコードブロックを区別する場合、そのようなコードの可読性と単純さを低下させます。

これは、問題のコードスニペットの複雑さに密接に関連しています。そして、これは順番にサイクロマティックおよびハルステッド複雑度の測定に関連しています。これから、次のことを観察できます。

サブルーチンまたは関数のサイズが大きいほど、その内部制御フロー構造は大きく複雑になり、複数または単一のreturnステートメントを使用するかどうかという問題に直面する可能性が高くなります。

結論は次のとおりです。関数を1つだけ実行し、1つだけ実行する（および適切に実行する）ように小さくします。それらが名目上小さな循環的およびハルステッド複雑性メトリックを示す場合、それらはおそらく最も正確であり、理解可能なタスクの実装であることに縛られるだけでなく、その内部構造も比較的自明です。

その後、非常に簡単に、また多くの睡眠を失うことなく、どちらの選択でもエラーを引き起こすリスクをあまり冒さずに、単一のリターンと複数のリターンを使用するかどうかを決定できます。

また、このすべてを見て、単一のリターンまたは複数のリターンの問題に苦しんでいるとき、それは-経験不足、愚かさ、または労働倫理の欠如による-きれいなコードを書かず、書く傾向があることを示唆することができますサイクロマティックおよびハルステッド測定を完全に無視した巨大な関数。