Уф дочитал. Много интересного узнал. Всё замечательно, т.е. есть замечания:
 вы напрасно развили тему как писать 
Это как раз то, что можно оставить на откуп программеру или кодеру (в завивимости от квалификации).
Гораздо важнее чтобы эту конструкцию не сокращали, т.к. тогда теряется прозрачность кода.
Естественно важно как именовать функции, но гораздо важнее создать структуру кода, и не с помощью большого дерева подкрепляемых файлов (include "file.php"),  а с помощью создания модулей (в моём понимании функции, классы). А если писать монолитный код, то хоть как ты именуй функции и пиши if then else, с ростом кода потеряется его смысл. Да и если писать такие вот модули, то инклудить можно будет в одном месте (в начале).
Также, очень важно проектирование, частично затронуто абзацем выше, т.е. формирование заголовков, внутренних ссылок и т.д в проекте.
P.S. со времен java  я делаю мануалы во время написания кода, используя самописную утилиту по образу и подобию javah

Одинарные кавычки работают быстрее чем двойные так как не включается интерпретатор замены. Поэтому 

Будет работать быстрее чем тоже самое в двойных кавычках.
Рекомендую в фунциях, условиях и различных операторах использовать использовать именно одинарные кавычки.
например


Максимально отделить программирование от гипертекста. Чтоб функции расчета, баз данных, создания, обработки возвращали лишь код. А вывод гипертекста или определения переменных шаблона было только в однои месте. Так легче отладку делать, читать код и заменять в случае чего вывод. Не надо лазить по инклюдам и другим файлам. 

Текст ошибок и сообщений, и вообще весь текст более менне статического назначения естественно лучше хранить отдельно в файле. Куда потом может зайти любой человек дорабатывающий проект и изменить "проффессор" на "профессор" без поиска по проекту или лазания по коду.

Лучше разрабатывать код с включенными warnings, notices  и тд. Так видней недоработки. И код будет правильней.

Хехе, одинарные кавычки - это уже мем.
Ну, и диагноз, разумеется =)

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

Про хранение всех сообщений в отдельном файле мысль правильная, но требует определенного понимания и полного пересмотра архитектуры, разумеется.


Это сообщение отредактировал(а) Feldmarschall - 11.6.2008, 20:14

И всё-таки отделение кода от гипертекста это "правило" тесно связано с поставленной задачей. 

От себя добавлю (если этого не было) как можно меньше регулярных выражений.
sizeof() быстрее и красивее count()
как можно проще индексы массивов (числовые лучше всего)

хехе, ещё один =)
sizeof(), даже если бы она не была одной и той же функцией, что и  count(), все равно не была бы быстрее или медленнее. 
То же самое и с массивами. да делайте те индексы ,которые удобнее. Если раз в сто лет этот индекс станет узким местом - переделаете. 
когда ж вы поймете, что ахиллес все-таки перегонит черепаху?

хоть какая-то нелогическая отпимизация никогда не мешала.
представь 10к^2 обращение к массиву 



тем более что займет это всё ровным счетом минимум времени...( я про оптимизацию xD )

Добавлено через 10 минут и 15 секунд
Если можно отнести к правилу хорошего кода, для серьёзного проекта, то это несомненно:
Кэширование повторно используемых данных внутри классов, запросов

Это сообщение отредактировал(а) boogi - 12.6.2008, 00:31

Если эта страна и погибнет, то только из-за таких "мыслителей". 
И ведь на полном серьезе обсуждается, каким концом разбивать яйцо. Со времен Свифта ни-че-го не изменилось. Понять действительно важные вещи в состоянии единицы. А остальные будут заниматься оптимизацией длины имен переменных

При чем тут это, философ? Посмотри на название топика. И лучше не пытайся прыгнуть выше головы.

PS: Я буду только рад если та страна про которую ты говоришь погибнет.

