17

しばらく前に書いたコード標準ドキュメントの一部として、「ループや条件付きコードブロックには、（特に）1行しかない場合でも、常に中括弧を使用する必要があります」と強制します。

例：

// this is wrong
if (foo) 
    //bar
else 
    //baz
while (stuff)
    //things

// This is right.
if (foo) {
    // bar
} else {
    // baz
}
while (things) {
    // stuff
}

1行を中括弧で囲まずに、誰かがそれをコメントアウトすると、問題が発生します。1行を中括弧で囲まず、インデントが他の人のマシンで同じように表示されない場合は、問題が発生しています。

それで、質問：これが誤った、またはそうでなければ不合理な基準になる理由はありますか？それについてはいくつかの議論がありましたが、「醜い」よりも良い反論を私に提供できる人は誰もいません。

4

21 に答える 21

23

私が提供できる最良の反論は、スペースによって占有される余分な行により、一度に表示できるコードの量が減少し、一度に表示できるコードの量が、いかに簡単かを左右する大きな要因であるということです。エラーを見つけることです。あなたが中括弧を含める理由に同意しますが、何年にもわたるC++の中で、結果として間違いを犯したのは1回だけで、中括弧をスキップする正当な理由がなかった場所でした。とりあえず。残念ながら、これらの余分なコード行が実際に役立つかどうかはわかりませんでした。

同じインデント レベルで一致する中かっこの対称性 (および実行の 1 つのブロックとして含まれるステートメントの暗黙のグループ化) が好きなので、私はおそらくより偏っています。つまり、常に中かっこを追加すると、多くの行が事業。

于 2009-12-16T18:39:41.877 に答える
22

ループを返すか続行するかを評価するifステートメントのマイナーな例外を除いて、これをある程度まで強制します。

だから、これは私の基準では正しいです：

if(true) continue;

このように

if(true) return;

しかし、ルールはそれがリターンかコンティニューのどちらかであり、それはすべて同じ行にあるということです。それ以外の場合は、すべてを中括弧で囲みます。

理由は、それを行うための標準的な方法を持つためと、あなたが言及したコメントの問題を回避するための両方です。

于 2009-12-16T18:17:29.430 に答える
8

中かっこを常に使用しない正当な理由を考え出す人はまだいません。

メリットは、私が聞いた「醜い」理由をはるかに超えています。

コーディング標準は、コードを読みやすくし、エラーを減らすために存在します。

これは本当に報われる1つの基準です。

于 2009-12-16T18:17:39.337 に答える
5

エラーを減らし、コードを読みやすくするコーディング標準について議論するのは難しいと思います。最初は醜い感じがするかもしれませんが、実装するのは完全に有効なルールだと思います。

于 2009-12-16T18:18:48.367 に答える
5

インデントに応じて中かっこが一致する必要があるという立場に立っています。

// This is right.
if (foo) 
{
    // bar
}
else 
{
    // baz
}

while (things) 
{
    // stuff
}

2つの例に関しては、一致する閉じ括弧を見つけるのは難しい場合があるため、少し読みにくくなると思いますが、インデントが正しくない場合は読みやすくなり、ロジックを簡単に挿入できます。大きな違いではありません。

インデントが正しくない場合でも、ifステートメントは、次の行にあるかどうかに関係なく、次のコマンドを実行します。両方のコマンドを同じ行に配置しない唯一の理由は、デバッガーのサポートのためです。

于 2009-12-16T18:24:16.980 に答える
4

現在、私はこの基準に従って生活しているチームと協力しており、それに抵抗する一方で、統一性のために準拠しています。

例外、テンプレート、マクロの使用を禁止しているチームに反対するのと同じ理由で反対します。言語を使用する場合は、言語全体を使用してください。C、C ++、およびJavaで中括弧がオプションである場合、慣例により中括弧を義務付けることは、言語自体に対するある程度の恐れを示しています。

私はここで他の回答に記載されている危険性を理解し、統一への憧れを理解していますが、テンプレートに対応していない環境用の唯一のコンパイラやCコードとの相互作用など、いくつかの厳密な技術的理由を除いて、言語サブセットには同情していません例外の広範な使用を排除します。

私の一日の多くは、ジュニアプログラマーによって提出された変更を確認することで構成されており、発生する一般的な問題は、ブレースの配置やステートメントが間違った場所に配置されることとは関係ありません。ハザードは誇張されています。コンパイラーが喜んで受け入れるものの違反を探すよりも、もっと重要な問題に集中することに時間を費やしたいと思います。

于 2009-12-16T19:59:46.650 に答える
4

