7workers Apr 19 2009 at 10:25

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

1 min

676

Lumber room

-8

Comments 16

NikitaG Apr 19 2009 at 10:38

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

7workers Apr 19 2009 at 11:07

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

Wave Apr 19 2009 at 19:38

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

Davert Apr 19 2009 at 10:55

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

endo Apr 19 2009 at 11:34

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

UFO landed and left these words here

vooD Apr 19 2009 at 11:59

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

endo Apr 19 2009 at 13:01

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

Kupyc Apr 19 2009 at 12:07

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

NikitaG Apr 19 2009 at 12:43

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

UFO landed and left these words here

Kupyc Apr 19 2009 at 14:41

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

VoidEx Apr 19 2009 at 12:41

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

Davert Apr 19 2009 at 14:34

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

ipod Apr 19 2009 at 15:10

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

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

Wave Apr 19 2009 at 19:41

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