текучий интрерфейс

$object ->setSmth1() ->setSmth2() ;

Понял

Сколько новых слов узнал..

Можно ещё прочитать про всё это на вики и закрепить :)

Да, я уже гуглю

зачем phpdoc на них? doc больше занимаeт места чем сами методы

Зачем вообще phpdoc? Он много места занимает.

Зачем документация? Её читать нужно.

Не, ну просто на get/set дока совсем нелепо выглядит. Она больше чем сам метод

Ну, кроме очевидного применения PHPDoc ещё помогает другим средам разработки и редакторам, у которых не такой сильный статический анализатор как у IDEA.

В том же NetBeans при наличии PhpDoc у методов классов жить сильно проще. По крайней мере, год назад так было.

Ещё по нему можно доку генерировать. Публичное API класса всё-таки.

Зачем вообще phpdoc? Он много места занимает.

1) он кушает память 2) документация всегда врет, код нет

На смену придет указывание типа переменной?

1) он кушает память 2) документация всегда врет, код нет

Ужас!

На смену придет указывание типа переменной?

Если речь о тайпхинтинге, то нет, это разные вещи, хоть и пересекаются в IDE.

Ужас!

проще за IDE заплатить нормальную чем за +50 серверов

проще за IDE заплатить нормальную чем за +50 серверов

А можно послушать прохладную историю про 50 серверов из-за PhpDoc?

А что еще в доке может быть написано полезного кроме типа вввода и вывода

А что еще в доке может быть написано полезного кроме типа вввода и вывода

Возвращаемое значение? Выбрасываемые исключения?

например такое /** * Не прошло и n лет, как написан класс для управления услугой. * Спасибо моим родителям за то, что они дали миру меня. * * Если кто увидит в коде класс CustomerV - знайте, это предыдущая реинкарнация этого класса. * И функционал из CustomerV надо переносить сюда, если таковой ещё остался. */

например такое /** * Не прошло и n лет, как написан класс для управления услугой. * Спасибо моим родителям за то, что они дали миру меня. * * Если кто увидит в коде класс CustomerV - знайте, это предыдущая реинкарнация этого класса. * И функционал из CustomerV надо переносить сюда, если таковой ещё остался. */

Какое отношение петросянство в комментарии имеет отношение к phpDoc?

Какое отношение петросянство в комментарии имеет отношение к phpDoc?

самое прямое, потому что будут либо такие комменты, либо вот такие /** * */ public function getCustomerId ()

самое прямое, потому что будут либо такие комменты, либо вот такие /** * */ public function getCustomerId ()

Ну, у меня плохие новости о команде разработчиков тогда :)

у меня тоже для тебя плохие - любые комментарии врут, вместо времени на КРАСИВОЕ ОФОРМЛЕНИЕ phpdoc лучше потратить время на написание unit тестов, спек или хотя бы приемочных тестов

А API я буду по юнит-тестам генерить? А спеки - это не документация? Они не врут?

1) он кушает память 2) документация всегда врет, код нет

1. бред какой-то.

1) он кушает память 2) документация всегда врет, код нет

я то думалю что у меня там много памяти в пустую летит

1. бред какой-то.

а как по твоему работают аннотации? они хранятся в памяти, иначе php их бы выпиливал

а как по твоему работают аннотации? они хранятся в памяти, иначе php их бы выпиливал

ты про аннотации или PHPDoc?

ты про аннотации или PHPDoc?

аннотации расположены внутри phpdoc

А API я буду по юнит-тестам генерить? А спеки - это не документация? Они не врут?

phpspec точно не врет ;)

Это новость.

самое прямое, потому что будут либо такие комменты, либо вот такие /** * */ public function getCustomerId ()

Я соглашусь с тем, что PHPDoc можно не писать в случае, если без них IDE всё понимает и не корябится.

А API я буду по юнит-тестам генерить? А спеки - это не документация? Они не врут?

документацию к API можно с тем же успехом генерировать с помощью рефлексии

документацию к API можно с тем же успехом генерировать с помощью рефлексии

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

И тут я ловлю себя на том, что начал писать статический анализатор для генерации доки...

Потому, что хотел сэкономить по несколько килобайт с файла.

