Должен ли программист внимательно знать о приоритете оператора? Использование фигурных скобок для группировки выражений должно быть в порядке, не так ли? Я всегда использую фигурные скобки, чтобы быть на более безопасной стороне. И когда задавали вопрос о приоритете, я не могу легко ответить.Должен ли кто-нибудь заранее знать приоритет оператора?
Для очень распространенных операторов - да, это стоит знать. Если вы положите скобки вокруг все, что в противном случае полагалось бы на приоритет оператора, ваш код был бы нечитаемым (или легко путать с Lisp).
Для более неясных операторов - я явно избегал их изучения. Если я начну считать слишком много вещей само собой разумеющимся, что я не могу разумно ожидать, что другие разработчики узнают, я начну писать код, который я могу легко читать, но никто другой не может. Лучшим примером являются операторы сдвига. Я даже не знаю (точно - у меня есть подозрение), какие из них будут относиться так же без скобок, но я абсолютно уверен, что понятнее:
int x = (y << shift) + offset;
или
int x = y << (shift + offset);
Оператор смены действительно злой. Все, что я знаю, это всегда противоположность тому, что вы думали, когда вы его использовали :) –
Явное избегание знаний для меня не очень хорошо. – PEZ
@PEZ - работает ли кнопка downvote на ответах Джона Скита? Я не думаю, что кто-то еще это пробовал;) –
Да, важно понимать приоритет оператора. Тем не менее, я думаю, что есть смысл использовать круглые скобки, чтобы быть совершенно ясно о ваших намерениях. Это поможет читаемости и ремонтопригодности.
Я знаю основы (например, деление и умножение выше сложения и вычитания), но мне нужно было бы искать нечто более эзотерическое.
Обычно я использую круглые скобки, чтобы сделать мое намерение ясным. Я думаю, что он читает лучше и избегает ошибок из-за неправильных предположений.
Это, безусловно, не может повредить, и может помочь вам прочитать код с тонкостями тонкости, написанными другими.
На практике, вероятно, лучше не предполагать, что те, кто поддерживает ваш код, будут иметь одинаковый навык, поэтому, хотя они должны быть в состоянии читать этот код, вы можете не захотеть писать код, который слишком сильно использует взаимодействие , Лучше использовать конструкцию, которая безошибочна, даже если это означает несколько дополнительных круглых скобок здесь и там.
Я думаю, что важно понимать основные правила предвидения. Я нахожу, что знаю, что ничтожные подробные детали не стоят времени. В основном потому, что любой случай, когда задание неоднозначно, можно решить простым набором парен. Во-вторых, потому что не все знают их, и лучше всего сделать код доступным для пользователей в вашей группе.
Когда-то в колледже я знал наизусть все правила предков. Как только я попал в реальный мир, я обнаружил, что большинство людей не знали их наизусть. Если я проверил в каком-то действительном коде, который зависел от некоторых правил предсуждения, я последовательно получал такую же обратную связь: «добавьте parens, чтобы сделать это очевидным».
Я с вами на этом; использование фигурных скобок, чтобы сделать приоритет явным, всегда является хорошей идеей. Это упрощает чтение кода, и ваши намерения ясны.
С учетом этого вы должны знать, где искать информацию о приоритете оператора, если вы поддерживаете код других.
Вы должны понимать это, чтобы иметь возможность читать код, написанный кем-то, кто не использовал парсы повсюду.
Я не думаю, что «всегда-скобки» - хорошее эмпирическое правило. Код, в котором слишком много парнеров, становится сложнее читать, чем необходимо. Нравится:
(a * b) + c
просто глупо. Там где-то есть равновесие, и задача состоит в том, чтобы найти его. Как и многие другие, речь идет о применении здравого смысла.
Я не думаю, что это глупо; Я думаю, что это более читаемо. –
Практически: не совсем. Если это так сложно, что вам нужно знать приоритет оператора, вы, вероятно, должны разбить выражение на куски. Кроме того, скобки помогут вам сэкономить!
Профессионально: вам не потребуется много времени, чтобы узнать порядок выбора вашего языка и может пригодиться при чтении кода других людей. Если ничего другого, просто держите его на чит-лист на стене куба.
Вы должны это понимать, но не следует предполагать, что другие будут. Я всегда использую круглые скобки, чтобы сделать приоритет явным.
Я использую чит-лист для всех, кроме самых распространенных арифметических операторов. Если что-то не так сложно, я использую явные круглые скобки, чтобы мои намерения были ясными.
Причина, по которой мне нравится использовать письменное руководство, а не запоминать приоритет, заключается в том, что я часто работаю на нескольких языках с не совсем разными правилами. Запоминание чего-либо за пределами наиболее распространенных операторов может привести к ошибкам, когда я начну слишком полагаться на свою память.
Нет!
Если вы не уверены в приоритете, то вероятность того, что кто-либо еще прочитает код, будет нести его неправильное толкование.
Если вы не знаете только
(..)релевантные биты кода, то нет никакой двусмысленности для вас или кого-либо еще.
Существует третий вариант. Вместо того, чтобы запомнить все эти правила, или с помощью круглых скобок, чтобы убедиться, что все, ...
Если ваше выражение так долго, что не ясно, что происходит первым, разбить его на несколько строк, используя временные переменные для промежуточного Результаты. Затем вы вводите ясность без беспорядка круглых скобок, и вы можете использовать описательные имена для переменных temp, чтобы сделать вещи еще более ясными.
У меня никогда не было 100% -ного владения правилами приоритета, потому что я работаю на нескольких языках (C, C++, perl, bash и время от времени тире TCL/TK.). В разные годы я работал с несколькими языками ассемблера и с несоответствующим компилятором или двумя.
Я НЕ МОЖЕТЕ хранить полностью подробные правила приоритета прямо у меня в голове - мне нужно слишком часто переключаться между наборами правил.
Быстрый, который имеет более высокий приоритет в T-SQL: И против OR.
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
После того, как вы узнаете, приоритет этих операторов к точке, где вы полагаться на этот старшинства, вы обречены либо:
Да Для:
Нет/Может быть:
Несколько лет назад я увидел эту очередностью таблицу C:
Это немного упрощено, но оно имеет правильную идею.
Очень легко обмануть себя при написании a == a & some_flag.
Даже если я хотел бы предложить не обучение правил приоритета, используя круглые скобки и временные переменный для ясности (помните: код предназначен для чтения человека), иногда таблица оператора старшинства пригождается.
Предполагая, что вы знаете о понятии оператора старшинства (который я предполагаю, каждый делает из математических классов), я предпочел бы не взять на себя какие-либо знания на стороне читателя ...
... для общего, кроме смысл. Как уже отмечалось, выражения, подобные a * b + c, можно понять, используя знания из математических классов. Булевы выражения, такие как a < 4 && a > 0, могут быть поняты, потому что более логично сравнивать сравнения, более плотные, чем &&.
С другой стороны, не существует здравого смысла для смешения побитовых операторов с нормальной арифметикой, поэтому лучше использовать круглые скобки. Также нет здравого смысла для приоритета && более || (или это было наоборот?), Поэтому также используйте круглые скобки.
Лично я * ненавижу * лишние круглые скобки. Если вы не можете вспомнить, какой оператор имеет более высокий приоритет, тогда упростите свое выражение - не добавляйте к нему больше сложностей. – Shog9
Вот ссылка на большее обсуждение, FYI: http://programmers.stackexchange.com/questions/201175/should-i-use-parentheses-in-logical-statements-even-where-not-necessary. Суть одного ответа мне нравится: «Хорошие разработчики стремятся написать четкий и правильный код. Скобки в условных выражениях, даже если они не являются строго обязательными, помогают с обоими». –