私はこのようなコードを見てきました:
if(statement)
do this;
else
do this;
私はそれが好きではない、私はこれがよりきれいで読みやすいと思う
if(statement){
do this;
}else{
do this;
}
これは単に好みの問題ですか、それとも一方の方法が他方よりも推奨されますか?
最初のバージョンの問題は、中括弧を追加することを忘れずに戻ってif節またはelse節に2番目のステートメントを追加すると、予期しない面白い方法でコードが壊れることです。
保守性の面では、2番目の形式を使用する方がalwaysより賢くなります。
編集:ネッドはコメントでこれを指摘していますが、ここにもリンクする価値があると思います。これは単なる象牙の塔のでたらめではありません: https://www.imperialviolet.org/2014/02/22/applebug.html
ステートメントブロックを除外する場合の問題の1つは、else-ambiguityです。つまり、Cに触発された言語はインデントを無視するため、これを分離する方法はありません。
if(one)
if(two)
foo();
else
bar();
これから:
if(one)
if(two)
foo();
else
bar();
私の一般的なパターンは、1行に収まる場合は次のようにします。
if(true) do_something();
Else句がある場合、またはtrue
で実行するコードの長さがかなり長い場合は、中括弧で囲みます。
if(true) {
do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}
if(false) {
do_something();
} else {
do_something_else();
}
最終的には、スタイルと読みやすさの主観的な問題に帰着します。ただし、一般的なプログラミングの世界は、2つのパーティ(ブレースを使用する言語の場合)にほぼ分かれています。例外なく常に使用するか、例外なく常に使用します。私は後者のグループの一員です。
使用しているIDEのコードフォーマッタを使用しています。これは異なる場合がありますが、設定/オプションで設定できます。
私はこれが好きです:
if (statement)
{
// comment to denote in words the case
do this;
// keep this block simple, if more than 10-15 lines needed, I add a function for it
}
else
{
do this;
}
かっこを最初の瞬間から持っていると、これをデバッグする必要がなくなります:
if (statement)
do this;
else
do this;
do that;
私が従う「ルール」はこれです:
「if」ステートメントが何かを実行するためにテストしている場合(つまり、関数の呼び出し、変数の構成など)、中括弧を使用します。
if($test)
{
doSomething();
}
これは、どの関数がどのような条件で呼び出されるのか、プログラムのフローがどこに向かっているのかを明確にする必要があると思うからです。この条件でどの関数が呼び出され、どの変数が設定されているかをプログラマに正確に理解させることは、プログラムが何をしているかを正確に理解するために重要です。
「if」ステートメントが何かを停止するためにテストしている場合(つまり、ループまたは関数内のフロー制御)、1行を使用します。
if($test) continue;
if($test) break;
if($test) return;
この場合、プログラマーにとって重要なのは、コードを実行したくない例外的なケースをすばやく発見することであり、それはすべて実行ブロックではなく$ testでカバーされます。
単純なものであっても、すべてのifステートメントに中括弧を使用します。または、三項演算子を使用するように単純なifステートメントを書き直します。
if (someFlag) {
someVar= 'someVal1';
} else {
someVar= 'someVal2';
}
このようにずっと良く見えます:
someVar= someFlag ? 'someVal1' : 'someVal2';
ただし、if/elseブロックに他に必要なものがないことが確実な場合にのみ、三項演算子を使用してください。
中括弧を使用することを好みます。中括弧を追加すると、読みやすく、変更しやすくなります。
中かっこを使用するためのリンクを次に示します。
それは好みの問題です。私は個人的に両方のスタイルを使用します。文を追加する必要がないと合理的に確信している場合は、最初のスタイルを使用しますが、可能であれば、2番目のスタイルを使用します。最初のスタイルにこれ以上ステートメントを追加することはできないため、一部の人はこのスタイルの使用を推奨しないと聞いています。ただし、2番目の方法では追加のコード行が発生し、ユーザー(またはプロジェクト)がこの種類のコーディングスタイルを使用する場合、最初の方法は単純なifステートメントに非常に適しています。
if(statement)
{
do this;
}
else
{
do this;
}
ただし、この問題の最善の解決策はPythonにあると思います。空白ベースのブロック構造では、ifステートメントを作成するための2つの異なる方法はありません。1つしかありません。
if statement:
do this
else:
do this
それには、中括弧をまったく使用できないという「問題」がありますが、最初のスタイルよりも行が少なく、ステートメントを追加することができるという利点があります。
私の経験から、最初の形式の唯一の(非常に)わずかな利点はコードの可読性であり、2番目の形式は「ノイズ」を追加します。
しかし、最新のIDEとコードの自動生成(またはオートコンプリート)では、2番目の形式を使用することを強くお勧めします。中括弧を入力するのに余分な時間を費やすことはなく、最も頻繁に発生するバグを回避できます。
エネルギーを消費するバグが十分にあり、人々は時間の大きな無駄のためにドアを開けないでください。
コードを記述するときに覚えておくべき最も重要なルールの1つは、一貫性です。コードのすべての行は、誰が書いても同じ方法で書かれるべきです。厳密であることは、バグの「発生」を防ぎます;)
これは、変数、メソッド、ファイルを明確かつ明示的に命名する場合、またはそれらを正しくインデントする場合と同じです...
私の生徒たちがこの事実を受け入れると、彼らは自分のソースコードとの戦いをやめ、コーディングは本当に興味深く、刺激的で創造的な活動であると見始めます。彼らは神経ではなく心に挑戦します!
私はいつも自分のコードを標準にし、できるだけ同じように見えるようにしました。これにより、他の人が更新を担当しているときに読みやすくなります。最初の例を実行し、途中で行を追加すると失敗します。
動作しません:
if(statement)これを行う;この;それ以外の場合はこれを行います。
個人的には、最初のスタイルを使用するのは、例外をスローするか、メソッドから早く戻るだけです。関数の最初での引数チェックのように、これらの場合、私がすることは複数あることはめったにないので、他にはないからです。
例:
if (argument == null)
throw new ArgumentNullException("argument");
if (argument < 0)
return false;
それ以外の場合は、2番目のスタイルを使用します。
私の個人的な好みは、次のような空白と括弧の混合物を使用することです。
if( statement ) {
// let's do this
} else {
// well that sucks
}
これはきれいに見え、私のコードを非常に読みやすくし、最も重要なのはデバッグです。
コードに明示的に記述し、中かっこを使用する方が良いという事実に関するほとんどの回答に同意します。個人的には、一連のコーディング標準を採用し、チームの全員がそれらを認識して準拠していることを確認します。私が働いている場所では、.NETプロジェクトに対して IDesign.net によって公開されたコーディング標準を使用しています。
中かっこを付ける方が好きです。しかし、時々、三項演算子が役立ちます。
の代わりに :
int x = 0;
if (condition) {
x = 30;
} else {
x = 10;
}
単純に行う必要があります:int x = condition ? 30 : 20;
ケースも想像してください:
if (condition)
x = 30;
else if (condition1)
x = 10;
else if (condition2)
x = 20;
中括弧を入れればもっといいでしょう。