The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
If you prefer to compare a logical expression to a logical constant (true, false), then I beg to disagree!
Do you ask someone: Is it true that you want a cup of coffee? Or do you ask: Do you want a cup of coffee?
You reserve the "Is is true that" form to very special cases, like: Is is true that you love me?
So "== true" or "== false" is completely banned from any code that I handle!
From my "programming childhood" I was brought up to write every funcition as a (1) verify all arguments and preconditions, (2) do the work, (3) prepare the results.
If in step 1 any precondition is not satisfied, then you prepare an error return and get out of there, making no changes. Don't even look at the work and result stages.
If anything in step 2 prevents you from creating a complete result, then you prepare an error return and get out of there, without any side effects or other kinds of results.
In step 3, with all preconditons met and all work successfully completed, you do whatever possible to preserve the results (e.g. wait for locks to be released). If all functions are written in this orderly manner, you very rarely run into problems in this step.
These "Get out of there" tests are usually semantically negative, even though they may be syntactically positive ("if (parameter outside legal range) ..."). The essential part is: Don't bother the clean work with debris (I count "n" levels of extra indentation due to validity checks as "debris"!). If there is nothing more you can do, then leave!
Any test that ends up in an abort/termination is placed as early as possible - and then there is no "else" and no extra indentation.
Within step 2, and sometimes even in step 1, the "if" selects one of two equally valid actions, or they are elseif-alternatives. In such cases, I write the test so that the most likely case comes first (even when that requieres negation of the logical expression). An elseif-sequence is ordered in decreasing likelyhood. The final else is the least likely one - like a default at the end of a switch case statement.
After an almost 4 month hiatus, I'm finally back to article writing. The last 4 months have been something of a nightmare turned reality, starting the week before Easter. Part of the hiatus involved my mother being diagnosed with heart disease, high blood pressure, high cholesterol, and diabetes. She's doing much better now, but it didn't look good for a while. First time diagnosis (at 89) for her, she hates going to the doctor, even though she used to be an OR nurse! Perhaps because she has been a nurse!
The other part of the hiatus involves me personally, and I'm happy to share, but you'll have to email me directly as the content is not really lounge appropriate (that'll raise some eyebrows!)
I consider everyone here to be part of my larger "digital community", and through the last 4 months I have also been graced with amazing community support where I live. I can't emphasize enough how important it is to be surrounded by loving friends during times of crisis. To paraphrase a cliche, keep your friends close and the crazies far, far away, in another galaxy.
While the emotional healing continues, I feel like I've finally regained enough of a foundation to stand on and start letting the creative juices flow again. I've really missed that!
Thanks for reading and thanks to Code Project for creating the connections to the people here that I relied on for some stability amidst all the turmoil, even though ya'll didn't know it.