Как стать автором
Обновить

Комментарии 16

Я что гораздо важнее продуманная архитектура приложения
бардак в коде может свести на нет даже самую гениальную архитектуру
Читая чужой код, уже не раз подмечал, что если в коде бардак, то искать за этим кодом продуманную архитектуру — самонадеянно. Чем аккуратней пишет кто-то код, тем больше совершенствуется, в том числе учится проектировать.
Чем вам волшебство не нравится? Кастую файербол 10го левела!
> документирование методов и функций
У Вас есть много времени? У меня — нет.
НЛО прилетело и опубликовало эту надпись здесь
Вы когда-нибудь работали с чужим кодом?
Документирование определенных ф-ций в данном случае не сильно облегчит задачу. Описание логики работы это как раз то что необходимо, но я этого пока не видел ни в одном коде.
У вас его будет еще меньше, когда через месяцок-другой вы будете тратить время на разбор недокументированного кода. А с ростом числа возвратов Х к нему прямо пропорционально будут расти и потери.
Согласен, но тут главное без фанатизма
//метод getId вовращает ид текущего объекта
public function getId(){//начало метода getId()
return $this->id;//возвращаем текущий ид
}// конец метода getId()
Вот такие комменты никаму не нужны
Я за коментирование сложной логики и принципиальных моментов
НЛО прилетело и опубликовало эту надпись здесь
Обобщая сказанное Вами и NikitaG, на мой взгляд, вполне комфортно можно чувствовать себя в коде документированном по стандарту phpDoc (в этом случае комфорт возрастает в той степени в которой IDE умеет использовать этот стандарт) и имеющем пояснения в труднодоступных нетривиальных местах.
Мы не настолько богаты, чтобы покупать дешёвые вещи.
Из той же оперы.
Чем понятнее и структурированее код, тем меньше его надо документировать.
Замечание справедливое, но как уже было замечено, хороший код не означает хорошее приложение (с точки зрения архитектуры).

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