No, you were right the first time.

```
! => NOT
&& => AND
|| => OR
```

These operators have precedence. The above illustrates the order of operation. NOT after brackets, then AND, and finally OR.

```
if (A || B && ! C)
```

will evaluate `! C`

first so it will be a negated boolean.

Next, `B && ! C`

are evaluated. If `! C`

is `false`

, then this expression will be `false`

regardless what `B`

is. Finally we get to OR, and if `A`

is `true`

the expression will yield `true`

regardless what the rest does. If `false`

then the rest of the expression has to be `true`

for the final yield to be `true`

.

```
if ( (points == 10000000000 || points > 10000000000) && !gotAcheivement10 == false)
```

Your pattern above is,

```
if ((A || B) && ! C)
```

So it gets evaluated with brackets coming first.

```
aORb = A || B
```

and becomes,

```
if (aORb && ! C)
```

which now just has two steps to completion. Negate C and AND it with aORb. The yield is `true`

only if both operands are `true`

.

The question that came up in my mind is the necessity for all that in the first place. That’s why I simplified the line to just,

```
if (points >= 1E10 && ! gotAchievement10)
```

I used Scientific Notation to reduce possible errors with the huge numbers. Looking into the future, this line will lend itself to a dynamic handler that will elliminate all the if statements in that function. You’d be amazed how much we can still pare this code down.

That’s not the concern, just now. That you are getting a handle on logical operators and their expressions is all that really matters, for now. Once you have a good chunk of the language under your belt, your own mindset will drift in this direction, or your teacher will nudge you to take on a dynamic mindset rather than spaghetti code. There is nothing wrong with your code, so long as all the logic is correct.

You will have observed how different points of view arise and this gives us lots of playing room to sample various techniques. You should sample as many as you can get your hands on or dream up and dissect them to the minutest detail as you learn and review.

Nobody is expecting you to write your code like me. Take the good bits and leave what you don’t understand in favor of what you know already works. If you periodically come back around to old projects then that is perfect fodder for trying new things where the expectations are known, and clear. Be sure to save each revision so you can walk back if something goes wrong.