Видимо имелось в виду, что функции модели должны возвращать только данные или код результата(не в смысле php код), т.е. не должны возвращать "Выполненно успешно", а лучше "success" или какое-то заранее определённое значение.

Сам же я хотел такой вопрос задать, из области не очень повседневной:
Принято (обычно/часто вижу такое) приватные методы называть с подчёркиванием в начале и маленькими буквами, тогда как публичные - с использованием больших(в верблюжьей или иной нотации - не важно). В часности, в php4 это часто применялось, чтобы можно было сразу видеть, какие методы предназначены для вызова извне, а какие выполняют утилитарные функции и вызываются другими методами класса. Столкнулся с тем, что как бы не хотелось, но в некотором классе набралось довольно болшое количество публичных методов, причём часть из них, тем не менее, также вызывается в других из низ. При этом эти методы я не могу сделать приватными в силу того, что они иногда мной применяются-таки в остальной части скрипта, хотя и довольно редко. Использует ли кто-то специальные способы разделения методов класса "по частоте использования" путем именования специальным образом?

Не могу представить. Зачем нам 100млн обращений к массиву? 


По типу операций и возвращаемым результатам - да. По частоте нет.

например

getSomethingList - возвращает массив
getSomethings - возвращает массив объектов Something
updateSomething - обновляет Something

Добавлено через 4 минуты и 41 секунду
Sannis, 

Имеется класс для работы с базой, примерно 250 методов работать во всяких блокнотах - сложновато. В Zend Studio - нормально.

Преимущества IDE я уже оценил) Что-ж, спасибо, пока не буду размышлять, не очень-то они и мешают.

Почитал всю тему, очень интересно читать такие дисскусии и обсуждения, а особенно для новичков.
Сам на php пишу относительно не так давно, но стараюсь читать как можно больше инфы касающейся php.
Когда начинал прочитал одну очень интересную книжку PHP5 на примерах (М.Кузнецов, И.Симдянов,С.Голышев) откуда впринципе и узнал про стили программирования(о чём даже представления не имел, до того момента)
там описано 4 стиля (расставления фигурных скобок)

И для себя наиболее удобным и читабельным посчитал Стиль GNU.
Это я к тому что стилей много, думаю эти 4 только малая часть всех существующих, хотя могу и ошибаться, стилей много и каждый кодер выбирает тот который удобен ему.
Так же придерживаюсь тона при названии переменных, функций, разделения пробелами +/=/- и т.д., т.к. сам нарывался на скрипты где в названии переменных использовали что то вроде $l_gh а функции назывались $drw_n при этом комментарии в коде отсутствовали вообще.
Так же хотелось бы задать опытным кодерам вопрос, может и покажется он глупым, но всё же, предподчительно в какой кодировке писать скрипты? я юзаю utf-8.
P.S.
ИМХО - Хорошего тона, должны придерживаться все кто кодит, тем самым проявляя уважение к другим кодерам.  


Это сообщение отредактировал(а) Цербер - 16.6.2008, 10:31

 Это происходит при лексическом анализе, поэтому не имеет роли. Ведь на серваке по любому будет кеширование байткода.

P.S. Кстати непонятно, нахрена замену делали, неужели было влом лишние 2 условия в StateMachine вписать? Хрен этих разработчиков поймешь )

 Предпочитаю Java-style.



 В однобайтовой. i18n не планируется у меня. Для i18n же utf-8 бы юзал.

0. Логика визуализации и бизнес-логика - абсолютно разные вещи, это стоит держать отдельно друг от друга.
1. Табы или 4 пробела - это не важно, главное, чтоб другим оно не мешало.
2. По правилам кодинга (не программирования) существуют strict-стандарты для java, я стараюсь держаться именно за них.

пример в студию 

Мой стиль вот:

Пришел к нему,  как к самому удобному,  достаточно удобно его читать 

Это сообщение отредактировал(а) gta4kv - 22.6.2008, 19:27