true-false or false-true
-
I also prefer #1. But shouldn't it be "Token received" if token isn't
Guid.Empty? :) /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
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
-
In most cases I put the conditions which prevent code execution (like error cases) first and the condition in which the code must execute comes last.
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 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