私が見ている大きな利点の1つは、中括弧で囲まれた条件文とループにステートメントを追加する方が簡単であり、最初に中括弧を作成するために多くの追加のキーストロークを必要としないことです。

于 2009-12-16T18:19:09.860 に答える
4

私の個人的なルールは、それが非常に短い場合は'if'であり、すべてを1行にまとめます。

if(!something) doSomethingElse();

通常、これは、このようなifが連続して多数ある場合にのみ使用します。

if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);

ただし、そのような状況はあまり発生しないので、それ以外の場合は、常に中かっこを使用します。

于 2009-12-16T18:25:20.273 に答える
4

プログラマーのグループがコーディング標準にうまく従う唯一の方法は、ルールの数を最小限に抑えることです。

メリットとコストのバランスをとってください (すべての余分なルールはプログラマーを混乱させ、混乱させ、特定のしきい値を超えると、プログラマーがいずれかのルールに従う可能性を実際に減らします)

したがって、コーディング標準を作成するには:

  • 他のルールよりも優れているという明確な証拠を示して、すべてのルールを正当化できることを確認してください。

  • ルールに代わるものを見てください - それは本当に必要ですか? すべてのプログラマーが空白 (空白行とインデント) をうまく使用している場合、if ステートメントは非常に読みやすく、初心者のプログラマーでさえ "if" 内のステートメントをスタンドアロンのステートメントと間違える可能性はありません。if-scoping に関連する多くのバグが発生している場合、根本的な原因はおそらく、コードを不必要に読みにくくする貧弱な空白/インデント スタイルを使用していることです。

  • コード品質に対する測定可能な影響によって、ルールに優先順位を付けます。ルールを適用することで回避できるバグの数 (例: 「常に null をチェックする」、「常にアサートでパラメーターを検証する」、「常に単体テストを作成する」対「必要でない場合でも常にいくつかの中括弧を追加する」) . 前者のルールにより、年間何千ものバグを防ぐことができます。ブレース ルールを使用すると、1 つ節約できます。多分。

  • 最も効果的なルールを守り、チャフを捨てます。チャフは、少なくとも、ルールを無視することによって発生する可能性のあるバグよりも実装にコストがかかるルールです。しかし、おそらく 30 以上の重要なルールがある場合、プログラマーはそれらの多くを無視し、あなたの善意は塵のようになります。

  • コードを読まずにランダムなビットをコメントアウトするプログラマーをクビにします :-)

