Why C# doesn't accept the boolean operators as words ("and", "or", "not" ,..etc) with the current operators?

Question

My if stetement:

if (!string.IsNullOrEmpty(Person.Name))
        // some code

I think the "!" operator is less readable when writing imperative code,

Are you agree with me the following code is more readable?

if (not string.IsNullOrEmpty(Person.Name))
            // some code

I'm not talking about replace the current operators, but where's the problem if the language accept them both ?

Answer 1

There are a couple of good reasons:

• There are some fine points that the words don't convey too well. For example, a short-circuit AND operator vs one that doesn't short-circuit (&& vs &). VB recently(ish) introduced a short-circuit AND operator called AndAlso. That never made any sense to me. It seems to confuse people from the start.

• Less typing. Boolean logic is used everywhere, and a couple of keystrokes saved on each expression can add up to a lot -- or at least, I've found that having to type more is pretty annoying.

• Because it's what C, Java, Objective-C, and C++ programmers are used to. People have been using this syntax for 40(?)-ish years now. It lends an air of continuity to the languages that people seem to like.

• "and", "or", and "not" are English words, and a syntax using glyphs like ! and &&/& is more linguistically and culturally neutral.

• Adding more operators which mean the same thing is unnecessary for the operation of the language, and can be confusing.

Answer 2

If you want your code to be more "readable" then perhaps VB is a better option for you. It is completely valid to have statements like

If value Is Not Null Then
   'do something
End If

I personally find that the c# syntax of ! and && and || to be very readable because they're consistant across a number of languages and also tend to follow the conventions used in mathematics where these operations often gain their origins.

It also means there is no ambiguity to their meaning as it is a symbol.

Answer 3

The problem, in a word, is complexity. From a usability perspective, you don't want to confuse developers with multiple ways of doing the same thing. From a compiler perspective, the more tokens you have, the worse the performance. Clearly one more token won't make a difference, but think of all the other redundancies others might ask for. Better to force everyone to do things the same way. At least that way we'll be sure to keep coming back to Stack Overflow!

Answer 4

I have an interesting point in mind. Often you want to use the properties of the language. If you have a logical expression in normal form, where the main operator in the Polish tree of the logical operations is an AND (&&) and the first operand is false, the language won't calculate the value of the other operands. Similarly, if the main operator in the Polish tree of the logical operations is an OR (||) and the first operan is true, the other operands won't be calculated. Let's see a few examples

//...
// Position is a class
private bool checkMate(ref int numberOfPlies, ref ChessPosition position, int maxNumberOfPlies, List<Move> moves)
{
    if (numberOfPlies > maxNumberOfPlies)
        return false;
    position.makeMove(moves[numberOfPlies]);
    if (!(position.getSuccessOfLastMove())))
        return false;
    numberOfPlies++;
    return ((
            ((isCheckMate()) ||
            ((checkMate(ref numberOfPlies, ref position, maxNumberOfPlies, moves)))
           ));
}
//...

The above method checks whether a varitation leads to a checkmate from a given chess position and the checkmate is given in a certain amount of plies. Position is a class, its makeMove() method makes a move in the given position, its getSuccessOfLastMove() is true if the last move was valid and is false if the last move was not valid. Move is another class. Ply is a half-move in chess (Move = white moves and black moves, Ply = White or Black made a move). isCheckMate checks whether a given position is a checkmate.

We don't want to call checkMate if isCheckMate() is true, so we don't need other operation here than the usual ||.

However, here we want to evaluate all the operands:

//... bool isThisFlowerYellowOrYellowish(Flower flower) { return (((flower.flowerColor == flower.yellow) OR (flower.FlowerColor == flower.yellowish)) AND (flower.setColorToYellowIfTheColorIsYellowish())); } //...

The code above is not a valid C# code, but let's see why we need an OR in C#. In the example above we want to run the setColorToYellowIfTheCollorIsYellowish() even if we know the result of the total evaluation before evaluating the function, but the code is not working because we don't have an OR operation which calculates all the operands even if we can know the result. If this was possible, we would be able to not write the function in an alternative way.

//...
bool isThisFlowerYellowOrYellowish(Flower flower)
{
    if (flower.FlowerColor == flower.yellowish)
        return flower.setColorToYellowIfTheColorIsYellowish();
    return (flower.flowerColor == flower.yellow);
}

//...

This is disgusting compared to the second example in my opinion. If we had an "OR" and an "AND" operator which are not optimised and evaluates all the operands no matter what, then the language would be richer with a feature, but, we can survive without these operators, because we have alternative solutions when needed and this is a very rare case.

In my opinion we don't need a "NOT" operator, because that's a unary operator and it would be similar with the ! operator.

In my opinion we shouldn't change the !, ||, &&, & and | operators because all the programmers are used to them. If they are changed in C#, the language will not have backwards compatibility.

EDIT:

On a second thought, the language would have backwards compatibility if the old operators' meaning would be unchanged, regardless of whether the keywords of not, or, and would be introduced.