ну а так написан синтаксический анализатор файла

Ужас какой.

мир взорвется если не будет культа карго по phpdoc и таких отличных комментариев * конструктор это __construct * метод выкидывает исключение LogicException с пустым текстом

у меня тоже для тебя плохие - любые комментарии врут, вместо времени на КРАСИВОЕ ОФОРМЛЕНИЕ phpdoc лучше потратить время на написание unit тестов, спек или хотя бы приемочных тестов

Это удобно если ты один разрабатываешь, или вдвоем хотя-бы.

Я думаю когда команда будет из 10ти человек то они тебя нахуй пошлют со своими тестами, читая метод чтобы понять зачем он

Не, ну давайте мух от котлет отделять. Тесты - это хорошо. phpDoc - для других целей сделан. И он действительно хорош когда надо работать в команде или если проект опенсорсный. Да, он жрёт память немного, но это экономия на спичках. В PHP и так всё плохо с памятью и на срезании комментов сэкономить особо не выйдет.

Я думаю когда команда будет из 10ти человек то они тебя нахуй пошлют со своими тестами, читая метод чтобы понять зачем он

в команде из 2+ разработчиков либо пишется код не требующий комментариев, либо рефакторится до такого состояния

Не, ну давайте мух от котлет отделять. Тесты - это хорошо. phpDoc - для других целей сделан. И он действительно хорош когда надо работать в команде или если проект опенсорсный. Да, он жрёт память немного, но это экономия на спичках. В PHP и так всё плохо с памятью и на срезании комментов сэкономить особо не выйдет.

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

Не, ну давайте мух от котлет отделять. Тесты - это хорошо. phpDoc - для других целей сделан. И он действительно хорош когда надо работать в команде или если проект опенсорсный. Да, он жрёт память немного, но это экономия на спичках. В PHP и так всё плохо с памятью и на срезании комментов сэкономить особо не выйдет.

есть команда пусть это двое. если метод/функция требуют комментирования - то код слишком сложен, это может быть сложный алгоритм, просто много строк кода, описание бизнес правил тогда код нужно упрощать, писать имена переменных, методов более осознанно с подсказками для apidoc - ide отлично справляется с этим, phpdoc ни как не влияет на валидацию данных передаваемых как аргументы и не стоит забывать что php изначально динамически типизируемый. в ситуации когда передается аргументом ассоциативный массив phpdoc тоже слабый помощник в доктрине есть uow, так вот из phpdoc комментариев не разберешься как это все работает и зачем так. есть user guide документация, она лучше решает задачи документирования. ну и я говорил что комменты очень часто врут, а код нет, легко начать принимать вместо строки число как аргумент и так же легко забыть исправить phpdoc

по моему опыту phpdoc нужен только джунам которые не в состоянии понять метод на 20—30 строк

нет

всем нужен

а кто его не пишет - дурень

вот коменты в коде это бред

