Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was under the impression that it was always best to write:
If Not X = Y then
then
If X <> Y then
but I'm not sure where I did I get this idea:-).
Is there a best? Why do we have two way to do the same thing anyways?
tks!
Readability is most important.
The second seems more natural to me. It seems misleading to use the equal sign and then adding the Not to it.
The Not IMHO is best used with boolean functions like IsNumeric(...) which lends itself to a more natural reading of the code, E.g.,
If Not IsNumeric(myNumberString) Then
And, I personally prefer using Not to = False for Boolean tests. E.g., I like...
If bFlag1 Then
If Not bFlag2 Then
...more than...
If bFlag1 = True Then ' <-- (This is totally redundant) = True
If bFlag2 = False Then
If a <> b = True Then ' <-- please don't ever do this
The first option is to be avoided as confusing. Someone might think that you meant to write If (Not X) = Y Then.
Why do we have two ways? Because... how could you prevent it? It's a natural consequence of having the three operators =, <>, and Not.
Besides style and readabilty there is a little difference:
Not is a logical operator and <> is a relational operator and logical and bitwise operators have a lower precedence than other arithmetic and relational operators (see here).
Furthermore the Not operator can be overloaded, I think this is not possible for relational operators in VBA.
I think that If X <> Y Then... is more expressive (but this is a matter of preference). Also it might be more efficient in terms of condition evaluation, since If Not X = Y Then... needs two operations (evaluating the equality and negating the result) rather than one. But, with some code optimisation behind the scene, who knows what actually happens?...
However, there are cases when is impossible to avoid the negated condition; for example the Is operator does not have a negated form (like Isn_t or something), so in this case you need to say If Not X Is Y Then...
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I learned that single equal sign is used to represent 'A is equal to B' rather than double equal sign as in many programming languages.
My understanding about this is single equal sign is usually used to 'assign' operator and double equal sign is used as a substitute to distinguish 'equal' sign from 'assign' operator.
Is there any historical or other reason for this?
SQL is a declarative language, and assignments are not typically made in SQL queries themselves. As a result, SQL doesn't have the problem of ambiguity of = meaning either assignment or equality check. As a result, there is no problem with using = to check equality. On the other hand, in a programming language such as Java, single = is used for assignments, while == is used for comparison.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
Using Linq and EntityFramework we recently noticed, while testing our queries performances, that the use of Equal(=) operator to compare two integers takes around 800ms more than using a combination of GreaterThan(>) and LessThan(<) operators.
So basically, replacing itemID == paramID (Both being integers) by !(itemID > param ID || itemID < paramID) in our linq query makes the query faster by about 800ms consistently.
Anyone with a deep knowledge of SQL could explain this result to me?
If this was always faster SQL Server would do the rewrite for you. It does not so you can conclude that it is not always faster to do this. In fact it is a bad idea to do this rewrite in 99.999% of the cases.
The information given in the question (almost none) does not allow for further analysis.
Often people ask "why did this random change make my query faster". The answer is always: You accidentally triggered a better query plan. There is no system to it. Query plans can be unstable.
Psychic guess: The complex predicate forces a table scan (or makes it appear better) than using an index. That can sometimes be a good thing.
The first step would be to examine the generated sql. My guess is itemID is nullable and EntityFramework's default behaviour with nullable properties isn't the greatest. It will translate your query into something like: prop = value OR prop is null
If that is the case and you are using EF6, you can overide that behaviour by:
context.UseDatabaseNullSemantics = true;
Msdn
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 7 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm sure there's a reason that the comparison operator is <>. I'm googling and trying to make sense of it; I'm reading that it has to do with indexes from a functional perspective; what I'm trying to work out is the semantics behind using "less than and greater than".
How can any value ever be both less than and greater than at the same time? Wouldn't this mean that <> always returns false?
Some early computer languages used <> as not equals, such as the original BASIC.
You may be better off thinking of <> as less than OR greater than rather than less than AND greater than. This is similar to the other relational operators, such as >= meaning greater than OR equal to. Then it makes perfect sense.
Or just do what everyone else does and think of it as "not equal to" - I've seen many variations such as <>, !=, /= and even ¬=.
I wouldn't get too deeply philosophical about what characters make up tokens in various languages. That way lies madness.
For example, in C, the expression delta != 7 could be read as DELTA = 7 (think "yelling out delta as an exclamation").
Or a == b meaning that you're really certain that a is equal to b :-)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have heard both ends of the story. One view is that using a special value of a numeric variable to indicate special state is a design flaw. However, I meet this behavior all the time.
An example would be a byte unsigned integer, where the value 255 indicates lack of information.
Is this a bad practice? If so, in what exceptional cases it is allowed/encouraged?
That depends very much on the situation; as always, strive to write things the simplest, easiest to understand way. Hopefully exceptional situation handling doesn't clutter up the code for the normal case (that's the idea behind exceptions, but they create their own mess...).
Be careful when selecting the value to be used for exceptional cases. For example, C/Unix conventions use this quite a bit, but make sure to use "impossible" values. So, getchar(3) returns a character code as an int, but returns a non-character EOF for end of file. Similarly, read(2) returns the number of characters read (could be 0 if nothing to be read), or -1 on error.
This is absolutely not a bad practice, assuming that you can afford it, i.e. the range of representable integers has enough extra values that you never need to use in real-life situations.
For example, if you needed a full range of unsigned bytes, including the 255, then giving 255 a new meaning of "unknown" would be a problem. If 255 is never used for the "real" data, then you are free to assign it any meaning that you would like.
What's wrong, however, is using special numbers throughout the code without assigning them a special name. For example,
if (myByte == 255) {
// Process the situation when the value is unknown
}
is unquestionably bad. You should name all your special constants, and use only these names throughout your code:
if (myByte == UNKNOWN_VALUE) {
// You can skip the comment about processing an unknown value:
// the name of the constant tells your readers what's going on.
}
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Speed difference between If-Else and Ternary operator in C…?
This is a very simple question, does the ternary operator increase the speed of execution in comparison to if else statement?
No. Most languages parse it to a very similar syntax tree. Any jit/optimizer is going to collapse it into 'basic blocks' of simple instructions without jumps; and from that point on it will optimize the same.
There could, of course, be some really bad systems out there for which this is not true; but gcc/msvc/c# will all deal with it equally well.
It's abundance can usually be associated with the fact that it is an expression instead of just a logic statement. This makes it all to easy to do things like (note: really ugly example ahead):
size_t n = strlen( pszVar == NULL ? "" : pszVar );