MSDN states that SSRS will evaluate both the true and false part of an Iif statement regardless of which one is returned. This seems to make Iif completely useless in regard to error avoidance. In other words, you cannot use Iif to skirt around an error, so essentially any operation you choose to include must always be valid regardless of the conditions. Honestly, what good is this?
So my question is... Does SSRS have other ways of evaluating conditions besides Iif?
Here is my example. I just want to be able to return Left without grabbing the first character of the match.
=Iif
(
InStr(Fields!SearchField.Value, Fields!Criteria.Value) <= 1,
"",
Left(Fields!SearchField.Value, InStr(Fields!SearchField.Value, Fields!Criteria.Value)-1)
)
However, what is happening here is that InStr(Fields!Criteria.Value, Fields!Criteria.Value)-1 is evaluating to 0 in some cases, which is perfectly fine until the FALSE part of the statement tries to deduct 1 from it and pass it into the InStr function. InStr cannot accept -1 as the number of characters to return.
An oversimplification of this is as follows. Assume you have a situation where Value can never fall below 0 without throwing an error.
Iif (Value > 0, Value = Value -1, 0)
Trying to use Iif to force the value not to fall below 0 does not work because all of these statements get evaluated even if they do not meet the conditions.
Trying to use InStr to get an index on a match, and Left to build a substring based on that index fails because of this. I have no idea how to completely avoid the condition.
I too thought Switch would work, but upon testing it did not. As far as I can tell, custom code is the only way to go. I tested the function below which worked for my few test cases.
Public Function TruncateWord(ByVal str As String, ByVal criteria As String) As String
If str.Contains(criteria) Then
Return Left(str, InStr(str, criteria) - 1)
Else:
Return ""
End If
End Function
I tested with the below 5 basic strings, searching for "d", and got the following results:
+-----------------+
| String | Result |
+-----------------+
| asdf | as |
| asd | as |
| as | |
| da | |
| ad | a |
+-----------------+
So this appears to work for all 3 possible cases (InStr returns > 1, InStr returns 1, and InStr returns 0) from my limited testing.
Here is the final result from C Black's suggestion to use custom code. I had eventually hoped to use the segment of the string to format the match in a different color in the opposite column. I had to add some html tags. It works perfectly. Thank you all for your assistance.
Code block:
Public Function ParseMatch (ByVal FullString As String, ByVal Criteria As String) As String
Dim Segment(2) As String
Dim Result As String
If FullString.ToUpper.Contains(Criteria.ToUpper)
Segment(0) = Left(FullString, InStr(Ucase(FullString), Ucase(Criteria) )-1 )
Segment(1) = Criteria
Segment(2) = Right(FullString, Len(FullString) - Len(Segment(0)) - Len(Criteria))
Result = Segment(0) & "<b><FONT color=blue>" & Segment(1) & "</FONT></b>" & Segment(2)
Else
Result = FullString
End If
Return Result
End Function
Report cell:
=Code.ParseMatch(Fields!Defendants.Value, Fields!Firm_Client_Name.Value)
If the name is found in the list of defendants, it colors the text blue in that field and bolds it.
Use SWITCH
SWITCH stops evaluating expression as soon as the first True is found. Switch works with pairs (an expression to evaluate and a result if it's true). The final True acts like an else.
=SWITCH
(
InStr(Fields!SearchField.Value, Fields!Criteria.Value) <= 1, "",
True, Left(Fields!SearchField.Value, InStr(Fields!Criteria.Value, Fields!Criteria.Value)-1)
)
I rewrote it for readability:
=Switch
(
InStr(Fields!Defendants.Value, Fields!Firm_Client_Name.Value) = 0, "",
InStr(Fields!Defendants.Value, Fields!Firm_Client_Name.Value) = 1, "",
True, Left(Fields!Defendants.Value, InStr(Fields!Defendants.Value, Fields!Firm_Client_Name.Value)-1)
)
' 0 = Error
' 1 =
' >1 = substring based on criteria
1 and >1 are correct, but I still get the error when the InStr evaluates to 0.
The thing is, I have to tell the Left function -1 or it will return the first letter of the delimiter, which I do not want. Even though the condition of InStr(Fields!Defendants.Value, Fields!Firm_Client_Name.Value) = 0 is true, instead of returning "" for the column, it returns an error. This tells me it is still being evaluated despite it being outside of the specified condition.
If I omit the -1 within the Left function, no error results. Yet I get substring + first letter of delimiter.
I work with sensitive information, so I cannot give specific results of the strings.
I want to save a true/false in my MySQL database. I'm saving 1/0 in an INT column to do this. When I select it, I get the 1 or 0, but I want it to return true/false to my PHP code, without having to rewrite the database.
Can I use another column type? Should I save it differently?
Update: My question is about not wanting to rewrite the returned value. I'm getting a lot of results from my database. Many of those are true/false, but some are 0s because the price is 0, so I don't want to universally rewrite all 1s and 0s. I also don't want to manually rewrite 10 columns.
To follow up my comment, here's a more detailed response which also covers the PHP side, although this probably belongs on StackOverflow.
I've always just used tinyint, although you can use bool/boolean which are synonyms for tinyint(1)
However as of MySQL 5.0.3 you can use the bit type:
As of MySQL 5.0.3, the BIT data type is used to store bit-field values. A type of BIT(M) enables storage of M-bit values. M can range from 1 to 64.
Next, assuming you have an active column, perhaps to store if a user is active, you could use PHP's automatic type conversion to handle this quite simply.
// Obviously you'd replace this with your database call
$results = [['active' => 1], ['active' => 0]];
foreach($results as $row) {
if ($row['active'] == true) {
echo "true\n";
}
else {
echo "false\n";
}
}
You don't strictly need to do anything.
PHP does not, and can not, use strongly typed variables. So, if you receive an (int) 1 from your query results, you can simply use this 1 as a boolean without rewriting or changing anything.
$intOne = (int) 1; //explicitly treat the variable as an integer
var_dump((bool) $intOne); //treat the variable as a boolean
When used in any boolean context, like if ($variable)... then any of these types will be considered to be false by PHP:
the boolean FALSE itself
the integer 0 (zero)
the float 0.0 (zero)
the empty string, and the string "0"
an array with zero elements
an object with zero member variables (PHP 4 only)
the special type NULL (including unset variables)
SimpleXML objects created from empty tags
... And, most importantly;
Every other value is considered TRUE (including any resource).
Source: PHP Manual > Booleans (english)
So while you can change the storage type of your column in mysql, this won't really change the way PHP handles the variable retrieved from your results at all.
Historically, I've always used a column of type TINYINT(1) to store boolean values in mysql, and as Tom Green points out, recent mysql versions provide a new BIT type, which might be appropriate. To the best of my knowledge, mysql does not currently have an actual boolean data type.
You could just as easily use a column of type VARCHAR(1), though, because PHP can and will use any value as a boolean, thanks to the glorious, majestic, and sometimes maddening, PHP Type Juggling.
If you're trying to use the values you're retrieving for boolean logic, just use the values you receive from mysql like booleans and it will work:
if ($valueFromResults) {
//The value was something like true
} else {
//The value was something like false
}
If you're trying to actually echo out the words "true" and "false", then you're probably best served by explicitly echoing the words out yourself, like this;
if ($valueFromResults) {
echo "true";
} else {
echo "false";
}
or, in my preferred shorthand;
echo ($valueFromResults) ? "true" : "false" ;
Update You mentioned in a comment that you want to pass the values through json_encode() and use them in javascript.
JavaScript treats any real value, like int 1, as true and any empty value, like int 0, or an empty string, as false. So if your json_encode() output gets used in actual JavaScript, the int values will still work as boolean values. So the integer values from your database should still work as they are.
Just check that your integer results are encoded as integers by PHP and not as strings - they should be encoded correctly by default - because "0" == true in javascript, but 0 == false.
For a boolean value (true/false), you should use the mySql type bit or tinyint(1).
$boolean = $mysql_data ? true : false;
I wanted to look for records where a certain string field was not blank or null, so I simply wrote SELECT ... FROM myTable WHERE x, assuming that blank and null strings would evaluate to false, but that doesn't appear to be the case.
The string "02306" is true, whereas "N06097EIP" is somehow false.
What's going on?
Edit: I'm aware of the workarounds, I simply want to know how the casting works.
In these expression string are first converted to numbers. "02306" is converted to 2306 which is >0 and therefore considered true, while "N06097EIP" (starting with non-digit) is converted to 0, which is evaluated as false.
Compare results of:
select convert("N06097EIP",signed)
and
select convert("02306",signed)
In a boolean context, such as
WHERE x
the expression x will be evaluated as an integer value. Note that MySQL considers a BOOLEAN as a numeric type.
http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html
It doesn't matter what type the expression x is; it's either an INTEGER type, or it will be converted to an INTEGER type, according to the documented conversion rules.
The end result is that the expression x will be evaluated to be either NULL, integer zero, or integer non-zero.
And those correspond to the boolean "truthiness" values of NULL, FALSE and TRUE.
The reason '02306' is considered TRUE is because this string converts to integer value 2306, which is non-zero.
The reason 'N06097EIP' is considered FALSE is because this string converts to integer value 0.
To can run a simple test case to verify:
SELECT IF( 0 = 'N06097EIP', 'is zero', 'is not zero')
SELECT 0 = 'N06097EIP'
The behavior you observe is entirely expected. It's all pretty straightforward. You may have been caught unawares, because the normative pattern is for us to avoid this type of evaluation and to instead use "workarounds" (as you put it) to return a boolean.
Don't try to be too cute about this with syntactic shortcuts. If nothing else, it's always harder on the next developer who has to figure out what you were doing.
Just spell out what you want.
SELECT *
FROM myTable
WHERE x IS NOT NULL AND x <> '';
or, if you'd prefer:
SELECT *
FROM myTable
WHERE COALESCE(x, '') <> '';
Just wanted to know if someone can explain the difference between these two conditionals:
if ( !object )
if ( object == null )
where object is an instance of a user-defined class.
I'm sure that these two cannot be used in an interchangeable manner, or are they?
Thanks.
The effect is in practice the same, so I guess you could say they're interchangeable.
In a boolean context (such as a conditional), an expresion is evaluated to either true or false.
In Actionscript 3.0, the following values evaluate to false:
false
null
0
NaN
"" (the empty string)
undefined
void
Everything else evaluates to true.
A reference to an user-defined class instance can either be null or not null.
So, in this case:
if ( object == null )
Obviously, the condition is met only if object is null.
In this other case:
if ( !object )
The expression object will evaluate to false if object is null. If it is null, the expression is false. Since this is in turn negated, the final value will be true and so the condition will be satisfied. So, just like in the first case, if object is null, the condition is met. And like in the first case, again, if object is not null, the condition is not met.
There's no other option if your variable is typed to a user-defined class; such a variable can only contain a valid reference or null; i.e. it can't hold any value evaluable to false in a boolean context, except for null; so, again, it's either null or not null. Which is why both code samples have the same effect.
The first is making a boolean comparison. If the object is false, the not(!) operation will make the condition true, if the object has a value other than false the statement will fail.
The second conditional is evaluating if the object has the value of null or not.
The reason these may be interchangeable is that various languages allow some equivalence between 0, false, null (or "\0") and other values of similar meaning.
I do not know actionscript, but testing equivalence of false, null, 0 etc., or reading the docs on boolean values, will be of some benefit.
Sure not :)
The first one means that the proposition is true only if different from the object;
The second one is true only if the object equals to null.
"!" means "is not the object"
"==" means that the the object has to have the value equal to the one at the right of the symbol
I keep seeing code that does checks like this
if (IsGood == false)
{
DoSomething();
}
or this
if (IsGood == true)
{
DoSomething();
}
I hate this syntax, and always use the following syntax.
if (IsGood)
{
DoSomething();
}
or
if (!IsGood)
{
DoSomething();
}
Is there any reason to use '== true' or '== false'?
Is it a readability thing? Do people just not understand Boolean variables?
Also, is there any performance difference between the two?
I follow the same syntax as you, it's less verbose.
People (more beginner) prefer to use == true just to be sure that it's what they want. They are used to use operator in their conditional... they found it more readable. But once you got more advanced, you found it irritating because it's too verbose.
I always chuckle (or throw something at someone, depending on my mood) when I come across
if (someBoolean == true) { /* ... */ }
because surely if you can't rely on the fact that your comparison returns a boolean, then you can't rely on comparing the result to true either, so the code should become
if ((someBoolean == true) == true) { /* ... */ }
but, of course, this should really be
if (((someBoolean == true) == true) == true) { /* ... */ }
but, of course ...
(ah, compilation failed. Back to work.)
I would prefer shorter variant. But sometimes == false helps to make your code even shorter:
For real-life scenario in projects using C# 2.0 I see only one good reason to do this: bool? type. Three-state bool? is useful and it is easy to check one of its possible values this way.
Actually you can't use (!IsGood) if IsGood is bool?. But writing (IsGood.HasValue && IsGood.Value) is worse than (IsGood == true).
Play with this sample to get idea:
bool? value = true; // try false and null too
if (value == true)
{
Console.WriteLine("value is true");
}
else if (value == false)
{
Console.WriteLine("value is false");
}
else
{
Console.WriteLine("value is null");
}
There is one more case I've just discovered where if (!IsGood) { ... } is not the same as if (IsGood == false) { ... }. But this one is not realistic ;) Operator overloading may kind of help here :) (and operator true/false that AFAIK is discouraged in C# 2.0 because it is intended purpose is to provide bool?-like behavior for user-defined type and now you can get it with standard type!)
using System;
namespace BoolHack
{
class Program
{
public struct CrazyBool
{
private readonly bool value;
public CrazyBool(bool value)
{
this.value = value;
}
// Just to make nice init possible ;)
public static implicit operator CrazyBool(bool value)
{
return new CrazyBool(value);
}
public static bool operator==(CrazyBool crazyBool, bool value)
{
return crazyBool.value == value;
}
public static bool operator!=(CrazyBool crazyBool, bool value)
{
return crazyBool.value != value;
}
#region Twisted logic!
public static bool operator true(CrazyBool crazyBool)
{
return !crazyBool.value;
}
public static bool operator false(CrazyBool crazyBool)
{
return crazyBool.value;
}
#endregion Twisted logic!
}
static void Main()
{
CrazyBool IsGood = false;
if (IsGood)
{
if (IsGood == false)
{
Console.WriteLine("Now you should understand why those type is called CrazyBool!");
}
}
}
}
}
So... please, use operator overloading with caution :(
According to Code Complete a book Jeff got his name from and holds in high regards the following is the way you should treat booleans.
if (IsGood)
if (!IsGood)
I use to go with actually comparing the booleans, but I figured why add an extra step to the process and treat booleans as second rate types. In my view a comparison returns a boolean and a boolean type is already a boolean so why no just use the boolean.
Really what the debate comes down to is using good names for your booleans. Like you did above I always phrase my boolean objects in the for of a question. Such as
IsGood
HasValue
etc.
The technique of testing specifically against true or false is definitely bad practice if the variable in question is really supposed to be used as a boolean value (even if its type is not boolean) - especially in C/C++. Testing against true can (and probably will) lead to subtle bugs:
These apparently similar tests give opposite results:
// needs C++ to get true/false keywords
// or needs macros (or something) defining true/false appropriately
int main( int argc, char* argv[])
{
int isGood = -1;
if (isGood == true) {
printf( "isGood == true\n");
}
else {
printf( "isGood != true\n");
}
if (isGood) {
printf( "isGood is true\n");
}
else {
printf( "isGood is not true\n");
}
return 0;
}
This displays the following result:
isGood != true
isGood is true
If you feel the need to test variable that is used as a boolean flag against true/false (which shouldn't be done in my opinion), you should use the idiom of always testing against false because false can have only one value (0) while a true can have multiple possible values (anything other than 0):
if (isGood != false) ... // instead of using if (isGood == true)
Some people will have the opinion that this is a flaw in C/C++, and that may be true. But it's a fact of life in those languages (and probably many others) so I would stick to the short idiom, even in languages like C# that do not allow you to use an integral value as a boolean.
See this SO question for an example of where this problem actually bit someone...
isalpha() == true evaluates to false??
I agree with you (and am also annoyed by it). I think it's just a slight misunderstanding that IsGood == true evaluates to bool, which is what IsGood was to begin with.
I often see these near instances of SomeStringObject.ToString().
That said, in languages that play looser with types, this might be justified. But not in C#.
Some people find the explicit check against a known value to be more readable, as you can infer the variable type by reading. I'm agnostic as to whether one is better that the other. They both work. I find that if the variable inherently holds an "inverse" then I seem to gravitate toward checking against a value:
if(IsGood) DoSomething();
or
if(IsBad == false) DoSomething();
instead of
if(!IsBad) DoSomething();
But again, It doen't matter much to me, and I'm sure it ends up as the same IL.
Readability only..
If anything the way you prefer is more efficient when compiled into machine code. However I expect they produce exactly the same machine code.
From the answers so far, this seems to be the consensus:
The short form is best in most cases. (IsGood and !IsGood)
Boolean variables should be written as a positive. (IsGood instead of IsBad)
Since most compilers will output the same code either way, there is no performance difference, except in the case of interpreted languages.
This issue has no clear winner could probably be seen as a battle in the religious war of coding style.
I prefer to use:
if (IsGood)
{
DoSomething();
}
and
if (IsGood == false)
{
DoSomething();
}
as I find this more readable - the ! is just too easy to miss (in both reading and typing); also "if not IsGood then..." just doesn't sound right when I hear it, as opposed to "if IsGood is false then...", which sounds better.
It's possible (although unlikely, at least I hope) that in C code TRUE and FALSE are #defined to things other than 1 and 0. For example, a programmer might have decided to use 0 as "true" and -1 as "false" in a particular API. The same is true of legacy C++ code, since "true" and "false" were not always C++ keywords, particularly back in the day before there was an ANSI standard.
It's also worth pointing out that some languages--particularly script-y ones like Perl, JavaScript, and PHP--can have funny interpretations of what values count as true and what values count as false. It's possible (although, again, unlikely on hopes) that "foo == false" means something subtly different from "!foo". This question is tagged "language agnostic", and a language can define the == operator to not work in ways compatible with the ! operator.
I've seen the following as a C/C++ style requirement.
if ( true == FunctionCall()) {
// stuff
}
The reasoning was if you accidentally put "=" instead of "==", the compiler will bail on assigning a value to a constant. In the meantime it hurts the readability of every single if statement.
Occasionally it has uses in terms of readability. Sometimes a named variable or function call can end up being a double-negative which can be confusing, and making the expected test explicit like this can aid readability.
A good example of this might be strcmp() C/C++ which returns 0 if strings are equal, otherwise < or > 0, depending on where the difference is. So you will often see:
if(strcmp(string1, string2)==0) { /*do something*/ }
Generally however I'd agree with you that
if(!isCached)
{
Cache(thing);
}
is clearer to read.
I prefer the !IsGood approach, and I think most people coming from a c-style language background will prefer it as well. I'm only guessing here, but I think that most people that write IsGood == False come from a more verbose language background like Visual Basic.
Only thing worse is
if (true == IsGood) {....
Never understood the thought behind that method.
The !IsGood pattern is eaiser to find than IsGood == false when reduced to a regular expression.
/\b!IsGood\b/
vs
/\bIsGood\s*==\s*false\b/
/\bIsGood\s*!=\s*true\b/
/\bIsGood\s*(?:==\s*false|!=\s*true)\b/
For readability, you might consider a property that relies on the other property:
public bool IsBad => !IsGood;
Then, you can really get across the meaning:
if (IsBad)
{
...
}
I prefer !IsGood because to me, it is more clear and consise. Checking if a boolean == true is redundant though, so I would avoid that. Syntactically though, I don't think there is a difference checking if IsGood == false.
In many languages, the difference is that in one case, you are having the compiler/interpreter dictate the meaning of true or false, while in the other case, it is being defined by the code. C is a good example of this.
if (something) ...
In the above example, "something" is compared to the compiler's definition of "true." Usually this means "not zero."
if (something == true) ...
In the above example, "something" is compared to "true." Both the type of "true" (and therefor the comparability) and the value of "true" may or may not be defined by the language and/or the compiler/interpreter.
Often the two are not the same.
You forgot:
if(IsGood == FileNotFound)
It seems to me (though I have no proof to back this up) that people who start out in C#/java type languages prefer the "if (CheckSomething())" method, while people who start in other languages (C++: specifically Win32 C++) tend to use the other method out of habit: in Win32 "if (CheckSomething())" won't work if CheckSomething returns a BOOL (instead of a bool); and in many cases, API functions explicitly return a 0/1 int/INT rather than a true/false value (which is what a BOOL is).
I've always used the more verbose method, again, out of habit. They're syntactically the same; I don't buy the "verbosity irritates me" nonsense, because the programmer is not the one that needs to be impressed by the code (the computer does). And, in the real world, the skill level of any given person looking at the code I've written will vary, and I don't have the time or inclination to explain the peculiarities of statement evaluation to someone who may not understand little unimportant bits like that.
Ah, I have some co-worked favoring the longer form, arguing it is more readable than the tiny !
I started to "fix" that, since booleans are self sufficient, then I dropped the crusade... ^_^ They don't like clean up of code here, anyway, arguing it makes integration between branches difficult (that's true, but then you live forever with bad looking code...).
If you write correctly your boolean variable name, it should read naturally:
if (isSuccessful) vs. if (returnCode)
I might indulge in boolean comparison in some cases, like:
if (PropertyProvider.getBooleanProperty(SOME_SETTING, true) == true) because it reads less "naturally".
For some reason I've always liked
if (IsGood)
more than
if (!IsBad)
and that's why I kind of like Ruby's unless (but it's a little too easy to abuse):
unless (IsBad)
and even more if used like this:
raise InvalidColor unless AllowedColors.include?(color)
Cybis, when coding in C++ you can also use the not keyword. It's part of the standard since long time ago, so this code is perfectly valid:
if (not foo ())
bar ();
Edit: BTW, I forgot to mention that the standard also defines other boolean keywords such as and (&&), bitand (&), or (||), bitor (|), xor (^)... They are called operator synonyms.
If you really think you need:
if (Flag == true)
then since the conditional expression is itself boolean you probably want to expand it to:
if ((Flag == true) == true)
and so on. How many more nails does this coffin need?
If you happen to be working in perl you have the option of
unless($isGood)
I do not use == but sometime I use != because it's more clear in my mind. BUT at my job we do not use != or ==. We try to get a name that is significat if with hasXYZ() or isABC().
Personally, I prefer the form that Uncle Bob talks about in Clean Code:
(...)
if (ShouldDoSomething())
{
DoSomething();
}
(...)
bool ShouldDoSomething()
{
return IsGood;
}
where conditionals, except the most trivial ones, are put in predicate functions. Then it matters less how readable the implementation of the boolean expression is.
We tend to do the following here:
if(IsGood)
or
if(IsGood == false)
The reason for this is because we've got some legacy code written by a guy that is no longer here (in Delphi) that looks like:
if not IsNotGuam then
This has caused us much pain in the past, so it was decided that we would always try to check for the positive; if that wasn't possible, then compare the negative to false.
The only time I can think where the more vebose code made sense was in pre-.NET Visual Basic where true and false were actually integers (true=-1, false=0) and boolean expressions were considered false if they evaluated to zero and true for any other nonzero values. So, in the case of old VB, the two methods listed were not actually equivalent and if you only wanted something to be true if it evaluated to -1, you had to explicitly compare to 'true'. So, an expression that evaluates to "+1" would be true if evaluated as integer (because it is not zero) but it would not be equivalent to 'true'. I don't know why VB was designed that way, but I see a lot of boolean expressions comparing variables to true and false in old VB code.