当前位置：文江博客话题详情

有哪些例子可以说明在程序中使用括号会降低可读性？

发布于 2024-08-25 05:49:16 字数 60 浏览 14 评论 0原文

我一直认为括号提高了可读性，但在我的教科书中有这样一句话：使用括号会极大地降低程序的可读性。有人有例子吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

潇烟暮雨 2024-09-01 05:49:16

我可以找到很多反例，其中缺少括号降低了可读性，但我能想到的作者可能的意思的唯一示例是这样的：

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("答案是 " + (a + b));

可能令人困惑的使用of parens:

在它不可能有其他含义的地方，比如上面的 a.isSomething() 前面。在 Java 中，如果 a 是一个 Object，则 !a 本身就是一个错误，所以显然 !a.isSomething()< /code> 必须否定方法调用的返回值。
将大量条件或表达式链接在一起，如果分解这些条件或表达式会更清晰。如上面的代码示例所示，将大的括号语句分解成较小的块可以使代码在调试器中更直接地单步执行，并且如果稍后在代码中需要条件/值，则不会结束重复表达并做两次工作。不过，这是主观的，如果您只在一处使用表达式并且调试器无论如何都会向您显示中间计算的表达式，那么这显然毫无意义。

I can find plenty of counterexamples where the lack of parentheses lowered the readability, but the only example I can think of for what the author may have meant is something like this:

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

In the above case, the ( ) around the method calls is unnecessary, and this kind of code may benefit from factoring out of terms into variables. With all of those close parens in the middle of the condition, it's hard to see exactly what is grouped with what.

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

I think the above is more readable, but that's a personal opinion. That may be what the author was talking about.

Some good uses of parens:

to distinguish between order of operation when behavior changes without the parens
to distinguish between order of operation when behavior is unaffected, but someone who doesn't know the binding rules well enough is going to read your code. The good citizen rule.
to indicate that an expression within the parens should be evaluated before used in a larger expression: System.out.println("The answer is " + (a + b));

Possibly confusing use of parens:

in places where it can't possibly have another meaning, like in front of a.isSomething() above. In Java, if a is an Object, !a by itself is an error, so clearly !a.isSomething() must negate the return value of the method call.
to link together a large number of conditions or expressions that would be clearer if broken up. As in the code example up above, breaking up the large paranthetical statement into smaller chunks can allow for the code to be stepped through in a debugger more straightforwardly, and if the conditions/values are needed later in the code, you don't end up repeating expressions and doing the work twice. This is subjective, though, and obviously meaningless if you only use the expressions in 1 place and your debugger shows you intermediate evaluated expressions anyway.

回复收藏 0 原文

安人多梦 2024-09-01 05:49:16

显然，你的教科书是由讨厌 Lisp 的人写的。

无论如何，这只是品味问题，没有适合每个人的唯一真理。

回复收藏 0 原文

雨巷深深 2024-09-01 05:49:16

好吧，考虑这样的事情：

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);

这只是一个简单的例子，当您使用涉及大量计算的算法时，事情可能会变得非常丑陋，因此将计算分成多个部分将比括号更有利于可读性。

Well, consider something like this:

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

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

Personally I prefer the former (but that's just me), because the latter makes me think the parantheses are there to change the actual order of operations, when in fact they aren't doing that. Your textbook might also refer to when you can split your calculations in multiple variables. For example, you'll probably have something like this when solving a quadratic ax^2+bx+c=0:

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

Which does look kind of ugly. This looks better in my opinion:

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

And this is just one simple example, when you work with algorithms that involve a lot of computations, things can get really ugly, so splitting the computations up into multiple parts will help readability more than parantheses will.

回复收藏 0 原文

悲念泪 2024-09-01 05:49:16

我认为括号并不是提高代码可读性的最佳方法。您可以使用换行符来下划线，例如 if 语句中的条件。如果不需要，我不会使用括号。

回复收藏 0 原文

乖乖哒 2024-09-01 05:49:16

当括号明显多余时，会降低可读性。读者期望他们在那里是有原因的，但实际上没有理由。因此，出现了认知打嗝。

“明显”多余是什么意思？

当可以删除括号而不改变程序的含义时，括号是多余的。
用于消除中缀运算符歧义的括号不是“明显冗余”，即使它们是冗余的，除非在乘法和加法运算符的非常特殊的情况下。原因：许多语言都有 10 到 15 级优先级，许多人使用多种语言工作，没有人能记住所有规则。即使括号是多余的，最好还是消除歧义。
所有其他冗余括号显然是多余的。

在学习新语言的人编写的代码中经常会发现多余的括号；也许新语法的不确定性会导致防御性括号。
消灭他们！

您要求提供示例。以下是我在初学者编写的 ML 代码和 Haskell 代码中反复看到的三个示例：

if (...) then 之间的括号总是多余且分散注意力。它们使作者看起来像一个 C 程序员。只需编写 if ... then。
变量周围的括号很愚蠢，如 print(x) 中那样。变量周围不需要括号；函数应用程序应该写成 print x。
如果函数应用程序是中缀表达式中的操作数，则该函数应用程序周围的括号是多余的。例如，
<前><代码>（长度xs）+ 1
应该总是写
```
长度 xs + 1
```

Parentheses reduce readability when they are obviously redundant. The reader expects them to be there for a reason, but there is no reason. Hence, a cognitive hiccough.

What do I mean by "obviously" redundant?

Parentheses are redundant when they can be removed without changing the meaning of the program.
Parentheses that are used to disambiguate infix operators are not "obviously redundant", even when they are redundant, except perhaps in the very special case of multiplication and addition operators. Reason: many languages have between 10–15 levels of precedence, many people work in multiple languages, and nobody can be expected to remember all the rules. It is often better to disambiguate, even if parentheses are redundant.
All other redundant parentheses are obviously redundant.

Redundant parentheses are often found in code written by someone who is learning a new language; perhaps uncertainty about the new syntax leads to defensive parenthesizing.
Expunge them!

You asked for examples. Here are three examples I see repeatedly in ML code and Haskell code written by beginners:

Parentheses between if (...) then are always redundant and distracting. They make the author look like a C programmer. Just write if ... then.
Parentheses around a variable are silly, as in print(x). Parentheses are never necessary around a variable; the function application should be written print x.
Parentheses around a function application are redundant if that application is an operand in an infix expression. For example,
```
(length xs) + 1
```
should always be written
```
length xs + 1
```