PS ブレースに関する私のスタンスは次のとおりです。「if」ステートメントまたはその内容が両方とも 1 行である場合は、ブレースを省略できます。つまり、1 行のコメントと 1 行のコードを含む if がある場合、内容は 2 行になるため、中かっこが必要になります。if 条件が 2 行にわたる場合 (内容が 1 行であっても)、中かっこが必要です。これは、実際には間違いが決して起こらない、些細で単純で読みやすいケースでのみ中括弧を省略することを意味します。(ステートメントが空の場合、私は中かっこを使用しませんが、私は常に、それが空であることを明確に示すコメントを入れています。意図的にそうしています。しかし、それは別のトピックに隣接しています。電話が鳴ったのではなく、スコープを空にして、コードを完成させるのを忘れた）

于 2009-12-16T21:20:04.943 に答える
3

常に中括弧を使用するもう1つの利点は、検索と置換などの自動化された操作が簡単になることです。

functionB例：これは通常、の直後に呼び出され、同様の引数パターンで呼び出されることに気付いたとfunctionAします。そのため、重複したコードを新しいにリファクタリングしたいとしcombined_functionます。十分に強力なリファクタリングツール（）がない場合、正規表現はこのリファクタリングを簡単に処理できます^\s+functionA.*?;\n\s+functionB.*?;が、中括弧がないと、単純な正規表現アプローチは失敗する可能性があります。

if (x)
  functionA(x);
else
  functionA(y);
functionB();

になります

if (x)
  functionA(x);
else
  combined_function(y);

この特定のケースでは、より複雑な正規表現が機能しますが、正規表現ベースの検索と置換、1回限りのPerlスクリプト、および同様の自動コードメンテナンスを使用できると非常に便利であることがわかったため、コーディングスタイルを好みます。それはそれを不必要に複雑にすることはありません。

于 2009-12-16T20:04:40.057 に答える
3

私はあなたの議論に賛成しません。個人的には、「誤って」下に2行目を追加したことのある人は誰も知りませんif。ネストされた ステートメントには、他のぶら下がりを避けるために中かっこを付ける必要があると私は理解ifしますが、IMOが置き忘れられる恐れがあるため、スタイルを強制していることがわかります。

于 2009-12-16T20:06:23.080 に答える
3

多くの言語には、このような「醜さ」に対処するために、このような 1 つのライナー (特に perl を考えています) の構文があります。次のようなものです：

if (foo)     
//bar
else     
//baz

三項演算子を使用して三項として記述できます。

foo ? bar : baz

と

while (something is true)
{
blah 
}

次のように記述できます。

blah while(something is true)

ただし、この「砂糖」を持たない言語では、中かっこを必ず含めます。おっしゃる通り、不要なバグの侵入を防ぎ、プログラマーの意図をより明確にします。

于 2009-12-16T18:26:03.627 に答える
3

理不尽だと言っているわけではありませんが、C に似た言語で 15 年以上のコーディングを行ってきましたが、中かっこを省略して問題が発生したことは一度もありません。ブランチをコメントアウトすることは、理論的には本当の問題のように思えます - 私はそれが実際に起こっているのを見たことがありません.

于 2009-12-16T18:34:02.840 に答える
1

これらすべてを読む時間があれば、中括弧を追加する時間があります。

于 2009-12-16T20:49:18.843 に答える
1

以下は、私が従う不文律 (今までだと思います) です。正確さを犠牲にすることなく読みやすさを提供すると信じています。これは、多くの場合、短い形式の方が長い形式よりも読みやすいという信念に基づいています。

  • ステートメントのブロックに複数の行がある場合は、常に中括弧を使用してください。if/else if/elseコメントはカウントされます。つまり、条件内の任意の場所にあるコメントは、条件付き get 中括弧のすべてのセクションを意味します。
  • ステートメントのすべてのブロックが正確に 1 行である場合は、必要に応じて中かっこを使用します。
  • 条件ステートメントを条件と同じ行に配置しないでください。if ステートメントの後の行は、常に条件付きで実行されます。

  • 条件ステートメント自体が必要なアクションを実行する場合、フォームは次のようになります。

    for (init; term; totalCount++)
{
    // Intentionally left blank
}

次のように言えば、これを冗長な方法で標準化する必要はありません。

読みやすさを犠牲にして中括弧を除外しないでください。疑わしい場合は、ブレースの使用を選択してください。

于 2009-12-16T18:42:29.733 に答える
1

中括弧について重要なことは、プログラマーの意図を非常に明確に表現することだと思います。インデントから意図を推測する必要はありません。

そうは言っても、Gus が提案した 1 行の return と continue が気に入っています。意図が明確で、よりクリーンで読みやすいです。

于 2009-12-16T18:43:41.280 に答える
0

保守性のために、単一行の条件に中かっこを追加することを好みますが、中かっこなしでそれを行うと、どのようにすっきりと見えるかがわかります。気になりませんが、余分な視覚的ノイズによってオフになる人もいます。

私もこれ以上の反論を提供することはできません。ごめん！;）

于 2009-12-16T18:18:13.923 に答える
0

言語によっては、1行の条件ステートメントまたはループステートメントに中括弧を付ける必要はありません。実際、コード行を減らすためにそれらを削除します。

C ++：

バージョン1：

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 ) throw InvalidOperation();
   return a/b;
}

バージョン2：

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 )
   { 
      throw InvalidOperation();
   }
   return a/b;
}

C＃：

バージョン1：

foreach(string s in myList)
   Console.WriteLine(s);

バージョン2：

foreach(string s in myList)
{
   Console.WriteLine(s);
}

視点に応じて、バージョン1またはバージョン2の方が読みやすくなります。答えはかなり主観的です。

于 2009-12-16T18:18:34.467 に答える
0

わお。誰もぶら下がっている他の問題に気づいていませんか？これが本質的に、常に中括弧を使用する理由です。

一言で言えば、elseステートメントを使用すると、特にネストされている場合に、厄介なあいまいなロジックが発生する可能性があります。さまざまなコンパイラが独自の方法であいまいさを解決します。何をしているのかわからない場合は、中かっこを省略するのは大きな問題になる可能性があります。

美学と読みやすさはそれとは何の関係もありません。

于 2009-12-16T19:53:16.457 に答える
0

このような場合は、IDEのオートフォーマッタの構成テンプレートを考え出すことをお勧めします。次に、ユーザーがalt-shift-F（または選択したIDEのキーストローク）を押すたびに、中括弧が自動的に追加されます。次に、全員に「先に進んで、フォントの色やPMD設定などを変更します。ただし、インデントや自動ブレースのルールは変更しないでください」と言ってください。

これは、私たちが利用できるツールを利用して、通常それに費やされる酸素の価値が本当にないものについて議論することを回避します。

于 2009-12-16T18:24:20.737 に答える