А я всегда комментирую код :(

Больше не буду

docов хватает

по моему опыту phpdoc нужен только джунам которые не в состоянии понять метод на 20—30 строк

чего ? что за бред. phpdoc тужен не только для говно кода . еще как минимум для ide.

чего ? что за бред. phpdoc тужен не только для говно кода . еще как минимум для ide.

для говно ide нужен phpdoc

для говно ide нужен phpdoc

ясно, вопросов больше нет.

ясно, вопросов больше нет.

каков наброс - таков ответ

каков наброс - таков ответ

нет вопрос был другой. что ide подсказывает параметры по доку

и как быть с магическими параметрами

и т.д.

и как быть с магическими параметрами

zf1 когда нить преходилось дебажить?! если да и то 100% будешь избегать magic methods

кря!

zf1 когда нить преходилось дебажить?! если да и то 100% будешь избегать magic methods

плюсы минусы подхода это другой разговор. тут шло о phpdoc

Если проект не маленький, то доки нужны (а значит всегда нужны, ибо проекты растут). Нужно это из-за большого количества людей и разной их подготовки. Одним доки не нужны (их что, заставляют читать?), другим необходимы (как минимум понять как код соотносится с бизнес логикой). Кто не пишет доки закапывает проект, не дает ему развиваться и расти. IMHO

Если проект не маленький, то доки нужны (а значит всегда нужны, ибо проекты растут). Нужно это из-за большого количества людей и разной их подготовки. Одним доки не нужны (их что, заставляют читать?), другим необходимы (как минимум понять как код соотносится с бизнес логикой). Кто не пишет доки закапывает проект, не дает ему развиваться и расти. IMHO

Человек выше видимо писал только маленькие проекты =(

даже если маленький

все равно нужен

вот убило у меня разработчика сосулей

пришёл другой, прочитал доки, понял как и что работает

и не сидит неделю не вникает

ну и да + в иде

вы ещё скажите что тесты не нужны

А че они нужны?)

Тесты

вы ещё скажите что тесты не нужны

тут люди доки не используют а от тестов в обморок упадут, не надо так

для говно ide нужен phpdoc

Ну, так-то PHPStorm понимает вводимые данные через указание типа + ошибку пишет если не тот тип. Так же пишет название переменной. Но пхпдок все равно нужен по-любому. Для ORM какой-нибудь или AR и т.п.

zf1 когда нить преходилось дебажить?! если да и то 100% будешь избегать magic methods

До сих пор на zf1 проекты пишем.

До сих пор на zf1 проекты пишем.

надеюсь не новые.

надеюсь не новые.

Нет,конечно. Новые вообще без фреймворков начинаем. При правильном проектировании фреймворк часто не нужен. Если не кондовый вэб

Нет,конечно. Новые вообще без фреймворков начинаем. При правильном проектировании фреймворк часто не нужен. Если не кондовый вэб

берете популярные компоненты и пилите свой фрейм ?

берете популярные компоненты и пилите свой фрейм ?

И да и нет. Берём нужные компоненты, но фреймворки не пишем.

И да и нет. Берём нужные компоненты, но фреймворки не пишем.

а что обычно пишите ? чтото типовое ?

и кто это поддерживает

считаю это расточительством и не поддерживаю

а что обычно пишите ? чтото типовое ?

Ну, из последнего, обработка кредиток или бизнес-интелидженс (агрегация данных). Покрытие тестами - 90%.

хотя для такой ниши они может и не нужны)

Если тесты хорошо написаны, то часть доков можно выкинуть

На счёт доков - нет смысла спорить, все очень ситуативно. От компании к компании, от проекта к проектк

Если проект не маленький, то доки нужны (а значит всегда нужны, ибо проекты растут). Нужно это из-за большого количества людей и разной их подготовки. Одним доки не нужны (их что, заставляют читать?), другим необходимы (как минимум понять как код соотносится с бизнес логикой). Кто не пишет доки закапывает проект, не дает ему развиваться и расти. IMHO

документация бывает разной. phpdoc для документирования большого проекта - иллюзия документации. я предпочту иметь ТЗ в котором есть описание сущьностей, UML диаграммы, описание точек входа, архитектуры

а где гарантии, что разработчики придерживались ТЗ и схем?

документация вида помогает только джунам /** * этот метод отправляет собщение от одного пользователя другому * @param $user1 User пользователь который посылает сообщение * @param $user2 User пользователь которому посылаю сообщение */ public function send(User $user1, User $user2) лучше писать так public function sendPrivateMessage(User $from, User $to) - тут не нужно быть гением чтобы понять что делает метод и что принимает на вход. сигнатура видна в IDE в панели методов

а где гарантии, что разработчики придерживались ТЗ и схем?

я уже выше писал что любая документация врет, кроме кода

Ну, так-то PHPStorm понимает вводимые данные через указание типа + ошибку пишет если не тот тип. Так же пишет название переменной. Но пхпдок все равно нужен по-любому. Для ORM какой-нибудь или AR и т.п.

давай я пример покажу как не нужно использовать phpdoc - https://github.com/beberlei/assert/blob/master/lib/Assert/Assertion.php#L18

https://github.com/beberlei/assert/blob/master/lib/Assert/Assertion.php#L18 вместо фасада, обычного 10500 раз всем знакомого паттерна - используется магия с phpdoc. а всё почему - писать больше на 2-4 строчки. проще в ногу себе выстрелить и побыстрее