# Bracket Best Practices?

Hello! I just have a quick question: when is it appropriate/standard practice to include brackets to separate boolean expressions and why?

Below are a few examples of code given in the python code challenge for control flow.

NOTE: I was unable to include the image in this post because new users are only able to include 1 link per post. Please see the replies below for a full description of the problem.

1 Like

For instance, here is an example from the exercise, where there are brackets surrounding the second line of code in the function.

In my code, I did not use brackets, yet I still got the correct outputs - why might this be?

Also, once seeing the brackets in use, I switched to using them; however for the second line of code this time I used two brackets:

``````if (num >= lower) and (num <= upper):
``````

The answer only uses one larger bracket. But both my version and the one below give the same output. Why might this be and which one is more appropriate in standard practice?

Brackets are only needed for grouping to override precedence. There is no best practice other than not using what is not necessary. Know your precedence (order or operation) and determine if overriding is necessary to get the result you intend.

1 Like

Ah! Very interesting. Thank you for this, @mtf.
So what might be an instance of overriding precedence with brackets?

Say I had the following code:

``````if (num1 >= num2 or num1 < num3) not num1 < num2:
return num1
``````

Would the `or` operation be interpreted first - because it is in brackets?

2 Likes

Everything inside the brackets will be evaluated first, yes.

We should give your example a bit more analysis, just to be sure we’re clear what order things are actually happening in.

``````if (num1 >= num2 or num1 < num3) not num1 < num2:
``````

Clearly `()` is the top of the food chain so we’ll chop that one out, first.

``````(num1 >= num2 or num1 < num3)
``````

Membership operators have greater precedence than `or` so the first comparison is evaluated first. If that yields True it will short-circuit the OR that follows. If it yields False the yield will be determined in the second comparison.

So let’s call the yield of this portion, `A`.

Now we have,

``````A not num1 < num2
``````

Oops, the wheels just came off. Can you envision why?

2 Likes

Okay, this is a fantastic, detailed explanation – thank you!
I am just trying to figure out the question you pose at the end. As I think I am clear now if `num1` `>=` `num2` is in fact determined `False` it would pose a contradiction with the following `not` statement!
Is this what you intended to hint toward?

2 Likes

Not exactly. We’ll reserve A for a moment.

Consider,

``````not num1 < num2
``````

By precedence, `not num1` has a lower precedence than `num1 < num2` so if we call the latter, B, we have,

``````A not B
``````

The wheels are still off but now we have the simplest form given the evaluation process, thus far.

For tickles and giggles let A equal 0 and B equal 1.

``````0 not 1
``````

What is lacking is an operator that can see both sides of the `not`. NOT is unary, not binary. Its operand is on the right, not the left. The first operand is just an orphaned value with no meaning.

``````A and not B
A or not B
``````

See how that puts the wheels back on?

1 Like

Ah, I am beginning to see more clearly now ( I think). So what you are suggesting is that `not` by itself can not uphold a viable comparison (because it is unary), it would require another operator (such as `and` or `or`)?
Does that mean that both `and` and `or` are considered binary? Also, if we had:
`A and B`
or
`A or B`
would either of these work?
Are there other unary operators I should be aware of?

1 Like

Yes, that is correct.

Yes, they both have two operands.

In this regard, NOT is the only unary.

1 Like

Thank you so much for all your help! You’ve enriched my understanding of these concepts. So much to learn!

2 Likes