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

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.

MasterZivих там как раз нет, за это люби свой любимый паскаль.
Потише демонстрируй свою некомпетентность, смешно.

Anatoly MoskovskyТак где, говорите, больше скобочек?
В си-подобных языках. Примеры, думаю, Вы знаете не хуже меня.

Anatoly Moskovskyпро то, кому в здравом уме могло прийти в голову что у сравнения меньший приоритет чем у логических операций.
Да, для того, кто не думает про одноимённые битовые операции, это аргумент.

Anatoly MoskovskyВы фигурные шоли имеете в виду? :)
Нет, круглые. Долго собираетесь юродствовать?

Anatoly Moskovsky, я предполагал, что человек с таким количеством сообщений в форуме Си знает хотя бы синтаксис языка. Прошу прощения за ошибку. Пример....




Думаю, достаточно. Считайте скобочки для сишного варианта.

Anatoly MoskovskyЕсли сравнить кол-во скобок в С с кол-вом do, : и ; в паскале, то еще не известно кто победит.
Тёплое с мягким?

Anatoly MoskovskyА уж по кол-ву набранного текста на единицу полезного кода паскаль точно лидер :)
Вы правы. Офигенная прелесть Паскаля (точнее, дельфы, как его современного представителя) в исключительной информативности кода, по характеристике "прочитал немного красивого кода и всё понял" ему нет равных. Если, конечно, код правильно написан, испортить можно всё, что угодно. Худший из известных мне языков в этом плане - пожалуй, Ява. Хотя в последних версиях надо отметить большой прогресс, на семёрке уже даже вполне приятно работать.

JeStonesoftwarerВы правы. Офигенная прелесть Паскаля (точнее, дельфы, как его современного представителя) в исключительной информативности кода, ...
Это все субъективно. Для меня, например, ...
Вы не совсем правы. Здесь есть три составляющих. Во-первых, согласен, субъективная - уровня "мне больше/меньше нравятся фигурные скобки чем begin/end". Во-вторых, привычка; наработанная практика восприятия кода на определённом языке, его типовых приёмов итп. И в-третьих таки объективная, порождённая (не)соответствием подходов и средств языка задаче.

Чтобы увидеть, что объективная составляющая точно существует.. ну давайте возьмём, например, какой-нибудь сложный, но воспринимаемый SQL-запрос, и представим себе, как будет выглядеть делающий то же самое код на plain C.

Так вот, я говорю именно об объективной составляющей. При этом, поскольку мне нравится и Си как таковой, и Паскаль как таковой, полагаю, что не вношу в оценку большой субъективности. В каждом из них есть то, что мне нравится, и то, что не нравится.