4

かっこは可読性を向上させるといつも思っていましたが、私の教科書には、かっこを使用するとプログラムの可読性が大幅に低下するという記述があります。誰にも例がありますか？

4

8 に答える 8

6

括弧の欠如が読みやすさを低下させた反例をたくさん見つけることができますが、著者が意味したかもしれないことについて私が考えることができる唯一の例は次のようなものです：

if(((a == null) || (!(a.isSomething()))) && ((b == null) || (!(b.isSomething()))))
{
   // do some stuff
}

上記の場合、メソッド呼び出しの前後の（）は不要であり、この種のコードは、用語を変数にファクタリングすることでメリットが得られる可能性があります。状態の真ん中にこれらの閉じ括弧がすべてあるため、何が何とグループ化されているかを正確に確認することは困難です。

boolean aIsNotSomething = (a == null) || !a.isSomething();  // parens for readability
boolean bIsNotSomething = (b == null) || !b.isSomething();  // ditto
if(aIsNotSomething && bIsNotSomething)
{
   // do some stuff
}

上記の方が読みやすいと思いますが、それは個人的な意見です。それは作者が話していたものかもしれません。

パレンのいくつかの良い使い方：

  • 両親なしで行動が変化したときの操作の順序を区別するため
  • 動作に影響がない場合の操作の順序を区別しますが、バインディングルールを十分に理解していない人は、コードを読み取ることになります。善良な市民のルール。
  • より大きな式で使用する前に、親内の式を評価する必要があることを示すには、次のようにします。System.out.println("The answer is " + (a + b));

おそらく紛らわしいparensの使用：

  • 上記の前のように、それがおそらく別の意味を持つことができない場所でa.isSomething()。Javaでは、aがである場合Object、!aそれ自体がエラーであるため、メソッド呼び出しの戻り値を明らかに!a.isSomething()否定する必要があります。
  • 分割するとより明確になる多数の条件または式をリンクします。上記のコード例のように、大きなパラセティックステートメントを小さなチャンクに分割すると、デバッガーでコードをより簡単にステップスルーできるようになります。条件/値がコードの後半で必要になった場合でも、終了しません。式を繰り返して、作業を2回行います。ただし、これは主観的なものであり、式を1か所でのみ使用し、デバッガーが中間評価された式を表示する場合は、明らかに意味がありません。
于 2010-03-14T12:42:24.173 に答える
5

どうやら、あなたの教科書は Lisp が嫌いな人によって書かれているようです。

いずれにせよ、それは好みの問題であり、すべての人にとって唯一の真実はありません.

于 2010-03-14T12:17:39.297 に答える
2

コードの可読性を向上させるには、括弧を使用するのが最善の方法ではないと思います。改行を使用して、if ステートメントの条件などに下線を引くことができます。不要な場合は括弧を使用しません。

于 2010-03-14T12:19:36.107 に答える
2

さて、次のようなことを考えてみましょう：

Result = (x * y + p * q - 1) % tと

Result = (((x * y) + (p * q)) - 1) % t

個人的には前者を好みます (しかし、それは私だけです)。後者は、実際には操作の順序を変更するために括弧が存在すると思わせるためです。教科書では、計算を複数の変数に分割できる場合についても言及されている場合があります。たとえば、二次方程式を解くと、おそらく次のようになりますax^2+bx+c=0。

x1 = (-b + sqrt(b*b - 4*a*c)) / (2*a)

これはちょっと醜いように見えます。私の意見では、これはより良く見えます：

SqrtDelta = sqrt(b*b - 4*a*c);
x1 = (-b + SqrtDelta) / (2*a);

これは単純な例の 1 つにすぎません。多くの計算を伴うアルゴリズムを使用すると、状況が非常に悪くなる可能性があるため、計算を複数の部分に分割すると、括弧よりも読みやすくなります。

于 2010-03-14T12:23:39.750 に答える
2

括弧が明らかに冗長な場合、括弧は可読性を低下させます。読者は理由があって彼らがそこにいることを期待していますが、理由はありません。したがって、認知的しゃっくり。

「明らかに」冗長とはどういう意味ですか?

  • プログラムの意味を変更せずに括弧を削除できる場合、括弧は冗長です。

  • 中置演算子のあいまいさを解消するために使用される括弧は、乗算演算子と加算演算子の非常に特殊なケースを除いて、冗長であっても「明らかに冗長」ではありません。理由: 多くの言語には 10 ～ 15 レベルの優先順位があり、多くの人が複数の言語で作業しており、誰もすべての規則を覚えているとは期待できません。括弧が冗長であっても、あいまいさを解消する方がよい場合がよくあります。

  • 他のすべての冗長な括弧は明らかに冗長です。

冗長な括弧は、新しい言語を学んでいる人が書いたコードによく見られます。おそらく、新しい構文に関する不確実性が、防御的な括弧の使用につながる可能性があります。それらを抹消してください！

あなたは例を求めました。初心者が書いた ML コードと Haskell コードで繰り返し目にする 3 つの例を次に示します。

  • 間の括弧if (...) thenは常に冗長で気を散らします。彼らは作者を C プログラマーのように見せます。ただ書いてif ... thenください。

  • のように、変数を括弧で囲むのはばかげていprint(x)ます。変数を括弧で囲む必要はありません。関数アプリケーションを記述する必要がありますprint x。

  • 関数適用が中置式のオペランドである場合、関数適用を囲む括弧は冗長です。例えば、

    (length xs) + 1

    必ず書くべき

    length xs + 1
于 2010-03-14T15:24:48.753 に答える
1

極端に使用されたり、使いすぎたりすると、コードが読めなくなる可能性があります。コメントで同じ主張をするのは難しいことではありません。事実上すべてのコード行にコメントがあるコードを見たことがあれば、読みにくいことがわかります。または、コードのすべての行を空白にして、各行を読みやすくすることもできますが、通常、ほとんどの人は、類似した関連行（ブレークアウトメソッドを必要としない）をグループ化することを望んでいます。

于 2010-03-14T12:47:32.250 に答える
1

読みやすさを実際に損なうには、それらをはるかに超える必要がありますが、個人的な好みの問題として、私は常に次のことを発見しました。

return (x + 1);

C および C++ コードでも同様であり、非常にいらいらさせられます。

于 2010-03-14T13:09:50.873 に答える
0

メソッドがパラメーターを取らない場合、なぜ空の()呼び出しが必要なのmethod()ですか? これを行う必要はありません。

于 2010-03-14T12:13:30.793 に答える