Can Resharper help me deprecate "And" in favor of "AndAlso"?

I just found a bug in our code in which "And" was used where "AndAlso" is required. To prevent this kind of bug in the future, I would like to prohibit the use of "And" as a logical operator, and use only "AndAlso". Can Resharper help me do that?

Yes, I know there are situations where And is functionally different from AndAlso. In my opinion, however, those situations arise from bad code, and I would be glad to flush them out and eradicate them.

A little background for those who don't know: In VB.NET, AndAlso is a short-circuit operator, but And is not, making it possible (even likely) that someone will use a non-short-circuit operator where a short-circuit operator is required. This is not an issue in C#, because there is no non-short-circuit alternative to &&.




Corresponding issue is reported to YouTrack -
You are welcome to comment or vote for it.

Thank you.


Although it's not widely used, the C# equivalent of "And" is just "&":

static void Main()
    Console.WriteLine("With &&:");
    Console.WriteLine(Test1() && Test2());
    // Output: Test1, False
    Console.WriteLine("With &:");
    Console.WriteLine(Test1() & Test2());
    // Output: Test1, Test2, False

static bool Test1()
    return false;

static bool Test2()
    return false;

Similarly, the C# equivalent of "Or" is "|", whereas "OrElse" is "||".



I stand corrected. It seems this concern applies to C# as well; it would be reasonable to discourage the use of & on boolean operands to prevent its accidental use in situations where && is required.



It's not incorrect code to use & and if ReSharper issued a warning for this, then you would have to disable that warning just to use &.

I've used & correctly more times than I've used it incorrectly. I fail to see how this should be something that ReSharper warns about using.

The only reason a & would introduce a bug is if that source code is was not being tested.



I am interested in what you have to say.

And, Or, &, and | may be used as either logical operators or bitwise operators. I agree that their use as bitwise operators is perfectly valid, and a Resharper warning against this would be a nuisance. I didn't mention this in my first post because it seemed an unnecessary detail, but I did make a comment to this effect on the YouTrack issue Angelina created ( Taking this into account, the request really should be phrased as something like this:

Identify uses of 'And', 'Or', '&', and '|' as logical operators, and either suggest replacement or automatically replace with 'AndAlso', 'OrElse', "&&', and '||' respectively.

Does this address your concern? Or do you believe that a Resharper warning would be inappropriate even if applied to uses of And, Or, &, and | as logical operators? If so, I would like to know more about why you think so. To be clear, I understand the functional difference between & and && when used as logical operators, but I can't see why the functionality of & would ever be preferred to the functionality of &&. If I'm blind to an important use case, I would be grateful for enlightenment. Could you provide an example, perhaps?



The problem here is that & and && are valid operators in an expression, and in C# they result in different code behavior.

For example;

if(foo() & poo()) { exit; }

if(foo() && poo()) { exit; }

Both of the above lines of code will execute exit only if foo() and poo() return true.

But! The first if statement WILL call poo() if foo() returns false, and the second if statement will NOT call poo() if foo() returnns false.

How would ReSharper know if the programmer needed poo() to always been called?


I tend to agree with TC; when used as logical operators, the non-short-circuiting operators are almost always a mistake. If your code requires that both "foo" and "poo" always run, then change the code to make that more obvious:

bool fooResult = foo();
bool pooResult = poo();
if (fooResult && pooResult) { exit; }

Relying on non-short-circuiting operators to always call code with side-effects is not immediately obvious when scanning the code, and should result in a warning.


Please sign in to leave a comment.