Хороший дизайн требует написания каждой функции только один раз. В PHP я делаю это с помощью подключаемых файлов (таких как Utils.php и Authenticate.php) с помощью PHP-команды include_once. Однако мне не удалось найти какие-либо стандарты или рекомендации для включения файлов PHP. Что бы вы посоветовали в StackOverflow?
Я ищу:
Одно соглашение, которое я люблю использовать, заключается в том, чтобы поместить каждый класс в свой собственный файл с именем ClassName.class.php, а затем настроить автозагрузчик для включения файлов классов. Или иногда я помещаю их все в подкаталог классов/ и просто называю их ClassName.php. Зависит от того, сколько классов и неклассов я ожидаю.
Если вы организуете свои служебные функции в классы и вместо этого сделаете их статическими методами, вам может сойти с рук написание только одного require_once() в ваших файлах верхнего уровня. Этот подход может подходить или не подходить для вашего кода или стиля кодирования.
Что касается возвращаемых типов, я стараюсь следовать соглашениям, используемым во встроенных функциях. Возвращает тип, соответствующий запросу, или возвращает false в случае ошибки. Просто убедитесь, что вы используете === оператор при проверке неверно в результатах.
Тот факт, что вас беспокоят условности, говорит о том, что вы уже на правильном пути. Если вы знакомы с любым другим языком ООП, таким как Java, C++, C# и т. д., то вы обнаружите, что можете следовать многим тем же соглашениям благодаря Преимущества ООП в PHP5.
Какое бы соглашение об именовании вы ни выбрали (я предпочитаю брать пример с Java или C#, где это возможно), убедитесь, что вы используете включаемые файлы для функций, при включении которых они фактически не выполняют никакого кода, и никогда не включайте один и тот же файл дважды. (используйте include-once или требуется один раз)
Некоторые такие стандарты уже написаны. Большинство крупных проектов будут следовать собственным стандартам.
Вот один из них, написанный Zend и являющийся стандартом, используемым во фреймворке Zend. http://framework.zend.com/manual/en/coding-standard.html
Кроме того, в PEAR всегда были довольно строгие стандарты кодирования: http://pear.php.net/manual/en/standards.php
Однако мой предпочтительный ответ заключается в том, что для вашего собственного проекта вы должны использовать то, что вам удобно, и быть внутренне последовательным. Для других проектов следуйте их правилам. Согласованность обеспечивает наибольшую читаемость кода. Мои собственные стандарты не такие, как у PEAR. Я не использую четыре пробела (я использую табуляцию) и никогда не использую верблюжий регистр, как имена функций, но, тем не менее, если я редактирую что-то из другого проекта, я буду использовать все, что делает этот проект.
Я сделал следующее. Сначала я создал перехватывающий фильтр, чтобы перехватывать все веб-запросы, а также создал версию, которая будет работать с командами командной строки.
Оба перехватчика перейдут к загрузочному файлу, который установит автозагрузчик. Этот файл как функция автозагрузки и хеш. Для хеша ключом является имя класса, а значением — путь к файлу класса. Функция автозагрузки просто возьмет имя класса и запустит требование к файлу.
Несколько советов по производительности, если они вам нужны, используйте одинарные кавычки при определении файла, так как они немного быстрее, поскольку они не интерпретируются, также используйте require/include вместо их версий _once, это гарантированно запустится один раз, и первый немного быстрее.
Вышеизложенное здорово, на самом деле, даже с большой базой кода с кучей классов хэш не такой уж большой, и производительность никогда не была проблемой. И, что более важно, мы не связаны каким-то сумасшедшим соглашением об именовании классов псевдопространства имен, см. ниже.
Другой вариант - это имя с разделителями, трюк с псевдопространством имен. Это менее привлекательно, так как пространства имен появятся в версии 5.3, и я считаю это грубым, поскольку переименование их в кодовой базе будет менее увлекательным. Независимо от того, как это работает, предположим, что у всего вашего кода есть корень. Затем все классы именуются на основе обхода каталога, необходимого для того, чтобы попасть туда, разделенного символом, например «_», а затем само имя класса, однако файл будет назван в честь класса. Таким образом, местоположение класса кодируется в имени, и автозагрузчик может использовать это. Проблема с этим методом, помимо real_long_crazy_class_names_MyClass, заключается в том, что при каждом вызове выполняется значительная часть обработки, но это может быть преждевременная оптимизация, и снова появляются пространства имен.
eg.
/code root
ClassA ClassA.php
/subfolder
subFolder_ClassB ClassB.php
