Question

我一直认为括号提高了可读性，但在我的教科书中有一个声明，即使用括号会大大降低程序的可读性。有没有人有任何例子？

Answer 1

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

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
}

我认为上述内容更具可读性，但这是个人观点。这可能就是作者所说的。

parens的一些好用途：

区分行为改变时的操作顺序
区分行为不受影响时的操作顺序，但不熟悉绑定规则的人将会读取您的代码。善良的公民统治。
表示在用于更大的表达式之前应该评估parens中的表达式：System.out.println("The answer is " + (a + b));

可能令人困惑的使用parens：

在不太可能具有其他含义的地方，例如上面的a.isSomething()前面。在Java中，如果a是Object，!a本身就是错误，那么!a.isSomething()必须否定方法调用的返回值。
将大量条件或表达链接在一起，如果分解则会更清楚。与上面的代码示例一样，将较大的paranthetical语句拆分为较小的块可以允许代码在调试器中更直接地逐步执行，如果稍后在代码中需要条件/值，则不会结束重复表达并完成两次工作。这是主观的，如果你只在一个地方使用表达式而你的调试器显示中间评估的表达式，那么这显然毫无意义。

Answer 2

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

无论如何，这是一个品味问题，每个人都没有单一的事实。

Answer 3

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

Answer 4

好吧，考虑这样的事情：

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

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

就我个人而言，我更喜欢前者（但那只是我），因为后者让我觉得这些parantheses可以改变实际的操作顺序，而事实上他们并没有这样做。您的教科书也可能涉及何时可以在多个变量中拆分计算。例如，在解决二次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);

这只是一个简单的例子，当你使用涉及大量计算的算法时，事情会变得非常难看，因此将计算分成多个部分将有助于提高阅读能力。

Answer 5

括号在明显多余时会降低可读性。读者希望他们出于某种原因，但没有理由。因此，认知打嗝。

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

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

冗余括号通常出现在正在学习新语言的人编写的代码中;也许新语法的不确定性导致了防御性的括号。清除它们！

你问了一些例子。以下是我在ML代码和初学者编写的Haskell代码中反复看到的三个例子：

if (...) then之间的括号总是多余且分散注意力。它们使作者看起来像C程序员。只需写下if ... then。
变量周围的括号很愚蠢，如print(x)中所示。在变量周围不需要括号;函数应用程序应写为print x。
如果该应用程序是中缀表达式中的操作数，则函数应用程序周围的括号是多余的。例如，
```
(length xs) + 1
```
应始终写
```
length xs + 1
```

Answer 6

任何极端和/或过度使用都会导致代码无法读取。用评论提出同样的主张并不困难。如果您曾经查看几乎每行代码都有注释的代码会告诉您难以阅读。或者你可以在每行代码周围都有空格，这样可以使每行易于阅读，但通常大多数人都希望将类似的相关行（不保证分组方法）组合在一起。

Answer 7

你必须超越它们才能真正损害可读性，但作为个人品味，我总是找到;

return (x + 1);

和C和C ++代码类似，非常恼人。

Answer 8

如果方法不接受参数，为什么需要空()来调用method()？我相信你不需要这样做。

在程序中使用括号会降低可读性的一些示例是什么？

8 个答案: