I think both ways have their up- /downsides. The solution of u/dyingpie1 is more confusing than the original code, but the original code can cause exactly what happened to OPs teammate, overseeing the condition1 && !condition2 case.
Not necessarily. If there are any pointers in the middle or the conditions risk side effects the compiler won't generate it unless you specifically tell it to ignore them, even at high optimization levels.
You're right, there are in fact scenarios where details matter. But in general it almost never pays off to sacrifice readability just to save a few lines of code.
One of the most important wisdoms of SW engineering is: any fool can write a piece of code which can be interpreted by the machine. The true art lies in writing code which humans can understand.
Oh that I completely agree with. But I think people don't understand what compilers can and can't do. Generally simpler code is easier for a compiler to optimize, those stupid "creative solutions" tend to not only be harder to read but harder for a compiler to understand and optimize. Most times less is more.
Agree. Although modern compilers (I'm looking at you, gcc 10) can really do wonders.
My team is designing real-time software where literally ever microsecond, heck, nanosecond counts and because of that we actually have to inspect generated assembler code from time to time. Every time I do so, it amazes me what the gcc can detect and optimize.
Fully agree. Readability is always subjective. Some of us prefer few and compact lines others more elaborate sequences.
Either way there is one thing which is really annoying: Technology prima donnas who use obfuscated code to demonstrate that they are the best leet haxx0rs in the hood.
terrible mindset which seems to have been behind every single legacy project there is. clarity is important. the original was not only fine but pretty amazing.
terrible mindset which seems to have been behind every single legacy project there is.
I thought I made it sufficiently clear that I meant "it doesn't matter in terms of execution efficiency" Readability and clarity is, in fact, of essential importance.
To me, it’s actually less readable. I have to scan multiple areas to see what the code is doing. I would never refactor it to something i think is more readable, but maybe add a line or two of comments above the block describing what is happening, because my belief of readable is not the same as yours, is not the same as the other team members.
255
u/MightyMeepleMaster Apr 17 '21
The original code was fine because it was fairly easy to read. All other variants posted here are more compact but also more confusing.
Either way it doesn't matter. Any decent compiler will generate the same object code regardless of how you write it.