Имхо, в таких выражениях для наглядности обязательно ставить скобки, чтоб не вспоминать на ходу приоритет операторов и не спотыкаться на различиях ||-or и &&-and...

Прочитал две страницы, и решил посеять зерно сомнения в ваших, без сомнения, светлых головах  Для пишется понятный красивый и правильный код ? - вернее сказать для кого ? Если вы пишите код для преподавателя по программированию, то, конечно мы все ставим отступы, разделяем и все остальное. А кто ни будь задавался написать правильно работающий, оптимально  работающий но ужасно не читаемый код ?  Для чего ? для того чтобы ваши последователи потратили на то чтобы в нем разобраться столько же времени, сколько потратили бы на написание своего с нуля. 
Сколько пишу на пхп, постоянно ловлю себя на мысли, что мозг не работает, тут нет ничего сложного, после 2го сайта все пишется уже подсознательно, вместе с чатами, фильмами и смс. А когда пишешь <вырезано> код, без структуры, с определением функций в функциях, с переопределением глобальных переменных, с кривыми комментариями, которые понятны только мне  (на примерах и метафорах из жизни) и все еще это пополняешь названиями функций типа Audi_R8 или zzt213 (кузов новой тойота селика),  то в голове приходиться держать массу всяких ассоциаций и сравнений, что делает процесс хотябы более интересным и требовательным к себе, нежели просто , простите, тупо 
$OB1.="bye;" echo $OB1; unset ($OB1).

Нужна ли эта красота и порядочность в и без того простых кодах, когда вы пишете свое для себя под себя, и так чтобы кроме вас это пользовать никто не смог?

M skyboy

мата не надо. даже с одной замаскированной буквой

Это сообщение отредактировал(а) skyboy - 12.12.2007, 09:23

ну, да. конечно. машина, для управления которой надо будет полгода учиться в ВУЗе - это самая что ни на есть хорошая машина, потому что заставляет думать и вспоминать, каким образом можно переключиться с первой передачи на вторую. как же.
а как же ошибки? легко их отлавливать, если постоянные eval? а если функции в функциях?
как быть при добавлении нового функционала через полгода? удобно? просто? без ошибок?
нет, товарищ, с такими взглядами жить будет трудно...

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

Не знаю, насколько сложные проекты Вы писали, но мое мнение - не очень сложные и не профессиональные.
Да, если пишешь скрипт на 20 строк, то можно обзывать переменные a, b, c и т.п. но если объем кода переваливает даже за 10-20 кб, то (во всяком случае у меня), начинаются проблемы с запоминанием всех имен переменных, функций, классов и т.п. А если они еще и будут названы, как Вы предложили, то проект не будет закончен никогда! Все время уйдет на поиск и попытки написания таких имен. А если еще и пишешь не сам, а в команде - то еще дольше!  
Плюс дальше будут БОЛЬШИЕ проблемы с редактированием кода. Вспомнить даже через 2 - 3 дня после написания что именно делает функция с именем zzt213 (особенно если она не очень большая и используется не часто) будет проблематично.
Основные усилия при написании программы должны быть направлены не на разгадывание ребусов с именами переменных, а на построение, написание и отладку логики программы. Если название переменной или функции выбрано правильно - редактировать код можно даже не зная абсолютно точно где и как переменная используется, а просто видя перед собой локальный кусок кода (серьезные изменения так лучше все-таки не делать, но для мелких - самое то).
А  вот как выбирать имена - это уже искусство.

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

Если же подходить к его заявлениям серьёзно, то есть вещи, которые невозможно объяснить - их можно понять только на собственном опыте. К примеру, все эти многочисленные заверения о том, что он сам через два дня забудет. 
Тем более, что он сам говорит, что "усложняет" код для развлечения. Ну развлекается человек и развлекается. Мало ли какие у кого странности. Смысл чьи-то личные тараканы в теме, посвященной технологии в целом?

Впрочем, повторюсь, я всё равно не верю, что все это написано всерьёз, а не с целью развлечься.

Понял!
FCCStepan пишет просто crackme на php!
 

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


Feldmarschall, Про сетевого троля не очень понял сравнение .

N0dwis,  если совсем асбтрагриоваться, то можно и так сказать. 


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

Ладно  продолжайте сабж )

FCCStepan, это называется обфускация и ею совершенно не нужно заниматься программисту самому.

По теме же, можно спорить бесконечно. Однако важно одно, что бы вы всегда придерживались *одного* стиля.

Полностью согласен.

Код должен иметь возможность к расширению и быть достаточно гибким + http://agilemanifesto.org/


Для шаблона, имхо, твой вариант не менее ужасен, всего 4 переменных да ещё и с заранее заданными именами, где же гибкость?

Плясать нужно начинать от стандартов кодирования Zend.

Если что-то сильно не нравится - используем свое. Чем более распространенный стиль написания кода вы используете, тем легче его будет читать другим кодерам.

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

