true-false or false-true
-
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 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 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 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 ExceptionI 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
-
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 -
I always have a tendency to put positives first, eg.
if (thing == true)
{
// do ok thing.
}
else
{
// error message
}...so, obviously, I would go for "Assert.isTrue".
- I would love to change the world, but they won’t give me the source code.
-
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
