是否可以通过括号来防止死亡?
有时,我会编写一些带有比我喜欢的更多括号的代码。
if(!(new Day((((new Date()) / millisecondsPerDay) % 75)) instanceof oldDay))) {
// Bonus points if that condition made any sense to you
}
很难跟踪我需要放置多少个括号,尤其是当我使用的 IDE 没有在出现问题时立即告诉我时。事实上,我敢打赌上面的例子与括号不正确匹配。我被括号中的死亡错误所钉住的次数比我愿意承认的还要多。
我想知道是否有办法规避这个问题。我可以使用哪些技术来避免用这么多括号括起来?
是否有任何语言具有不需要这么多括号的机制?例如,我认为添加自动关闭括号的特殊字符和自动打开它们的特殊字符可能会有所帮助。 (以下示例中的 <
和 >
)
if(!(new Day<new Date()) / millisecondsPerDay) % 75> instanceof oldDay>
Occasionally, I will write some code with way more parentheses than I like.
if(!(new Day((((new Date()) / millisecondsPerDay) % 75)) instanceof oldDay))) {
// Bonus points if that condition made any sense to you
}
It is hard to keep track of how many parentheses I need to put, especially when I'm not using an IDE that immediately tells me when something is wrong. In fact, I bet the above example doesn't match the parentheses correctly. I've been pegged with errors from death by parentheses more than I would like to admit.
I was wondering if there was a way to circumvent this. What techniques can I use to avoid having to wrap things with so many parentheses?
Are there any languages with a mechanism that prevent the need for so many parentheses? For example, I thought adding special characters that automaticall close parentheses and one that automatically opens them might help. (<
and >
in the following example)
if(!(new Day<new Date()) / millisecondsPerDay) % 75> instanceof oldDay>
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
一种可行的替代方法是在条件循环之前预先计算括号内的值。以您的代码为例:
让我们开始分解它。
请记住,代码是为人类阅读而编写的,然后才供机器执行。如果您发现巨大的条件语句,请开始预处理它们并将其分解。如果需要超过一秒钟才能弄清楚您正在检查的情况,那么它可能太长了。
One viable alternative is to precompute the parenthesized values before the conditional loop. Take your code for example:
Let's start breaking it up.
Remember that code is written for humans to read and only afterwards for machines to execute. If you find giant conditionals, then start preprocessing them and break it up. If it takes more than a second to figure out what your condition is checking, then it's probably too long.
嗯,首先我总是喜欢重构这种代码。如果可以的话,我将表达式的一部分提取到变量(或函数,以最适合的为准),那么您可以使代码本身更有意义,并且您不需要弄得这么混乱
编辑:逆波兰表示法
你哪个可以将
5 + ((1 + 2) * 4) − 3
变成这样的东西:5 1 2 + 4 * + 3 -
。当然这种形式可能很接近编译器中计算的堆栈表示。Well, first of all i always like to refactor this kind of code. If i can, i extract part of expression to the variable (or function, whichever suites best), then you can make more sense to the code itself, and you would'nt need to make such a mess
EDIT: By the way if you want to do something without parentheses you can try something like this: Reverse Polish Notation
Which you can make
5 + ((1 + 2) * 4) − 3
into this thing :5 1 2 + 4 * + 3 -
.Of course this form may be very close to stack representation of calculations in compilators.如果我遵循:
如果您无法读取内联逻辑...只需将其放在多行上! ;-)
If i follow:
If you can't read an inline logic... just put it on multiple line! ;-)
这么多括号很好地表明
作者不理解该语言的运算符优先级。例如,您将构造函数调用
new Date()
包装在一组完全冗余的括号(new Date())
中。除非您的语言与任何普通语言不同,否则前缀new
运算符将比几乎任何其他运算符绑定得更紧密。作者不关心可理解性。
使其更易于理解、可测试和可维护。下线的某个人(很可能是你,会为此感谢你……或者因为你不这样做而诅咒你)。
一些提示:
了解您的语言的运算符优先级。没有充分理由不要添加括号。真正了解运算符优先级的人必须花一些时间来弄清楚为什么你把这些括号放进去:你在这里做了一些不明显的事情吗?
分解表达式。使用堆栈空间(它很便宜)。
在前面的子表达式的基础上,将每个简单子表达式计算为独立的局部变量。
使变量名称反映它们所代表的内容。
然后只测试最后的临时的。在你的例子中,这看起来是一个布尔值。
这样编写代码很容易理解(没有复杂的表达式),也很容易测试(简单的表达式更容易检查正确性)。它可以更轻松地识别/定位问题。
That many parens is a pretty good indication that
The author doesn't understand the operator precedence of the language. For instance, you've wrapped a constructor invocation
new Date()
in a completely redundant set of parentheses(new Date())
. Unless your language is different than any normal language, that prefixnew
operator is going to bind tighter than almost any other operator.The author doesn't care about understandability.
Make it more understandable, testable and maintainable. Somebody down the line (who might well be you, will thank you for it...or curse you for not doing so).
Some hints:
Understand your language's operator precedence. Don't add parentheses without good reason. Somebody who does understand operator precedence has to spend some time figuring out why you put those parens in: are you doing something non-obvious here?
Break the expression up. Use stack space (it's cheap).
Compute each simple subexpression as an independent local variable, building on the previous ones.
make the variable names reflect what they represent.
Then test only the final temporary. In your case, that looks to be a boolean.
Writing code like that makes it easy to under stand (there are no complex expression), it makes it easy to test (simple expressions is much easier to check for correctness). It makes it easier to identify/locate problems.
我想说这个问题的答案是否定的,因为所有这些括号的全部目的是避免表达式中的歧义。如果删除它们,表达式可能不会按照您想象的方式进行计算。
因此,如果有像
<>
这样的构造来修复/添加丢失的括号,则可能不会将它们添加到您期望的位置。简单的例子(好像需要它一样):
...将评估为...
...或...
...并且您没有真正的方法知道它将是哪一个。
唯一的选择是将某些部分移到表达式之外,将结果存储在变量中,以便您可以在表达式中计算较少的值。
I would say the answer to this is NO, because the whole point of all those parentheses is to avoid ambiguity in the expression. If you remove them, the expression may not be evaluated in the way that you think it will.
Ergo, if there was such a construct as
<>
to fix/add your missing parens, if may not add them in the place you were expecting it to.Simple example (as if it were needed):
...will evaluate to either...
...or...
... and you have no real way to know which one it will be.
The only alternative is to move some of the parts outside your expression, store the results in variables so you can evaluate less in your expression.