language-agnostic - 単一の決定およびアクションステートメントに適したスタイルは何ですか？

Question

次の例のように、括弧なしで単一の決定とアクションをサポートする言語の場合：

if (var == true)
    doSomething();

これを書くための好ましい方法は何ですか？ブラケットは常に使用する必要がありますか、それとも個々の開発者の好みとして使用を残す必要がありますか？さらに、この方法は、次の例のように、コードブロックのサイズに依存しますか？

if (var == 1)
    doSomething(1);
else if (var > 1 && var < 10)
    doSomething(2);
else
{
    validate(var);
    doSomething(var);
}

score 10 · Accepted Answer

本当に正しい答えはありません。これが社内のコーディング標準です。会社全体で一貫性を保つことができれば、読みやすくなります。私は個人的に好きです

if ( a == b)    {
    doSomething();
}
else {
    doSomething();
}

しかしこれは聖戦。

score 10 · Accepted Answer

私はお勧め

if(a==b)
{
    doSomething();
}

成功条件に 2 番目のステートメントを追加するときに中かっこを追加することを覚えておくよりも、前もって実行する方がはるかに簡単だと思うからです...

if(a==b)
    doSomething();
    doSomethingElse();

とは大きく異なります

if(a==b)
{
    doSomething();
    doSomethingElse();
}

詳細についてはJoel の記事を参照してください。

score 8 · Accepted Answer

私は常にブレースを使用する傾向があります。次のようなものから始めたところに、いくつかの微妙なバグが発生する可能性があります。

if(something)
 DoOneThing();
else
  DoItDifferently();

次に、句に別の操作を追加しelse、中かっこで囲むのを忘れることにしました。

if(something)
 DoOneThing();
else
  DoItDifferently();
  AlwaysGetsCalled();

AlwaysGetsCalled()は常に呼び出されます。午前 3 時にそこに座って、なぜコードの動作がおかしくなっているのか不思議に思っていると、そのようなことはかなり長い間見逃される可能性があります。この理由だけでも、私は常にブレースを使用しています。

score 4 · Accepted Answer

私の好みは、一貫性を保つことです。たとえば、1 つのブロックでブラケットを使用する場合は、1 つのステートメントだけでもブラケット全体を使用します。

if (cond1)
{
   SomeOperation();
   Another();
}
elseif (cond2)
{
   DoSomething();
}
else
{
   DoNothing();
   DoAnother();
}

しかし、1 つのライナーがたくさんある場合は、次のようになります。

if (cond1)
    DoFirst();
elseif (cond2)
    DoSecond();
else
    DoElse();

その方がきれいに見えます (ダミーのメソッド名を気にしないのであれば ;) が、それは私だけです。

これは、ループ構造などにも当てはまります。

foreach (var s as Something)
    if (s == someCondition)
        yield return SomeMethod(s);

また、これは .NET により適した規則であることも考慮する必要があります (Java peepz は、最初の中括弧を if と同じ行に配置することを好むことに注意してください)。

score 3 · Accepted Answer

これは経験不足のせいだと思いますが、コードモンキーとしての 7 年間の勤務期間中、ブレースのないブロックにコードを追加するときに、ブレースを追加しないという間違いを犯した人を実際に見たことがありません。それは正確にゼロ回です。

そして、賢明なクラッカーがそれに到達する前に、いいえ、その理由は「誰もが常にブレースを使用する」ということではありませんでした.

だから、正直な質問 - 私は本当に反対票ではなく実際の返信を得たいと思っています.それは実際に起こるのでしょうか?

(編集: アウトソーシングのホラーストーリーを十分に聞いたので、少し明確にします:有能なプログラマーに実際に起こることはありますか?)

score 2 · Accepted Answer

あなたがそれに一貫している限り、それは本当に重要ではありません。

1つのステートメント内で同一性を要求する傾向があるようです。つまり、1つのブランチに角かっこがある場合、どこにでも角かっこがあります。Linuxカーネルのコーディング標準は、その1つとしてそれを義務付けています。

score 2 · Accepted Answer

オプションの場合でも、中括弧を常に使用することを強くお勧めします。なんで？次の C++ コードのチャンクを取り上げます。

if (var == 1)
  doSomething();
doSomethingElse();

さて、実際には十分な注意を払っていない誰かがやって来て、(var == 1) の場合に何か特別なことが起こる必要があると判断したので、彼らはこれを行います:

if (var == 1)
  doSomething();
  doSomethingExtra();
doSomethingElse();

それはすべてまだ美しくインデントされていますが、意図したとおりにはなりません。

中かっこを常に使用することで、この種のバグを回避する可能性が高くなります。

score 2 · Accepted Answer

私は個人的に、Code Complete からの McConnell の説明を支持します。

できる限りそれらを使用してください。コードの可読性を高め、発生する可能性のあるわずかな混乱を取り除きます。

ただし、もっと重要なことが 1 つあります....一貫性です。どのスタイルを使用する場合でも、常に同じ方法で行うようにしてください。

次のようなものを書き始めます。


If A == true
   FunctA();

If B == "Test"
{
   FunctB();
}

コンパイラが何をしようとしているのかを理解できず、見つけるのが難しい奇妙なバグを探すことになります。

基本的に、毎回快適に書けるものを見つけて、それに固執してください。私は、可能な限りブロック区切り文字 ('{', '}') を使用することが道だと信じています。

別の質問の中で質問を開始したくはありませんが、これに関連して、あなたの精神力を養うために言及したいことがあります. ブラケットを使用する決定が下された場合。開始ブラケットをどこに置きますか？ステートメントと同じ行またはその下。インデントされたブラケットかどうか?


If A == false {
  //calls and whatnot
}
//or
If B == "BlaBla"
{
  //calls and whatnot
}
//or
If C == B
  {
  //calls and whatnot
  }

これは新しい質問になるため、これには答えないでください。これに興味がある場合は、あなたの入力から新しい質問を開きます。

score 1 · Accepted Answer

Cで必要なように、変数を解放する前にNULLをチェックしている場合を除いて、常に括弧を使用してきました

その場合、次のようにすべてを 1 行にまとめることで、1 つのステートメントであることを明確にします。

if (aString) free(aString);

score 1 · Accepted Answer

上記のステートメントの書き方に正しい方法も間違った方法もありません。受け入れられているコーディングスタイルはたくさんあります。ただし、私は、プロジェクト全体で一貫したコーディングスタイルを維持することを好みます。すなわち。プロジェクトが K&R スタイルを使用している場合は、K&R を使用する必要があります。

score 1 · Accepted Answer

他の人が言及したように、中括弧なしで 2 行で if ステートメントを実行すると、混乱が生じる可能性があります。

if (a == b)
    DoSomething();
    DoSomethingElse(); <-- outside if statement

読みやすさを損なうことなくできる場合は、1行に配置します。

if (a == b) DoSomething();

それ以外の場合は常にブレースを使用します。

三項演算子は少し異なります。ほとんどの場合、私はそれらを 1 行で行います。

var c = (a == b) ? DoSomething() : DoSomethingElse();

ただし、ステートメントに関数呼び出しがネストされている場合や、1 行のステートメントを視覚的に解析するのが困難なラムダ式が含まれている場合があるため、次のようなものを好みます。

var c = (a == b)
    ? AReallyReallyLongFunctionName()
    : AnotherReallyReallyLongFunctionOrStatement();

if/else ブロックよりもさらに簡潔ですが、何が起こっているのかを簡単に確認できます。

score 1 · Accepted Answer

Sun のJava プログラミング言語のコード規則には、次のように書かれています。

if-else クラスのステートメントは、次の形式にする必要があります。
if (condition) {
    statements;
}

if (condition) {
    statements;
} else {
    statements;
}

if (condition) {
    statements;
} else if (condition) {
    statements;
} else {
    statements;
}

score 1 · Accepted Answer

Ruby は、この議論における 1 つの問題を見事に回避します。ワンライナーの標準は次のとおりです。

do_something if (a == b)

複数行の場合:

if (a == b)
  do_something
  do_something_else
end

これにより、簡潔な 1 行のステートメントが可能になりますが、単一行から複数行に移行する場合、ステートメントを再編成する必要があります。

これは (まだ) Java や他の多くの言語では利用できません。

score 0 · Accepted Answer

少なくとも1つが必要な場合にのみ、すべてのステートメントを中括弧で囲みます。

score 0 · Accepted Answer

私たちの上司は、たとえそれが単一のステートメントであっても、決定ステートメントの後に{}を置くようにさせます。2行余分に追加するのは本当に面倒です。唯一の例外は三項演算子です。

コードモニターを1200x1600の縦向きにしたのは良いことだと思います。

score 0 · Accepted Answer

私は、次のコード例で、その記事 ( Making Wrong Code Look Wrong ) のJoel Spolsky に同意する傾向があります。

if (i != 0)
bar(i);
foo(i);

Foo は無条件になりました。それは本当に悪いです！

私は常に決定文に括弧を使用します。これにより、コードの保守性が向上し、コードのバグが発生しにくくなります。

score 0 · Accepted Answer

私は好む

if (cond)
   {
   //statement
   }

たった1つのステートメントでも。一度何かを書くつもりで、それが機能することに疑いがなく、そのコードを別のコーダーが見ることを計画したことがない場合は、先に進んで、好きな形式を使用してください。しかし、追加のブラケティングには実際にどのような費用がかかりますか? この投稿をタイプするのにかかる時間よりも、1 年間でより短い時間です。

はい、ブロックのレベルに合わせて括弧をインデントするのも好きです。

Python は、インデントがブロックを定義するという点で優れています。そのような言語では、その質問は意味がありません。

score 0 · Accepted Answer

私はapparatchikのように「常に中括弧を使用する」という行に従っていました。ただし、スタイルを変更して、単一行の条件式でそれらを省略できるようにしました。

if(!ok)return;

複数ステートメントのシナリオでは、中括弧は必須である必要があるという意見はまだあります。

if(!ok){

    do();

    that();

    thing();
}

score 0 · Accepted Answer

Perl で単純なテストを行う場合、次の形式で記述することがあります。

do_something if condition;

do_something unless condition;

これは、サブルーチンの開始時に引数をチェックするのに非常に役立ちます。

sub test{
  my($self,@args) = @_;

  return undef unless defined $self;

  # rest of code goes here

}

score 0 · Accepted Answer

ゴールデンルールは、既存のプロジェクトで作業する場合は、それらのコーディング標準に従うことです。

私が家にいるとき、私は2つのフォームを持っています。

最初の行は次の 1 行です。

if (condition) doThis();

2 つ目は複数行用です。

if (condition) {
   doThis();
}

language-agnostic - 単一の決定およびアクションステートメントに適したスタイルは何ですか？

20 に答える 20

Related

Reference