LINUX.ORG.RU

В каком формате вы пишете документацию к своим проектам?

 


1

4

Интересуюсь потому, что сам подумываю начать писать полноценную. Вопрос задан не в контексте «какие варианты возможны», а в контексте «какие варианты реально используются».

Сам пока поглядываю в сторону markdown, т.к. в нём в нём есть подсветка и можно вставлять картинки. Иногда в этом есть необходимость, т.к. они нагляднее, чем псевдографика.

★★★

Последнее исправление: hobbit (всего исправлений: 1)

Интересуюсь потому, что сам подумываю начать писать полноценную.

Документация нужна пожалуй хотя бы к бете, а так предпочитаю в код добавлять (в некоторых случаях) комментарии в связи с чем была разработана функция и обычные текстовые файлы в которых объяснена программная архитектура проекта.

anonymous
()
Ответ на: комментарий от u-235

Генерирую из исходников doxygenом.

Никогда не использую так как AssistX поможет получить ответ на конкретный вопрос.
Да и в IDE и текстовых редакторах для программистов обычно бывает аналогичный функционал.
Конечно это моё субъективное мнение.

anonymous
()
Ответ на: комментарий от LongLiveUbuntu

//Я сам себе руководство.

Моё руководство считает, что пора начать искать варианты документировать проект. Ибо были уже случаи, когда возвращался к коду, который писался очень давно и уже не могу разобраться, как он работает. Поэтому на будущее планируется расписывать более-менее сложные алгоритмы человеческим языком. Хотя бы в общих чертах.

u5er ★★★
() автор топика
Ответ на: комментарий от u5er

Поэтому на будущее планируется расписывать более-менее сложные алгоритмы человеческим языком. Хотя бы в общих чертах.

Безусловно.
Иначе будет - «Не знал да ещё забыл».

anonymous
()
Ответ на: комментарий от u5er

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

Бывает, что программисты специально не добавляют комментарии, … (понятно почему они так делают).

anonymous
()

Markdown по работе, для себя иногда org-mode. Он по сути то же самое, но помощнее, плюс как айпайтон ноутбук работает, удобно иногда сгенерить конфиги и запустить деплой сразу из файла с докой.

masa ★★★
()
Ответ на: комментарий от Zhbert

открываешь свой же код через год и такой «Что за дебил это писал? Как оно работает?»?

Практически всегда.

Иногда ещё добавляется «Что за дебил писал документацию, которая противоречит коду?»

Toxo2 ★★★★★
()
Ответ на: комментарий от masa

Когда пытаешься разобраться как и что - да, но когда пытаешься использовать - нет.

Фишка в том, что всегда нужна как минимум обзорная документация, чтоб тот, кто планирует пользоваться кодом, знал, что в нём вообще есть и как делается то или это.

u5er ★★★
() автор топика
Ответ на: комментарий от Zhbert

Пробовал или Рабинович напел? В абсолютной массе от ИИ куда лучше документации програмистов выходит, у которых документация побочный необязательный продукт при создании основного.

One ★★★★★
()
Ответ на: комментарий от u5er

Да, это мем скорее, в сложном проекте определенно нужна дока, где что лежит и как работает на верхнем уровне. А вот комментарии сомнительная штука, меня больше всего забавляет, когда пишут в таком стиле:

# проверяем что x > 0
if (x > 0) { ... }

Особенно это LLM часто делает

masa ★★★
()

Использую HTML. Начал давно. Не переводить же теперь всё на markdown (чтобы что?), поэтому так в HTML и продолжаю. HTML это мейнстрим. markdown - лентяйская нишевая поделка. Вот когда браузеры начнут отображать markdown массово, тогда и подумаю. Можно вставлять .svg-картинки (или просто как фрагменты HTML). В таких картинках тоже можно делать участки гиперссылками.
Сегодня узнал про новую фичу, уверен, что markdown так не умеет, а фича полезная.

Saakx
()
Ответ на: комментарий от Saakx

Вот когда браузеры начнут отображать markdown массово

браузеры

Мне изначально не понравилась идея запускать браузер для просмотра документации. Поэтому я для себя выбрал Marker. В нём посмотреть можно и в нём же отредактировать.

u5er ★★★
() автор топика
Ответ на: комментарий от u5er

я для себя выбрал Marker

сложно его будет «продать» (убедить использовать) другим людям. А браузеры - легко.
Редактировать сторонние люди ничего не будут. Даже читать можно заставить с трудом, по себе знаю.

Единственная альтернатива - это .pdf (потому что в HTML нет страниц A4)

Saakx
()
Последнее исправление: Saakx (всего исправлений: 3)

в последнее время пробую на asciidoc - умеет в pdf, html статик через hugo, например лаконичная тема https://github.com/alex-shpak/hugo-book

