Рекомендации по приоритету Java-операторов

Ответ 1

Что касается "Реального Мира", то, вероятно, справедливо сказать:

• достаточно, чтобы программисты знали, что умножение/деление имеют преимущество перед сложениями/вычитанием, как это математически соглашение
• вряд ли кто-нибудь из программистов может запомнить любые другие правила приоритета

Итак, помимо конкретного случая */ vs +-, я бы просто использовал скобки, чтобы явно определить приоритет.

Ответ 2

Другим связанным источником ошибок является то, как накапливаются ошибки округления. Не проблема с порядком приоритета оператора как таковая, а источник удивления, когда вы получаете другой результат после перестановки операндов арифметически эквивалентным способом. Здесь версия sun.com Дэвида Голдберга Что каждый компьютерный ученый должен знать о арифметике с плавающей точкой.

Ответ 3

Цитата (из Спецификация языка Java §15.7) должна читаться в контексте Порядок оценки. Как обсуждалось здесь, этот раздел относится к порядку оценки, который не связан с приоритетом оператора (или ассоциативностью).

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

Например, если x == 1 изначально, выражение ++x/++x будет оцениваться как 2/3 (которое оценивается как 0), поскольку Java имеет порядок слева направо. Если бы порядок оценки в Java был справа налево, x был бы увеличен дважды, прежде чем вычислять числитель, и выражение будет оцениваться как 3/2 (которое равно 1). Если бы порядок оценки был undefined, выражение могло бы быть оценено для любого из этих результатов.

Цитата, о которой идет речь, вместе с ее контекстом,...

Язык программирования Java гарантирует, что операнды операторы, по-видимому, оцениваются в определенном порядке оценки, а именно слева направо.

Рекомендуется, чтобы код не опирался на эту спецификацию. Код обычно яснее, когда каждое выражение содержит не более одной стороны эффект, поскольку его внешняя операция

... отвлекает читателя от зависимости от правопорядка порядка оценки Java (как в примере выше). Он не поощряет ненужные круглые скобки.

Изменить: Ресурс: таблица приоритетов Java-операторов, которая также служит индексом для разделов JLS, содержащих синтаксическую грамматику, из которой каждый приоритет уровень выводится.

Ответ 4

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

Ответ 5

Кроме того, не забудьте логический && и || операторы быстрого доступа, избегайте чего-то вроде:

sideeffect1() || sideeffect2()

Если sideeffect1() оценивает true, sideeffect2() не будет выполняться. То же самое касается && и false. Это не полностью связано с предпосылкой, но в этих крайних случаях ассоциативность также может быть важным аспектом, который обычно не имеет значения (по крайней мере, насколько я заинтересован)

Ответ 6

JLS не дает явной таблицы приоритетов оператора; это подразумевается, когда JLS описывает различные операторы. Например, грамматика ShiftExpression такова:

ShiftExpression:
    AdditiveExpression
    ShiftExpression << AdditiveExpression
    ShiftExpression >> AdditiveExpression
    ShiftExpression >>> AdditiveExpression

Это означает, что аддитивные операторы (+ и -) имеют более высокий приоритет, чем операторы левого ассоциативного сдвига (<<, >> и >>>).