ИМХО "красиво" написанный код повышает "КПД"  программиста и уменьшает в будущем время отладки.

ЗЫ: Так же есть стандарты PEAR, но лично мне по душе больше Zend.

Однако, вопреки стандартам Zend:
1. Не использую завершающий тег "?>"
2. Иногда использую другой стиль объявления массивов
3. Вместо "elseif" использую "else if" (C++ Style)
4. Если возникают вопросы, какую функцию использовать (напр. count или sizeof) - опираюсь на стандарты языка С++.

Ссылки по теме (4 разных стандарта кодирования):
http://framework.zend.com/manual/en/coding...ding-style.html
http://pear.php.net/manual/en/standards.php
http://drupal.org/coding-standards
http://tony2001.phpclub.net/doc/standard/

Выбор только за вами.

Это сообщение отредактировал(а) CyClon - 24.2.2008, 10:55

CyClon, 

по-моему как раз-таки у Зенда написано НЕ использовать завершающий тег, если нет перемешки php и html (я тоже не использую ;)).


ага, а потом придет человек, который все время писал, придерживаясь Зенда (например) - и будет разбираться в вашей, понятной только вам, иероглифической каше =)

P.S. вот в этом плане Python мне очень нравится - даже отступы "стандартизованы" - если в следующей строке будет не такое количество отступов, как в изначальной - компилятор выдаст ошибку =) Отличное принудительное обучение людей писать правильно =)) На такой код любо посмотреть ) К тому же некоторые (Sun (Java), Python, др.) выкладывают официальные Programming Style Guide'ы, следовать которым - ну я считаю уважением к языку.

Это сообщение отредактировал(а) dsCode - 24.2.2008, 12:21

Ну, я конечно не имел ввиду код без отступов, писанный человеками-обсуксаторами  Просто в некоторых моментах можно навалять на стандарты и писать как нравится. Например, если не нравится именование функций следуя верблюжей нотации (getFile), можно писать в C-Style а-ля get_file. Все зависит еще от подготовки кодера. Например, многие пишут при сравнении слева констанку, а справа переменную, чтобы "случайно не написать = вместо ==". Лично я таких ошибок на своей памяти за 2 года помню максимум штуки 3  А писать константу слева - как-то непривычно и некрасиво. Хотя тут уже нужно определяться, или использовать всевозможные защиты от дурака (отказ от использования завершающего тега, чтобы не допустить случайных пробелов в конце кода; постановка константы в левой части выражения для условных операторов) или же писать так, как приятней 

ЗЫ: Сейчас перечитывал все 4 стандарта, все разные  Но PEAR помоему изменился неслоабо (особенно в плане использования фигурных скобок).

Что не понравилось в PEAR сейчас:
1) Использование "elseif" (я использую "else if"
2) Синтаксис оператора switch (здесь я использую Zend-Style)

Плюс ко всему, не могу определиться с именованием. Очень все стандарты разные, причем у каждого именования свои плюсы и минусы.
В классах использовать сокращения типа HTML в верхнем регистре делает названия классов непотяными (Например: HTMLFormBuilder, HTMLToXML). Использование только первый заглавной буквы - некрасивыми (HtmlFormBuilder, HtmlToXml). Однако, скорее придется использовать второй вариант.

Далее с функциями и переменными. В одном из стандартов призывают использовать C-Style имена переменных и функций ($var_name, $life_time, get_file(), set_value()), да бы не путать их с чем-то там  Однако форма записи мне ужасно ненравиться, намного красивее - $varName, $lifeTime, getFile, setValue). Хотя... Я сейчас все больше стараюсь использовать ООП, работать с классами, поэтому обычных функций приходиться объявлять все меньше и меньше. В классах же использование верблюжей нотации в методах как раз приветствуется.

ЗЫ: Пока писал, даже немного определился со "своими стандартами". Пора бы уже твердо это усвоить и писать годами код в одном стиле.

Ну, и наконец, вспомнил про include. Тут то же, что и с константами слева, и заверщающим тегом. Наверно буду использовать include_once и require_once и работать на "максимальную защиту от дурака а-ля случайных ошибок". Однако, include/require являются такими же конструкциями (а не функциями) языка, как и return. Тут я опять стал на перепутье - использовать скобки или нет?

С-Style:

Или же:


В общем, больная тема, уже надоела  Четких стандартов нет, поэтому приходится все-таки использовать свои.

Добавлено @ 13:57
Кстати, иногда встречал такое написание кода:



Кто как смотрит на доп. пробелы по бокам внутри скобок?  Одновременно смотрится понятнее, но и уродливее 

Это сообщение отредактировал(а) CyClon - 24.2.2008, 13:58

совершенно не согласен, у меня внимание разбегается, а код зрительно распадается
для меня оптимально иметь пробелы вокруг таких элементов как: = == === + - /
но никак не скобок

ещё и фигурные скобки

так по-моему оптимально