Personally, I'd use if (mode) when mode is a pointer or bool, and if (mode ==/!= something) otherwise. but that's just me.

Write for readability, let the compiler worry about the rest.

I hate typing but ... I use descriptive names and all the brackets and spaces I think are needed to make my code readable because the thing I hate more then typing is code I can't understand.

“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”
- Donald Knuth "The Art of Computer Programming"

Nope. Don't just sit in your armchair and think, try it.

There's now an easy way to test theories like that!

https://godbolt.org/

Spoiler: it makes no difference, and none of those variations cause any "special instruction" to appear.

Obviously, both variations get parsed into identical AST trees. Assembly generated from identical AST trees is identical.

1 members found this post helpful.

I don't think that I could have expressed the essential sentiment better than @geinst: (emphasis mine)

At the end of the day, "you are writing for the programmers who will follow you." Remembering that those programmers might have utterly no idea just who you are or were. (They won't be able to glean any insights from the grass atop your grave ...) Therefore, "clarity is the key."

Personally, if I encountered source-code such as "if (mode && (mode...", I would have preferred "even more clarity." I would have preferred that the "OP = Original Programmer" first, explicitly, have disposed of the case where "&mode" might have possibly referred to "nothing."

In my opinion, the case where "mode refers to nothing" is distinct from the case where "[mode refers to something and ...] mode does not equal newmode."

"TMTOWTSI ... There's More Than One Way To Say It.™"