51–60 of 82 posts
Old CS students' prank: improving the "no food and drink" sign unsurprisingly often found in labs by scribbling "no (food && drink) == (no food || no drink)" on it.
Earlier quoted context omitted.
Not not x is equivalent to x using the double negation rule (DN). "Not signed out" can be rephrased as "not not signed in" and thus simplified to "signed in". Same for "not untrusted ip" equaling "not not trusted ip" and, after DN, simply "trusted ip". It's completely logical, so I'm not sure what your point is. Perhaps the article should have explained this better.
The fact that "signed out" and "signed in" are opposites is not a logical fact; there's no general inference from "not p_out" to "p_in". If you had "outside" and went from !outside?" to "inside?", that would be erroneous (you could also be on the threshold). ETA: this is especially obvious for trusted/untrusted; it doesn't have to be the case that every ip is either positively trusted or positively untrusted. If, in…
Suffice to say that it contains such tips as avoiding negation in conditionals.
In the end it boils down to strategic optimization towards readability with the least mental overhead (the cycles you spend parsing, the more you can spend thinking).
Experience then teaches that if the expression is complicated enough for that to matter, you've already lost. Instead, make a boolean function with explicit "short circuit" returns.
// return true if we're screwed
isScrewed ( relevant parameters...):
if failure-mode-one:
return true
if failure-mode-two:
return true
if guaranteed-save-otherwise:
return false
if failure-mode-three:
return true
return false
Now if I could just get coworkers to stop writing "fooFlag == true" and "fooFlag == false" :-)
Earlier quoted context omitted.
Interestingly I've been going back and forth on this lately. I have been playing around with SD cards on the STM32F4 and a typical SD Card transaction consists of 3 to 10 commands which, if any one fails, the transaction fails. I'm currently using negative conditionals of the form "Not Error" (the Error test is an affirmative, and so that seems ok to me) A typical sequence is like the one to set the bus width. err =…
What I've found myself doing in such cases is adding a function that processes multiple commands and indicates an error if any one of the commands failed (sdio_batch could be a varargs function): struct sdio_cmd { enum { SDIO_SELECT, SDIO_COMMAND } cmd; int reg; // Guesses at suitable names without int val; // knowing anything about SDIO } int sdio_batch(int count, ...); err = sdio_batch(3, &(struct sdio_cmd){ SDIO_S…
int do_command(sdio_command_chain *cmd) {
int err = 0;
if (cmd->next) {
err = do_command(cmd->next);
}
return (err) ? err : call_command(cmd->parms);
}
This is why every developer should read Code Complete - it contains a myriad of tips learnt through many years of hard work. Suffice to say that it contains such tips as avoiding negation in conditionals. In the end it boils down to strategic optimization towards readability with the least mental overhead (the cycles you spend parsing, the more you can spend thinking).
Earlier quoted context omitted.
What the sign clearly means is "no [members of the set] food and drink."
But what the sign says is either "no(food && drink)" or "no(food) && drink", depending on how you feel about precedence. The obvious implication in the first case is that either food or drink, or neither, but not both, is permissible; in the second, it's that drink is acceptable only when not also accompanied by food, but no other constraint is expressed with regard to either. If the intent was to express that neithe…
Earlier quoted context omitted.
Except where writing negative conditionals are clearer. For example turning: if(a) { if(b) { if (c) { // Do something. } } } Into: if(!a) { } elseif(!b) { } elseif(!c) { } else { // Do something. }
Interestingly I've been going back and forth on this lately. I have been playing around with SD cards on the STM32F4 and a typical SD Card transaction consists of 3 to 10 commands which, if any one fails, the transaction fails. I'm currently using negative conditionals of the form "Not Error" (the Error test is an affirmative, and so that seems ok to me) A typical sequence is like the one to set the bus width. err =…
In the case of cleanup that must be done in the end, perhaps 2 functions would be better: a top level func to acquire and dispose of resources, calling an inner func to do as much work as it can with the resources. (assuming something like C that doesn't have a "finally" clause like Java)
I've never understood how finding the end of a long / nested mess of if/else blocks, rather than leaving the function, is somehow better. Which one feels more like a GOTO in terms of least astonishment?
Earlier quoted context omitted.
Except where writing negative conditionals are clearer. For example turning: if(a) { if(b) { if (c) { // Do something. } } } Into: if(!a) { } elseif(!b) { } elseif(!c) { } else { // Do something. }
Or if (a && b && c) { // Do something. }