Can death be prevented in parentheses?

Question

Sometimes I write some code with more brackets than I like.

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

It’s hard to keep track of how many brackets I need to put, especially when I don’t use the IDE, which immediately tells me when something is wrong. In fact, I'm sure the above example does not match the brackets correctly. I was tied to death errors with brackets more than I would admit.

I was wondering if there is a way around this. What methods can I use to avoid wrapping things with so many parentheses?

Are there any languages ​​with a mechanism that prevents the need for so many parentheses? For example, I thought about adding special characters that can help automatic closed parentheses, and automatically open them. ( < and > in the following example)

 if(!(new Day<new Date()) / millisecondsPerDay) % 75> instanceof oldDay> 

Answer 1

One viable alternative is to pre-comprehend the values ​​in parentheses 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 me start smashing it.

 Date d1 = new Date(); var factor1 = (d1 / millisecondsPerDay ) % 75; Day day1 = new Day (factor1); if (!day1 instanceof oldDay) { // do something } 

Remember that the code is written for people to read and only then to start machines. If you find giant conditional expressions, start pre-processing them and break them up. If you need more than a second to figure out what is checking your condition, then this is too long.

Answer 2

Well, first of all, I always like to reorganize this code. If I can, I extract part of the expression into a variable (or function, depending on which one is best suited), then you can make more sense for the code itself, and you won’t 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

What you can do 5 + ((1 + 2) * 4) − 3 into this thing: 5 1 2 + 4 * + 3 - . Of course, this form can be very close to representing a stack of computations in compilers.

Answer 3

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 the built-in logic ... just put it on a few lines !; -)

Answer 4

That many partners are a pretty good sign that

• The author does not understand the priority of the operator in the language. For example, you wrapped the constructor call new Date() in a completely redundant set of parentheses (new Date()) . If your language is no different from any normal language, this new prefix will bind more tightly than any other operator.

• The author does not care about comprehensibility.

Make it more understandable, verifiable, and maintainable. Someone down the line (who can be you, thank you for this ... or curse you for not doing this).

Some tips:

• Understand your priority as a language operator. Do not add parentheses for no good reason. Someone who understands the operator’s priority should spend some time figuring out why you put these parades: are you doing something unobvious here?

• Break expression up. Use stack space (it's cheap).

• Compute each simple subexpression as an independent local variable based on the previous ones.

• so that the variable names display what they represent.

Then check only the last temporary. In your case, it looks like a logical one.

Writing such code simplifies the setup (there is no complicated expression), this makes it easy to test (simple expressions are much easier to check for correctness). This makes it easier to identify / detect problems.

Answer 5

I would say that the answer to this is NO, because the whole point of all these parentheses is to avoid ambiguity in the expression. If you delete them, the expression may not be evaluated as you think.

Ergo, if there was such a construction as <> , to fix / add missing parsers if they cannot add them to the place where you expected.

A simple example (as if it were needed):

 (90 / 100 - 1) 

... will evaluate either ...

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

... or...

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

... and you have no real way of knowing which one will be.

The only alternative is to move some parts outside your expression, store the results in variables so that you can evaluate your expression less.