Нужно ли знать Приоритет оператора полностью?

Question

Должен ли программист полностью знать приоритет оператора? Использование скобок для группировки выражений должно быть хорошо, не так ли? Я всегда использую брекеты, чтобы быть на более безопасной стороне. И когда мне задают вопрос о приоритете, я не могу с готовностью ответить.

Answer 1

Для очень распространенных операторов - да, это стоит знать. Если вы поставите скобки вокруг всего , которое в противном случае полагалось бы на приоритет оператора, ваш код был бы нечитаемым (или его легко спутать с Lisp).

Для более неясных операторов - я явно избегал их изучения. Если я начну воспринимать слишком много вещей как должное, которых я не могу ожидать, чтобы другие разработчики знали, я начну писать код, который я могу легко читать, но никто другой не может. Лучший пример - операторы сдвига. Я даже не знаю (наверняка - у меня есть подозрения), какие из них будут рассматриваться одинаково без скобок, но я абсолютно уверен, что яснее:

int x = (y << shift) + offset;

или

int x = y << (shift + offset);

Answer 2

Несколько лет назад я видел эту таблицу приоритетов для C:

• Умножение и деление происходят перед сложением и вычитанием.
• Используйте скобки.

Это немного упрощенно, но у него правильная идея.

Answer 3

Да, важно понимать приоритет оператора. Тем не менее, я думаю, что стоит использовать круглые скобки, чтобы быть совершенно ясным относительно вашего намерения. Это поможет удобочитаемости и ремонтопригодности.

Answer 4

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

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

Answer 5

Вы должны понимать это, но вы не должны предполагать, что другие поймут. Я всегда использую скобки, чтобы сделать приоритет явным.

Answer 6

Это, конечно, не повредит, и может помочь вам прочитать код с тонкостями превосходства, написанными другими.

Однако на практике, вероятно, лучше не предполагать, что те, кто поддерживает ваш код, будут обладать одинаковыми навыками, поэтому, хотя вы и сможете читать этот код, вы можете не захотеть писать код, который использует слишком много преимуществ взаимодействий. Лучше использовать конструкции, которые безошибочны, даже если здесь и там есть несколько лишних скобок.

Answer 7

Быстрый, который имеет более высокий приоритет в T-SQL: И против ИЛИ.

SELECT c.Name
FROM [Customer] c LEFT JOIN [Order] o
  ON c.CustomerKey = o.CustomerId
WHERE c.Name like 'B%'
  OR c.Name like 'Z%'
  AND o.CustomerId is NULL

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

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

Answer 8

Я знаю основы (например, деление и умножение выше, чем сложение и вычитание), но мне пришлось бы искать что-то более эзотерическое.

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

Answer 9

Практически: не совсем. Если это так сложно, что вам нужно знать приоритет оператора, вам все равно следует разбить выражение на куски. Кроме того, скобки спасут вас!

Профессионально: изучение порядка для вашего языка не занимает много времени и может пригодиться при чтении чужого кода. Если ничего другого, просто держите его на шпаргалке на стене куба.

Answer 10

Вы должны понимать это, чтобы иметь возможность читать код, написанный кем-то, кто не использовал парены везде.

Я не думаю, что "всегда брекеты" - хорошее эмпирическое правило. Код, имеющий слишком много паренов, становится труднее читать, чем необходимо. Как:

(a * b) + c

просто глупо. Где-то есть баланс, и задача состоит в том, чтобы его найти. Как и во многих других вещах, речь идет о применении здравого смысла.