Я использую C ++ 11, и оба компилируются без предупреждения, ведь один из них — лучший способ сделать это?
if(a && b)
или же
if(a and b)
2.6 Альтернативные токены [lex.digraph]
1 Альтернативные представления токена предоставляются для
некоторые операторы и знаки препинания .162 Во всех отношениях языка каждый альтернативный токен ведет себя
то же самое, соответственно, как его основной токен, кроме его правописания. 17
Набор альтернативных токенов определен в таблице 2.
Не могу вставить таблицу 2, но в ней явно указано Альтернатива: and
Первичный &&
(то же самое для or
а также ||
).
Так что они абсолютно идентичны.
Если вы хотите попытаться убедить себя, что одно «лучше», чем другое, это ваше дело. Если кто-то еще пытается спорить, у них должна быть веская причина.
Изменить: вышеупомянутая таблица 2:
Table 2 — Alternative tokens
Alternative Primary
<% {
%> }
<: [
:> ]
%: #
%:%: ##
and &&
bitor |
or ||
xor ˆ
compl ~
bitand &
and_eq &=
or_eq |=
xor_eq ˆ=
not !
not_eq !=
Редактировать: возможно, стоит отметить, в соответствии с Себастьян Редл, MS нарушает правила здесь.
я предпочитаю &&
вместо and
,
&&
широко известен и принят, в то время как многие даже не знают, что and
действителен C ++.and
(и друзья) по умолчанию. Например MSVC ++.&&
а также ||
укоренился в моей голове. В то время как and
а также or
имеют те же приоритеты, что и &&
а также ||
тот простой факт, что я гораздо менее привык к ним, усложняет чтение условия.С другой стороны, and
является более многословным и может быть проще в использовании для программистов, которые изучили программирование на языках, которые не используют &&
, Но можно утверждать, что эти люди должны изучать C ++, а не пытаться изменить его snytax.
я бы предпочел
если (а и б)
потому что всегда есть шанс случайно перепутать
если && б)
с
если & б)
, доставляя вам много неприятностей ..
Как человек, который программирует как на C, так и на C ++, если нет веской причины использовать разные альтернативы на каждом языке, я предпочитаю придерживаться этого. Хотя and
был частью стандарта C в течение почти двух десятилетий, он требует заголовочный файл вместо того, чтобы быть встроенным в язык. Особенно, когда кусок кода может использоваться в нескольких проектах, хлопоты просто не стоят этого.
Я никогда не видел ситуации, когда использование and
над &&
было бы выгодно. Я не могу представить современную систему развития без & ключ, хотя, может быть, если вы пытаетесь сделать что-то на необычной платформе (например, непосредственно программировать на сильно ограниченной мобильной / встроенной системе), это было бы полезно. Я также думаю, что это снижает читабельность моего кода для людей, которые очень привыкли видеть &&
как логичный и оператор.