Should alternative tokens be recommended?

[johnthagen]

Alternative tokens provide human-readable string names for certain operators.

For example:

if (x && y.empty()) {
}

Becomes:

if (x and y.empty()) {
}

I've always personally found these easier to read (perhaps influenced from Python background). As far as I understand these identifiers are proper keywords in C++. However, I am hesitant to use them because my impression is that it is not idiomatic to use them in C++.

Also, the bitwise operator names (bitand, bitor) feel like a bit of overkill compared to boolean ones.

Some options I feel could be considered:

1) Guidelines don't mention alternative tokens (I couldn't find a mention in the current guidelines) 2) Guidelines recommend no alternative tokens are used 3) Guidelines recommend the boolean tokens (and, or, not) 4) Guidelines recommend boolean and bitwise tokens (and, or, not, bitand, bitor, and_eq, etc)

[JonasToth]

The guidelines recommend to use parenthesis for logical conditions to make the order of evaluation clear even to beginners that are not familiar with c++.

I feel that alternative tokens would be such a simplification as well especially for bitwise and logical operators. On the other hand, having consistent operators is very important for readability.

I would prefer to allow them, but require consistent usage. So either && everywhere or and everywhere. A tool like clang-tidy could enforce that easily.

[AndrewPardoe]

Per our editors' discussion, this would be a good rule for the Naming and Layout section. We do feel that the traditional notation should be used unless there is a good reason to use the alternative tokens.

[JonasToth]

What would be a good reason?

[jwakely]

"It's a longstanding convention. But consistency is more important, so if your project uses something else, follow that."

"As ever, remember that the aim of these naming and layout rules is consistency and that aesthetics vary immensely."

If you're working on a piece of code that always uses the alternative tokens, be consistent.

[JonasToth]

If you're working on a piece of code that always uses the alternative tokens, be consistent.

Thats a good reason.

[mikesreed]

Obviously, consistency is an important driver but the guidelines are often there to recommend what to do when starting with a blank sheet i.e. when there is no existing code to be consistent with. So for me there should be guidance here. There are two equally valid ways of doing something, which one is preferred? If we look at the two alternatives without prejudice, which one is better? I have to say, I use the "symbol" form because it seems to be what most other people use, but if I answer my own question I do feel the answer is the "word" forms.

1. They can be used on all keyboards used by devs. This is even more relevant now than it was before, with dev teams often spread across the globe.
2. They tend to force clearer code because they force spaces: compare if (I or l bitor l1) with if (I||l|l1). I know that is contrived but I have actually seen a production bug along these lines.
3. They are simply easier to read. Even though I don't use them myself I do have to admit this.

So, I feel that if there were to be a recommendation it should be to use the alternative "word" forms (but not if that would be inconsistent with current code)

[neithernut]

Couter-points:

• with the "symbol"-form, it's immediately obvious that it's an operator. You cannot mis-read && as an identifier.
• (hand-wavy) virtually all languages (including python) allow using the "symbol"-form, while the "word"-form is supported by few. Especially other modern compiled languages have && and ||.
• it's at least not as cursed as xtext's use of « and », which you probably cannot type if you are not French.

---

Out of curiosity: on what keyboard-layouts can't you write & or |? And don't you run into problems with parentheses, brackets and curly-braces on them anyway? I do know that some of those symbols are a bit more cumbersome to type on many European layouts (in fact, I'm impacted by that) but I assumed you quickly adapt. I honestly don't know what's the situation for layouts targeted at non-roman writing-systems. I suspect many will switch to an US-layout for programming, anyway (I know a few Europeans who do).

[MikeGitb]

Just a general comment: When discussing readability and giving examples: please use Identifiers and code constructs that are as close to real code you are writing as possible. It's not really useful to make decisions based on foo, bar, baz, a, b, c and trivial conditions like (a && b), when your actual identifiers are 5 times as long (but more speaking) and the conditions that are actually tricky to read have multiple subclasses.

You don't have to worry about p and p->foo / p && p->foo being misread/difficult to read either way, but for something like

( i < my_container.size() ) and (next_ptr and (next_ptr->elementsize > 5 or next_ptr->owned_object.key != key))

An advantage of one or the other form (if there is one) might suddenly become relevant (and more visible).