"Некоторые разработчики думают, что мировой запас скобок жёстко ограничен, и их следует использовать только в самых необходимых случаях" (с) одна хорошая книга по программированию.

1. Не помните приоритетность - плохо. Равно можете не помнить правила дорожного движения, правила грамматики итд.

2. "Вам удобнее" и "Вам плохо читаемо" - это не аргумент.

3. Крутизна тут не при чём.

4. Нехватка скобок ухудшает читаемость кода. Избыток скобок ухудшает читаемость кода. Слишком длинные и сложные выражения, в том числе со скобками и в том числе без скобок, ухудшают читаемость кода. В любом случае важна адекватность и чувство меры.

5. Идеального кода в мире мало. Важным для программиста является умение разобраться в неидеальном коде.

MasterZivВо многих (в большинстве) ЯП приоритеты операций более-менее соответствуют приоритету аналогичных операций из математики и булевой алгебры.
Проблемы с приоритетом идут как правило на стыке арифметических и логических операций. Ещё бывают вопросы с приоритетом сравнения, ну и изредка экзотика типа порядка выполнения 1 >> 2 >> 3.

Вот за что не люблю си-подобные языки, так это как раз за кучу "лишних" скобок.

AkinasoftwarerНе помните приоритетность - плохо. Равно можете не помнить правила дорожного движения, правила грамматики итд.Приоритетность в разных языках и даже диалектах разная. В отличие от ПДД. Я бы посмотрел, как бы ты помнил ПДД, будь они свои для каждой улицы...
Я бы посмотрел, как ты программируешь на наборе языков, сравнимом с количеством улиц.

ПДД свои для каждой страны, но особых проблем у меня не возникло. Просто перед пересечением границы стоит прочитать список "что там не так и как именно". При этом пересекать границы приходится пожалуй что чаще, чем менять языки программирования. Ну а для того, что входит в текущий набор... понимать приоритеты для трёх-четырёх языков опять-таки никаких проблем не вызывает.

AkinaДля начала подели приоритетность на абсолютную и языкозависимую. Использование первой естественно. Использование второй - более чем сомнительное занятие. Код не только плохочитаем, но и может оказаться непереносимым. Например, в MS SQL приоритет XOR выше, чем у NOT, а в MySQL наоборот...
Блестящий совет. То есть завтра какой-нибудь придурок делает какую-нибудь явную хрень (типа приоритета XOR выше, чем у NOT), и сразу же тот код, который сегодня был естественным и хорошим, завтра же становится более чем сомнительным и плохим.

softwarerНапример, в MS SQL приоритет XOR выше, чем у NOT
Хотя если секунду подумать, вообще интересно. Как тогда этот транслятор обходится с выражением NOT A XOR NOT B.

AkinasoftwarerТо есть завтра какой-нибудь придурок делает какую-нибудь явную хрень (типа приоритета XOR выше, чем у NOT), и сразу же тот код, который сегодня был естественным и хорошим, завтра же становится более чем сомнительным и плохим.
Нет, он и раньше был плохим, просто не каждый это понимал.
В том числе Akina 16944631 , согласно которому он был "естественным" до тех пор, пока у всех было одинаково.

AkinaИ те, кто переносит свои выросшие проекты с MySQL на MS SQL, хлебают своего же дерьма полной ложкой, если заблаговременно не позаботились в т.ч. и об этой стороне переносимости кода.
Как бы деликатно сказать.... сама постановка вопроса настолько идиотская, что вовсе не приоритет операций будет в этом случае главной проблемой.

AkinaЧто же до "придурок" - те системы, которые широко используются, настолько широко, что с их пониманием приоритетности приходится считаться, создают вовсе даже не придурки. И их понимание приоритетности никогда не строится на пустом месте и не высасывается из пальца.
Вы плохо представляете себе жизненный цикл систем. Скажем, однажды, в конце семидесятых годов, некоторые люди, которые писали на ассемблере первую версию Oracle, выбрали для хранения строк "паскалевский" формат, ибо им так было удобнее по их инструментальным средствам. Чуть позже, в конце восьмидесятых годов, другие люди, которые писали альтернативные rdbms на сях, выбрали для хранения строк "сишный" формат, ибо им так было удобнее по их инструментальным средствам. Прямым следствием этих двух решений стали бущующий по сей день идиотизм "пустая строка должна отличаться от null" и флейм "в оракле строки не как везде". Подобные эпизоды, безусловно, появляются не на пустом месте, но если Вы думаете, что где-то там сидят высоколобые мудрые разработчики и тщательнейше планируют все варианты и их последствия на сорок лет вперёд, то Вы глубоко заблуждаетесь.

Тем не менее, если о пустых строках в принципе можно спорить, то ряд подобных "не из пальца" решений иначе как идиотизмом не назовёшь. Скажем, в том же MSSQL очень долго unique constraint допускал один и только один null в таблице, а на попытку вставить второй говорил "нарушение уникальности". И описанная Вами оригинальная схема приоритетов - если это действительно так - ровно из той же серии. Хотя у того и другого, безусловно, есть какие-то внутренние причины, и при желании даже можно раскопать, какие.

AkinaВариантов два.
NOT (A XOR NOT B) - так посчитает MS SQL
По идее, он вообще должен выдать синтаксическую ошибку в этом случае и требовать записать NOT A XOR (NOT B). В противном случае грамматика вместо LR(x) или чего-нибудь другого приятного становится контекстно-свободной с соответствующими последствиями для удобства и эффективности транслятора.

maytonЯ тут на бумажке таблицу истинности набросал. Вобщем
Дык. Именно преобразованием в обратную сторону я это и получил, прикидывая, для чего такие приоритеты вообще могут понадобиться :) Правда имхо такие вещи нужно делать в уме, равно как всякие not (a and b) etc.

Dima T, Вы правы, если говорить только о XOR и NOT. Проблему представляет другое, а именно то, что против всякой привычной логики, XOR оказывается по приоритету выше AND.