是否可以通过括号来防止死亡?

发布于 2024-12-01 18:42:42 字数 573 浏览 0 评论 0原文

有时,我会编写一些带有比我喜欢的更多括号的代码。

 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

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

评论(5

冷…雨湿花 2024-12-08 18:42:42

一种可行的替代方法是在条件循环之前预先计算括号内的值。以您的代码为例:

if(!(new Day((((new Date()) / millisecondsPerDay) % 75)) instanceof oldDay))) { 
    // Bonus points if that condition made any sense to you
 }

让我们开始分解它。

Date d1 = new Date();
var factor1 = (d1 / millisecondsPerDay ) % 75;
Day day1 = new Day (factor1);

if (!day1 instanceof oldDay) {
// do something
}

请记住,代码是为人类阅读而编写的,然后才供机器执行。如果您发现巨大的条件语句,请开始预处理它们并将其分解。如果需要超过一秒钟才能弄清楚您正在检查的情况,那么它可能太长了。

One viable alternative is to precompute the parenthesized values before the conditional loop. Take your code for example:

if(!(new Day((((new Date()) / millisecondsPerDay) % 75)) instanceof oldDay))) { 
    // Bonus points if that condition made any sense to you
 }

Let's start breaking it up.

Date d1 = new Date();
var factor1 = (d1 / millisecondsPerDay ) % 75;
Day day1 = new Day (factor1);

if (!day1 instanceof oldDay) {
// do something
}

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.

等你爱我 2024-12-08 18:42:42

嗯,首先我总是喜欢重构这种代码。如果可以的话,我将表达式的一部分提取到变量(或函数,以最适合的为准),那么您可以使代码本身更有意义,并且您不需要弄得这么混乱

bool isOldDay(int someFactor)
{
    if(someFactor instanceof oldDay) 
    {
        return true;
    }
    return false;

}

var today = new Date();
var particularFactor = today/millisecondsPerDay;
var someFactor = particularFactor % 75
var day = new Day(someFactor);


if(!isOldDay(day)) //Do something

编辑:逆波兰表示法

你哪个可以将 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

bool isOldDay(int someFactor)
{
    if(someFactor instanceof oldDay) 
    {
        return true;
    }
    return false;

}

var today = new Date();
var particularFactor = today/millisecondsPerDay;
var someFactor = particularFactor % 75
var day = new Day(someFactor);


if(!isOldDay(day)) //Do something

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.

写给空气的情书 2024-12-08 18:42:42

如果我遵循:

var a = new Date() / millisecondsPerDay) % 75
var newDay = new Day(a);

if (! newDay instanceof oldDay) {
   //do something
}

如果您无法读取内联逻辑...只需将其放在多行上! ;-)

If i follow:

var a = new Date() / millisecondsPerDay) % 75
var newDay = new Day(a);

if (! newDay instanceof oldDay) {
   //do something
}

If you can't read an inline logic... just put it on multiple line! ;-)

鹿! 2024-12-08 18:42:42

这么多括号很好地表明

  1. 作者不理解该语言的运算符优先级。例如,您将构造函数调用 new Date() 包装在一组完全冗余的括号 (new Date()) 中。除非您的语言与任何普通语言不同,否则前缀 new 运算符将比几乎任何其他运算符绑定得更紧密。

  2. 作者不关心可理解性。

使其更易于理解、可测试和可维护。下线的某个人(很可能是你,会为此感谢你……或者因为你不这样做而诅咒你)。

一些提示:

  • 了解您的语言的运算符优先级。没有充分理由不要添加括号。真正了解运算符优先级的人必须花一些时间来弄清楚为什么你把这些括号放进去:你在这里做了一些不明显的事情吗?

  • 分解表达式。使用堆栈空间(它很便宜)。

  • 在前面的子表达式的基础上,将每个简单子表达式计算为独立的局部变量。

  • 使变量名称反映它们所代表的内容。

然后只测试最后的临时的。在你的例子中,这看起来是一个布尔值。

这样编写代码很容易理解(没有复杂的表达式),也很容易测试(简单的表达式更容易检查正确性)。它可以更轻松地识别/定位问题。

That many parens is a pretty good indication that

  1. 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 prefix new operator is going to bind tighter than almost any other operator.

  2. 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 2024-12-08 18:42:42

我想说这个问题的答案是否定的,因为所有这些括号的全部目的是避免表达式中的歧义。如果删除它们,表达式可能不会按照您想象的方式进行计算。

因此,如果有像 <> 这样的构造来修复/添加丢失的括号,则可能不会将它们添加到您期望的位置。

简单的例子(好像需要它一样):

(90 / 100 - 1)

...将评估为...

((90 / 100) - 1) // = -0.1

...或...

(90 / (100 - 1)) // = 0.90909090...

...并且您没有真正的方法知道它将是哪一个。

唯一的选择是将某些部分移到表达式之外,将结果存储在变量中,以便您可以在表达式中计算较少的值。

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

(90 / 100 - 1)

...will evaluate to either...

((90 / 100) - 1) // = -0.1

...or...

(90 / (100 - 1)) // = 0.90909090...

... 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文