"You may have seen code which misunderstands how expressions work:
if isDelivered and isNotified: isDone = True else: isDone = false;
Instead of:
isDone = isDelivered and isNotified "
I think that's a matter of style, I prefer the isDone = isDelivered and isNotified style myself, and I think the people who write the other way have very poor style but as arrogant as that sounds I don't think I would be so arrogant as to say they don't know how expressions work.
This discussion reminds me of the ternary operators. I personally don't like using them except for very specific applications. Not because I don't know how they work, but because I think their overuse can lead to mistakes and maintenance issues as the conditional complexity grows. For simple statements, sure, but once you get into territory where you see 2 or 3 nested ternary statements with complex conditionals, it's easy to lose your mind (and much harder to follow the author's intent).
I'm with the other poster (humanrebar) too, in that one should strive toward writing maintainable code whenever possible. Make it clean and readable. The poor bugger who has to maintain it when you're gone will thank you!
First, it doesn't necessarily imply that someone writing code like this doesn't understand how expressions work. The author is trying to psychologically model people who code in this manner. I could similarly claim that the else there is unnecessary since the boolean is false by default. If it's a language that doesn't require variables to be declared first, I could claim that the assignment is itself unnecessary. I could then make a further claim that a person who codes like this doesn't understand expressions.
Second, the problem is taken out of context. What happens next? There'll be an if(else) statement somewhere to determine what happens next, and then the if(else) the author has painstakingly avoided will be back.
"isDone = isDelivered and isNotified" was written is because the programmer saw "if isDelivered and isNotified: isDone = True else: isDone = false;"
and thought I can improve that, then what they have done is managed to wrap the checking and assignment into one expression, they are logically now doing two things in the one line - it just so happens that they can do that because one of those things was not really necessary to do.
Taking that at face value results in something like Asm written in a high-level language: very short lines with not much on each one, and it's a pain to read and understand because you have to scroll two pages to see what could be accomplished in a dozen lines. I've seen code written in that style and it was not easy to work with. (What often goes along with that, "every function 'should do one thing and one thing only'", is even worse when taken to its logical conclusion --- it turns lots of scrolling into lots of jumping around.)
I don't have a lot of experience with programming so for now I do what I was taught.
Reading the code for lots of other successful open-source software will probably tell you far more useful things about how to write code than the "indoctrination" that passes for teaching these days. I'd recommend older codebases; the newer ones tend to unfortunately show the same bad habits due to the reasons above.