true-false or false-true
-
I do the same - if only because the "failure case code" is generally shorter:
MessageBox.Show("...", "...");
return;And it's more obvious what is going on that way. Plus ... it's a layer less indentation:
if (goodThing)
{
...
}
else
{
MessageBox.Show("...", "...");
return;
}Vs:
if (!goodThing)
{
MessageBox.Show("...", "...");
return;
}
...And it groups validations at the top of methods, leaving the "good code" alone at the end:
if (!goodThing)
{
MessageBox.Show("...", "...");
return;
}
if (!otherThingIWantToSee)
{
MessageBox.Show("...", "...");
return;
}
...Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
I once had to adhere to a rather arcane coding standard that required only one return statement per function. It made for some very deep indentation so I resorted to using many more very small functions. It's a bit less of an issue now with very high resolution monitors but back then it was very annoying.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
I do the same - if only because the "failure case code" is generally shorter:
MessageBox.Show("...", "...");
return;And it's more obvious what is going on that way. Plus ... it's a layer less indentation:
if (goodThing)
{
...
}
else
{
MessageBox.Show("...", "...");
return;
}Vs:
if (!goodThing)
{
MessageBox.Show("...", "...");
return;
}
...And it groups validations at the top of methods, leaving the "good code" alone at the end:
if (!goodThing)
{
MessageBox.Show("...", "...");
return;
}
if (!otherThingIWantToSee)
{
MessageBox.Show("...", "...");
return;
}
...Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionOne
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionAlways go for what is, not what is not, if possible. Less mental boggling, that way.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Ravi Bhavnani wrote:
But shouldn't it be "Token received" if token isn't
Guid.Empty?A perfect illustration of the mental gymnastics involved here. :)
Assert.IsTruedisplays the message if the assumption isn't met.Assert.IsTrue(token != Guid.Empty, ...displays the message iftoken == Guid.Empty, meaning that "token not received" is the correct message.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Gaaah! :-O I'm going to blame it on lack of caffeine, even though the real reason is sheer stupidity. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I once had to adhere to a rather arcane coding standard that required only one return statement per function. It made for some very deep indentation so I resorted to using many more very small functions. It's a bit less of an issue now with very high resolution monitors but back then it was very annoying.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
An adamant refusal to use GOTO :laugh:
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionI always prefer a positive comparison rather than negative so I prefer the first. Except the "IsFalse" kinda does my head in. How about
Assert.IsNotTrue(token == Guid.Empty, "Token not received.");
*head explodes*
cheers Chris Maunder
-
An adamant refusal to use GOTO :laugh:
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Using goto was forbidden. It was in C++ so that had something to do with it. The irony of it was they had this arcane and tedious coding standard and used a library they wrote themselves that was utterly atrocious. It is easily the worst library I have ever had to deal with. Here's one little tidbit : the whole thing was built around a state machine that changed states by throwing an exception. :wtf: I would have to work really hard to come up with a design worse than that.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionJust thinking outside of the box here...
Assert.NotEqual(token, Guid.Empty, "Token not received");
:D
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Ravi Bhavnani wrote:
But shouldn't it be "Token received" if token isn't
Guid.Empty?A perfect illustration of the mental gymnastics involved here. :)
Assert.IsTruedisplays the message if the assumption isn't met.Assert.IsTrue(token != Guid.Empty, ...displays the message iftoken == Guid.Empty, meaning that "token not received" is the correct message.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
perfect illustration of the mental gymnastic
Or, perfect illustration of the twisted minds that defined 'Assert semantics :wtf:
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionI prefer the second... I often find myself doing (in C++ unit tests) ```C++ ASSERT(!some_condition); ``` or ```C++ ASSERT(some_condition == false); ``` rather than ```C++ ASSERT_FALSE(some_condition); ``` Same thing, really, but as you say, there's an unconscious desire to be positive, I guess.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionI always chose "!=" over "==", as an habit of the embedded world where == is forbidden by implicit rules due to the possible mistake with =.
-
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionI would prefer something that rings true and has an explanation when it fails. Assert.IsTrue(TokenIsValid(token), "Invalid Token: "+ TokenCheck(token)); TokenCheck would say "Empty", "Wrong Length...must be 4 bytes" (or whatever), "Exceeds limits of 0-100"...etc.... Mike
-
An adamant refusal to use GOTO :laugh:
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Mycroft Holmes wrote:
use GOTO
Burn the heretic!
Software Zen:
delete this; -
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionMarc Clifton wrote:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
Assert.IsTrue(token != Guid.Empty, "Token is empty (not received).");
:-D The sense of the description now matches that of the assertion.
Software Zen:
delete this; -
Using goto was forbidden. It was in C++ so that had something to do with it. The irony of it was they had this arcane and tedious coding standard and used a library they wrote themselves that was utterly atrocious. It is easily the worst library I have ever had to deal with. Here's one little tidbit : the whole thing was built around a state machine that changed states by throwing an exception. :wtf: I would have to work really hard to come up with a design worse than that.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
I prefer the second... I often find myself doing (in C++ unit tests) ```C++ ASSERT(!some_condition); ``` or ```C++ ASSERT(some_condition == false); ``` rather than ```C++ ASSERT_FALSE(some_condition); ``` Same thing, really, but as you say, there's an unconscious desire to be positive, I guess.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
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!
-
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take Exception -
Which do you prefer: Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false
==into a true!=. With Option 1, I don't have to do that. Interesting how the mind works. Maybe a psychopath would go for option 2? ;PLatest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionFor me, it depends. 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.
-
Seen it; rewrote it. In (pre-Visual) BASIC code (ON ERROR GOTOs that would branch to different line labels depending on the ERRNO thrown) for nuclear weapons effects. Guess it's fitting, in retrospect, that "bomb code" worked by "blowing up" :)
That's an interesting coincidence. At the same job where I used that horrendous library the company built robots. They used Microsoft's BASIC as the embedded language and it had that ON ERROR stuff in it. It could get very tricky and downright dangerous when an emergency stop was activated because there was no telling where the robot would go next when the stop was cleared.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
