Тема очень интересная и актуальная.
Автору как всегда зачот! Полезное дело делает.
Даже то, что мы спорим - это очень хорошо, значит вопрос актуален, каждый высказывает свое мнение
.gif)
---
Кстати, по поводу увиденного несколько выше:
// Пример следования правилу.
$isOutOfBounds = elementIndex < 0 || elementIndex > MAX_ELEMENTS;
$finished = elementIndex == lastElementIndex;
if($isOutOfBounds || $finished){
...
}
Тут я согласен с UA95 и по моему мнению, присутствует индокод в виде 2-х паразитных переменных. Предыдущий пример более правильный, а для повышения читабельности, достаточно использовать круглые скобки, выделив ими логические цепочки.
AlkatraZ, понемаешь в чем разница между наукой и не наукой? В науке есть фундамент и критическая оценка, в PRS я не вижу этого. Я старался реализовать свой стандарт так, чтобы его можно было критически оценивать, а именно любой его прочитавший мог усомниться и сказать: в этом случае лучше зделать так, а не как ты это сдела - а я, в свою очередь, попытался защитить мое решение контраргументом, в PRS этого нет. Так же в PRS нет фундамента. Если я скажу что их решение переносить открывающую фигурную скобку тела функции на новую строку я считаю менее читабельным, простым и эффективным, мне никто не сможет доказать обратное, так как корень мысли у меня свой, а у аппонента свой, в моем же случае, есть критерии оценки правила, которым оно должно следовать, и я готов пересмотреть эти критерии, если кто то предложит их дополнить или поменять местами их приоритет.
AlkatraZ, По поводу условия я частично согласен. По правде говоря есть очень много подобных правил, которые я (возможно еще) не включил в стандарт из за их сомнительности. Данное правило я намеренно указал следующим образом:
"В случае, если логическое выражение включает более двух подвыражений, следует оценить его читабельность и, возможно, выделить подвыражения в переменные с "говорящими" названиями"
То есть я хочу лишь обратить внимание программиста на сложные логические выражения, и если программист действительно увидет их сложность, предлагаю решение этой проблемы. Если у вас есть более качественные решения, я конечно же изменю правило, но я думаю никто не будет спорить с утверждением, что длинные, многочленные логические условия читать сложно и с этим нужно как то бороться.
По поводу выделения логических блоков выражения скобками я согласен, но здесь есть возражение: действительно ли это повышает читабельность кода, другими словами, позволяет ли добавление скобок в сложное логическое выражение быстрее оценить его цели и задачи? Сомневаюсь.
# Delphinum (10.11.2013 / 17:57)
Если я скажу что их решение переносить открывающую фигурную скобку тела функции на новую строку я считаю менее читабельным, простым и эффективным, мне никто не сможет доказать обратное
В тех стандартах специально нет догматики по мелочам, чтоб кодеры сами могли выбрать для себя нужный путь. Оговариваются только ключевые и важные моменты.
Так, или иначе, стандарт (пусть и рекомендуемый) есть стандарт. Он рекомендуемый, посему следовать ему не обязательно, но я лично считаю, что код по тем стандартам выглядит красиво. В начале надо немного отказаться от своих привычек, но зато потом все удобно и уже автоматом пишешь код, который вписывается в те стандарты.
AlkatraZ, ну тут я могу спорить долго, я ведь тоже никого не заставляю следовать стандарту, я всего лишь сопровождаю мои правила аргументацией, которую готов оценивать с критиками, вот и все ;)
# Delphinum (10.11.2013 / 17:37)
BoGdAn, вот насчет "намного быстрее" не согласен )
Ну я относительно. А так в 2раза быстрее.
# Delphinum (10.11.2013 / 18:00)
По поводу условия я частично согласен. По правде говоря есть очень много подобных правил, которые я (возможно еще) не включил в стандарт из за их сомнительности. Данное правило я намеренно указал след
Главный принцип должен быть такой: код максимально чистый, никаких паразитных переменных.
---
Давай еще раз разберем кусок кода:
if(elementIndex < 0 || elementIndex > MAX_ELEMENTS || elementIndex == lastElementIndex){
Ъ
Для улучшения читаемости его при желании можно сделать многострочным (если условий много), но вот в последующем примере разбивка по переменным была сделана логически неверно.
Тут выражение простейшее, отлично читается и не нуждается даже в скобках.
Чтоб сразу же разобраться, достаточно помнить принцип действия логического орператора ||
А именно, следующая часть проверяется только тогда, когда предыдущая часть FALSE
И если мы вдруг разобьем все по переменным, визуально это намного ухудшится, ибо кроме паразитных переменных, теряется (визуально) логическая цепочка и мне приходится бегать по лишним выражениям, чтоб понять. откуда берется данная переменная.
# Delphinum (10.11.2013 / 18:07)
которую готов оценивать с критиками, вот и все ;)
Абсолютно верный подход.
Вот мы и спорим, критикуем, обсуждаем
BoGdAn, есть еще одна причина, из за которой я призываю использовать именно конкатенацию (о ней я уже говорил ранее). Дело в том, что в своей работе я пользуюсь не только PHP, а еще и Java, JS, C++ и т.д. Так вот при переходе между языками мне бы хотелось (как и любому ленивому программисту) не сильного изменения стандарата, дабы не пришлось запоминать для каждого языка особенности стандарта. То есть знаю я что в стандарте PHP я обрамляю пробелами символ присваивания, значит и в этом языке я должен делать то же самое. Так вот передача в выходной буфер информации в виде аргументов некоторой операции (как echo a,b,c) реализована не во всех языках (на пример в JS такого нет, такого нет и в Java), потому в этих языках я использую конкатенацию, и мне бы хотелось (согласно предыдущими утверждению) использовать конкатенацию и в PHP, при том, что это не сильно влияет на производительность программы да и делает ее более доступной большенству программистов, не снижая читабельности (если уж совсем откровенно)
AlkatraZ, тут полностью согласен. Более того, готов сформулировать еще два правила построения логических выражений:
1. Если корневой уровень логического выражения (то есть уровень первых скобок, а не вложенных) состоит из оператора ||, то в качестве первого подвыражения должно находится выражение, которое с большей вероятностью будет истино.
Данное правило позволяет быстро привести логическое выражение к истиности, что повышает эффективность.
2. Аналогично 1, только при использовании оператора И нужно ставить первым выражение, которое вероятнее всего будет ложным.
Объяснение то же
