Исходное сообщение
"Рабочий стол Budgie переходит с GTK на библиотеки EFL от про..." Отправлено ммнюмнюмус, 18-Сен-21 02:09
Что значит тру - как в suckless что-ли? Конечно, подход к документированию как в doxygen и gtk-doc сильно неудобный, т.к. там документация как правило дублирует имеющуюся инфу. Например, описание функции польностью повторяет объявление функции. А в описании структуры - вся структура. Ещё это железъное правило - коммент перед кодом. Верно, но только иногда. Комент может быть первым только если выполняет роль заголовка (для секции относительно громоздкого кода). Если же это описание для документации, то оно идёт после (либо в конце, либо на следующей в строке), лучший пример - man страницы из руководств Linux, POSIX и libc. Такой исходник должен быть поприятнее для чтения, при том, что сгенерировать удобные pdf и html всё также не проблема. Просто генератор должен извлекать информацию из самого исходника. Кстати, создавать pdf и html непрямую вообще не нужно. Хватит поддержки markdown, asciidoc или retext - из них потом (если очень хочется) можно что угодно сгенерировать.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Что значит тру - как в suckless что-ли? > Конечно, подход к документированию как в doxygen и gtk-doc сильно неудобный, т.к. > там документация как правило дублирует имеющуюся инфу. > Например, описание функции польностью повторяет объявление функции. А в описании структуры > - вся структура. > Ещё это железъное правило - коммент перед кодом. Верно, но только иногда. > Комент может быть первым только если выполняет роль заголовка (для секции относительно > громоздкого кода). Если же это описание для документации, то оно идёт > после (либо в конце, либо на следующей в строке), лучший пример > - man страницы из руководств Linux, POSIX и libc. Такой исходник > должен быть поприятнее для чтения, при том, что сгенерировать удобные pdf > и html всё также не проблема. Просто генератор должен извлекать информацию > из самого исходника. Кстати, создавать pdf и html непрямую вообще не > нужно. Хватит поддержки markdown, asciidoc или retext - из них потом > (если очень хочется) можно что угодно сгенерировать.
	Введите код, изображенный на картинке: