It may be (relatively) hard work to swap round existing statements as prophylative against errors (that you might as well just check, for, and leave alone all those you found to be cofrectly done) but when syarting from scratch... It's not a useless
practice to get into doing automatically. Even back in the '80s when learning Pascal (where assignment was := and equivalence was = on its own) I heard advocacy of using the "if <static> is what <variable> is" construction, almost as a mantra. And in
that language I don't even recall it being a legal move that an assignment can be made
and its success (e.g. that it didn't fail due to being NaN or otherwise out of type, regardless lf overloading) then immediately appropriated by a branching/looping decision. I presume that the tutor concerned probably came to the habit from some different language.
Maybe that was C? In various C flavours, assignments occurring and then broadcasting truths about themselves are a valid (if occasionally dickishly obfuscating) shortcut. Maybe deprecated in more contemporary implementations. But, as an e.g., the perlish "while (my $nextline = <$filehandle>) {chomp $nextline; …}" is pretty much a commonly understood (if not globally used) convention for that language, even though TIMTOWTDI naturally still rules and countless other methods (with greatermor lesser readability) could be employed in its stead, even before going down the OO route.
(Though I think you
do get non-fatal warnings reported, if so "use"d, for "if ($x=$y) {…}" where it is likely a typo of ommitance. And I tend to default to "eq" instead of "==" in the appropriate (textish) circumstances, which removes the honest-typo issue for a downright fail error if I miss either character of "eq" and fail to spot it before running.)
Also, might aid readability:
Code: Select all
if (var1 == x*y) …
if (var2 == sqrt(width) …
if (var3a == funnyFunction(i,familyCounter,refRelTree) …
if (var3b != var3a) …