PHP: Шаг к качественному коду и ZendStudio ( Code Assist )

[NikitaG]

Я что гораздо важнее продуманная архитектура приложения

[7workers]

бардак в коде может свести на нет даже самую гениальную архитектуру

[Wave]

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

[Davert]

Чем вам волшебство не нравится? Кастую файербол 10го левела!

[endo]

> документирование методов и функций
У Вас есть много времени? У меня — нет.

[vooD]

Вы когда-нибудь работали с чужим кодом?

[endo]

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

[Kupyc]

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

[NikitaG]

Согласен, но тут главное без фанатизма
//метод getId вовращает ид текущего объекта
public function getId(){//начало метода getId()
return $this->id;//возвращаем текущий ид
}// конец метода getId()
Вот такие комменты никаму не нужны
Я за коментирование сложной логики и принципиальных моментов

[Kupyc]

Обобщая сказанное Вами и NikitaG, на мой взгляд, вполне комфортно можно чувствовать себя в коде документированном по стандарту phpDoc (в этом случае комфорт возрастает в той степени в которой IDE умеет использовать этот стандарт) и имеющем пояснения в труднодоступных нетривиальных местах.

[VoidEx]

Мы не настолько богаты, чтобы покупать дешёвые вещи.
Из той же оперы.

[Davert]

Чем понятнее и структурированее код, тем меньше его надо документировать.

[ipod]

Замечание справедливое, но как уже было замечено, хороший код не означает хорошее приложение (с точки зрения архитектуры).

Определил для себя следующую политику комментирования. Если функция/класс будет доступно как публичное API, то методы комментирую обязательно (чтобы потом можно не парясь составить API). Если нет, то просто стараюсь писать структурировано и давать понятные имена методов и переменных, комментирую сложные места кода + @todo, где что-то надо доделать.

[Wave]

хороший код не означает хорошее приложение (с точки зрения архитектуры).
Зато плохой код почти всегда означает плохую архитектуру. Как выше уже отметил.