не решенная проблема - как бы этим заставить пользоваться других технических писателей конторы, которые умеют только «docx», чтобы не делать копипасту правок

x905 ★★★★★
()
Ответ на: комментарий от x905

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

Никак, только сделать движок для сайта, по аналогии с википедией, но другой. И даже после этого заставить будет тяжело.

Saakx
()
Ответ на: комментарий от masa

Особенно это LLM часто делает

LLM это сделает не от балды, а при исправлении твоей ошибки в предыдущих итерациях. А дальше проблема человека что это ненужное тянет и дальше

One ★★★★★
()

Для текстов по типу readme — markdown/org-mode.

Для исходников — doxygen/qthelp, doxygen распространён, есть разные тулзы для конвертации, можно генерить оффлайн docset'ы для Zeal, у Zeal удобный поиск, но с генерацией docset'ов заморочки. Как альтернатива есть Qt Help, там всё из коробки, можно сразу доки сгенерить и просматривать в Qt Assistant, и есть встраиваемый виджет для просмотра.

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

Dr64h ★★★★
()
Ответ на: комментарий от u-235

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

firkax ★★★★★
()
Ответ на: комментарий от u-235

Документация должна объяснять в первую очередь идеологию работы твоего софта, без привязки к конкретным деталям кода. Справочник по коду - уже вторичен к этому. Если ты будешь это всё сувать в исходники, они станут замусоренными и неудобными с точки зрения кодинга. Точно так же, как сам код дробится на отдельные файлы разной специализации, надо и разделять документацию с кодом.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

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

К примеру взять исходники PostgreSQLи попробовать понять его архитектуру всего проекта и подсистем без документации можно?
Можно.
Если пол года своей жизни на это потратить.
Впрочем конечно и профит от этого будет.

Пошучу

Но проектов много.
Тогда о таковых можно сказть - «Перед смертью он прекрасно понимал архитектуру PostgreSQL».

Другим такого не желаю …

anonymous
()
Ответ на: комментарий от Zhbert

У меня вот не было. Разве что свой очень старый код, когда я пользовался С++-ными фичами типа перегрузок функций и объявления переменных в середине кода, теперь осуждаю. Но хоть читать его не совсем комфортно, вопросов «как оно работает» всё же не возникает.

firkax ★★★★★
()

Документация не нужна.

На работе заставляют писать в местной Вике (Конфлюенс, как правило). Для своих поделок есть manы.

urxvt ★★★★★
()
Ответ на: комментарий от cobold

Это да. Но так или иначе, документацию всё равно придётся обновлять руками, поэтому сначала хочу выбрать способ документации, а потом уже буду решать вопрос поддержания её в актуальном виде.

u5er ★★★
() автор топика

По работе markdown для репозитория (ибо сразу можно читать в браузере, с форматированием, ссылками и картинками) и wiki (confluence) с draw.io для всяких бизнес и архитектурных вещей. Sharepoint + excel / word / pdf для критической документации (аудит, комплаенс, disaster recovery и тд)

Для своих проектов как получится, но чаще всего несколько readme в маркдауне в репозитории.

skyman ★★★★
()

README.md почти стандарт. Но есть нюансы. Где как выглядит простой

# Hello world for README.md

> [!NOTE]
> Hello from README.md

> [!WARNING]
> Don't use `README`, `README.txt`

Use shell session

`ShellSession`:

```ShellSession
[user@host:work_dir]$ echo 'Hello World!!!'
Hello World!!!
dir ls && cp

[user@host:work_dir]$ dir ls && cp
```

```ShellSession
user@host:work_dir$ echo 'Hello World!!!'
Hello World!!!
dir ls && cp

user@host:work_dir$ dir ls && cp
```

`shell-session`:

```shell-session
[user@host:work_dir]$ echo 'Hello World!!!'
Hello World!!!
dir ls && cp

[user@host:work_dir]$ dir ls && cp
```

```shell-session
user@host:work_dir$ echo 'Hello World!!!'
Hello World!!!
dir ls && cp

user@host:work_dir$ dir ls && cp
```

`console`:

```console
[user@host:work_dir]$ echo 'Hello World!!!'
Hello World!!!
dir ls && cp

[user@host:work_dir]$ dir ls && cp
```

```console
user@host:work_dir$ echo 'Hello World!!!'
Hello World!!!
dir ls && cp

user@host:work_dir$ dir ls && cp
```

gitea, github, obsidian, …. и тупо нет пересечения для ShellSession/shell-session/console * в скобочках или без. Но под конкретный выбрать можно.

AlexVR ★★★★★
()
Ответ на: комментарий от skyman

По работе markdown для репозитория (ибо сразу можно читать в браузере, с форматированием, ссылками и картинками) и wiki (confluence) с draw.io для всяких бизнес и архитектурных вещей.

А почему например не в LibreOffice?
Те же возможности и много более …

anonymous
()