|
В этой теме высказываем мнение о том, как правильно писать код (прочитанных где-то, придуманных самим). Ведь хорошо написанный код и легко понимать другим, и легко поддерживать. К этому стремятся многие, но приходят единицы, и то через года.
Если нечего сказать - то лучше не флудить в этой тем. Если есть интересные соображения - высказывайте, обсудим.
2
Антон
Предложу подборку php стандартов, используемую в своем проекте: https://http://sourceforge.net/apps/trac/phpdays/w...RU/about/prin...
3
Алексей
А ещё неплохо указывать:
1. В именах переменных указывать тип данных. Например: iNumber = 1; sName = "name"; oUser = new User; 2. При объявлении закрытых и защищенных переменных и методов неплохо писать так: private $_variable private _myMethod(), а не так: private $variable private myMethod() 3. При разработке MVC скрипты, реализующие: модель - сохранять, как .phpm, контролер - сохранять, как .php, вид - сохранять, как .phtml. 4. Классы сохранять, как class.myClass.php, интерфейсы interface.myInterface.php Это всё полезно, когда работаешь в большой команде разработчиков, над большим проектом.
4
Армен
Алексей Byorty Соломонов чертовски правильные комментарии о они озвучены для ООП. А что ты мог бы сказать про процедурный стиль кодинга?
5
Александр
3 и 4 пункт осуждаю, особенно это class.myClass.php
6
Алексей
Саш, да осуждай ради Бога мировые рекомендации=)Может ты осуждаешь еще шаблоны программирования или вообще ООП=)?
И в правду, наверно неудобно, смотреть на файл и понимать к чему именно он относится и за что отвечает. Наверное, лёгкое конфигурирование Apache - это просто нереальная задача, с которой справятся единицы=) А class.myClass.php - абсолютное зло. Вот представь, тебе необходимо перепрограммировать работу модуля за работу которого, отвечает конкретный класс. Ты работаешь с библеотекой классов, библеотека чужая, самописная, доков нет, в библеотеке около сорока классов с корявыми именами файлов. Модуль необходимо сдать за три дня. Вот интерес сидет и перебирать скрипт за скриптом, и смотреть тот это класс, что тебе нужен или нет. Наверное, открыть библеотеку классов и быстро найти нужный класс по его имени в названии скрипта - это полный отстой... Если осуждаешь, что-то аргументируй свой ответ
7
Антон
Каждый имеет право выбора - это наше законное право.
Например я выбрал изучение Python, и после 5 лет разработки на php5 со всеми возможностями ООП понял, что именно этого мне и не хватало. Я не агитирую, но приглашаю взглянуть на задачи совершенно иным образом.
8
Александр
Алексей, ну смотри, зачем называть файл class.Users.php если можно создать папку objects, если тем более работать с юзером как с объектом, и внутри создать файл User.php с классом User. По сути способ не лучше не хуже, если уж так взглянуть, скорее дело привычки. По-поводу пункта 1 я тоже придерживаюсь венгерской нотации, но помню долго спорил с тогда тим-лидом, он доказывал, что это неверно для php.
Ну а пункт 3 я не знаю. не проще ли организовать все по папкам, там models view controllers. Ну а то что имена файлов как и классов должны быть интуитивно понятно, я согласен, убил бы за функции func1, func2, func3 в и классы типа MyClass1 и т.д. тоже самое можно перенсти и на таблицы и поля при работе с Mysql
9
Алексей
Антон, да я не отрицаю право выбора, я ж написал ради Бога=) Написать "осуждаю" - это легко, а обосновать своё мнение гораздо сложнее, а так пусть каждый делает, что хочет.
PHP - демократичный язык. Армен, по поводу процедурного стиля не могу сказать ничего особенного, т.к. очень мало с ним сталкиваюсь. Так общие рекомендации: 1. Отделение вида от логики(возможно применение Smarty). 2. Использование говорящих имён переменных, типа $query = mysql_query(); А вообще процедурка годится для изучения азов языка, но при реализации проекта любой сложности лучше применять ООП, т.к. создания сайта - это только начало пути сайта в его (возможно)долгой жизни в сети. Даже если сейчас программист или заказчик хочет сделать сайт - визитку, то через месяц заказчик захочет, чтобы прикрутили голосование, галерею, нередактируемый модуль стал редактируемым и т.д. и т.п. В процедурке это сделать весьма проблемотично, а в хорошо спроектированной архитектуре классов - это не доставляет особых проблем=)
10
Армен
ООП стал только изучать. Причём нашёл огромную пользу сразу же. Углубляться не буду но вкратце я с Вами солидарен насчёт ООП. Очень полезная вещь.
11
Алексей
Я могу тебе больше сказать, если собираешь работать программистов или начинать свои проекты, то без ООП никуда=)
12
Андрей
ну почему же, PHPmyAdmin например написана полностю на процедурной парадигме, за счет чего и обеспечивается скорость.
13
Антон
Какая скорость? :)
Скорость приложений написанных с применением ООП подхода чаще оказывается быстрее, чем процедурного. Знаете почему? Дело в том, что ООП код более легко поддерживать и он имеет больше часто используемых участков кода. Т.е. в итоге мы имеем меньше написанного кода и меньше багов. За счет этого скорость получается большей. Важность простоты развития и поддержки проекта гораздо более важна, чем быстро написанный код. который затем невозможно понять никому, включая даже самого автора (спустя пол года). Поверьте - ООП рулит (но не всегда, разумеется). Иногда приходится писать процедурный код, но уже не на ПХП, а на Ми, чтобы создать очень быстрый модуль.
14
Армен
Пршу прощения а что такое Ми???)
15
Армен
Андрей Yii Ярощук
Насчёт скорости могу сказать что всё скорее всего зависит не от стиля программирования а от самого написанного кода. Можно на процедурном стиле такнаписать Гостевую Книгу))))) Что открывать ссылки будет по 4 минуты))) Всё зависит от логики. А насчёт ООП осмелюсь не согласится с фактом скорости обработки кода. ООП по определению не может быть оперативнее процедурного кода если судить по последовательности загрузки кода. Одно наследование чего стоит)
16
Антон
Армен STRANNIK Мосян,
я опечатался: Ми = Си (С++) Я не смею утверждать что ООП быстрее, и это было бы глупо. Но если в ООП я могу написать код просто, то в процедурном тот же код может быть весьма сложен, выполняя многое лишнее. Т.е. в итоге ОП код будет работать быстрее только из-за того, что придется выполнять меньше излишних действий по отношению к избыточному процедурному коду.
17
Армен
А зачем тогда библиотеки даны??)
18
Иван
3. При разработке MVC скрипты, реализующие:
модель - сохранять, как .phpm, контролер - сохранять, как .php, вид - сохранять, как .phtml. А что такое MVC?) и чем phpm отличается от php и phtml?)
19
Алексей
А что такое MVC?
Model-Controller-View и чем phpm отличается от php и phtml? Ничем. Просто для удобства.
20
Алексей
Андрей ♥I love Google♥ Ярощук
phpMyAdmin очень маленький проект, выполняющий очень узкий круг задач, для которого, возможно, не следует разворачивать сложной архитектуры. Если ты делаешь сайт, который тупо выводит информацию из базы, то можешь воспользоваться ПРОЦЕДУРНОЙ ПАРАДИГМОЙ)))))) Если же ты работаешь над большим проектом, вроде http://vkontakte.ru, то советую обратится к ООП. На процедурке, конечно, можно сделать тоже самое, только придется порвать одно место. Армен STRANNIK Мосян Библиотеки даны для того, чтобы php умел не только создавать html странички, но и мог делать, что - то полезное. Только организованы эти библиотеки через задницу - вместо того, чтобы нафигачить кучу функций, нужно было создавать классы, как в Java или C++/C#. Это нужно для того, чтобы жизнь разработчика была в тысячу раз легче. |


Дмитрий
http://http://pear.php.net/manual/ru/standards.php
Хорошо дополняет их следующая статья:
http://http://www.softtime.ru/info/article...php?id_articl...
Предпочитаю использовать комбинированный стиль.