Должен ли я использовать "&&" или "и"?

Ответ 1

2.6 Альтернативные маркеры [lex.digraph]

1 Альтернативные представления токенов предоставляются для некоторые операторы и пунктуаторы .16

2 Во всех аспектах языка каждый альтернативный токен ведет себя то же самое, соответственно, в качестве основного токена, за исключением его правописания .17 Набор альтернативных токенов определен в таблице 2.

Нельзя вставить таблицу 2, но в ней явно указано Alternative: and, Primary && (то же самое для or и ||).

Таким образом, они абсолютно идентичны. Если вы хотите попытаться убедить себя, что это "лучше", чем другой, это ваш бизнес. Если кто-то пытается это утверждать, у них будет хорошая причина.

Изменить: вышеупомянутая таблица 2:

Table 2 — Alternative tokens
Alternative Primary
<%          {
%>          }
<:          [
:>          ]
%:          #
%:%:        ##
and         &&
bitor       |
or          ||
xor         ˆ
compl       ~
bitand      &
and_eq      &=
or_eq       |=
xor_eq      ˆ=
not         !
not_eq      !=

Изменить: возможно, стоит отметить, согласно Себастьян Редл, MS нарушает правила здесь.

Ответ 2

Я предпочитаю && вместо and.

• && широко известен и принят хотя многие даже не знают, что and является допустимым С++.
• Некоторые IDE не принимают and (и друзей) по умолчанию. Например MSVС++.
• По крайней мере для меня приоритет оператора && и || укоренен в мою голову. В то время как and и or имеют те же приоритеты, что и && и ||, простой факт, что я гораздо менее привык к ним, затрудняет чтение условия.

С другой стороны, and является более подробным и может быть проще использовать для программистов, которые изучили программирование на языках, которые не используют &&. Но можно утверждать, что эти люди должны изучать С++, а не пытаться изменить его snytax.

Ответ 3

Я бы предпочел   если (a и b) , потому что всегда есть шанс случайно перепутать   если (a & b) с   если (a и b) , что вызывает у вас массу проблем.

Ответ 4

Как кто-то, кто программирует как на C, так и на С++, если у вас нет веских оснований использовать разные альтернативы на каждом языке, я предпочитаю сохранять его согласованным. Хотя and был частью стандарта C почти на два десятилетия, для него требуется заголовочный файл, а не встроенный в язык. Особенно, когда фрагмент кода может использоваться в нескольких проектах, хлопот просто не стоит.

Я никогда не видел ситуации, когда использование and over && было бы выгодным. Я не могу представить себе современную систему разработки без ключа &, хотя, возможно, если вы пытаетесь что-то сделать на необычной платформе (например, прямое программирование на сильно ограниченной мобильной/встроенной системе), это было бы полезно. Я также думаю, что это уменьшает читаемость моего кода для людей, которые очень привыкли видеть && как логический и оператор.