C # In-Source Генерация документации для непрограммистов - PullRequest
1 голос
/ 16 июля 2009

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

Более новая проблема, которую мы начали обнаруживать, заключалась в том, что результатом выполнения этого через doxygen является очень хорошее представление кодовой базы, но для программиста, для которого мы намеревались сделать эту документацию доступной для чтения нашими системными инженерами, которые будут часто приходят к нам с вопросом, что именно делает задание.

Существует ли простой способ документировать наш код, используя метод /// и doxygen таким образом, что, если мы его запустим определенным образом, мы можем сгенерировать документ, который JUST содержит версию документации по системному проектированию без каких-либо дополнительных поток стандартной документации для программистов, которая отпугнет системного парня, такого как методы, переменные-члены и т. д.? Любые альтернативные решения также приветствуются.

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

Ответы [ 3 ]

1 голос
/ 16 июля 2009

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

1 голос
/ 16 июля 2009

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

Что удивительно и немного пугающе в вашем вопросе, так это то, что инженеры-программисты создают систему, которую придется использовать системным инженерам, и что инженеры-программисты создают функциональность из ничего. Вы должны быть предельно осторожны, чтобы функциональность определялась вашими программистами; они должны реализовывать указанную функциональность (и эта спецификация должна соответствовать используемой системными инженерами).

0 голосов
/ 02 сентября 2009

Одна вещь, которую вы можете сделать, это использовать команду doxygen \page, которая дает вам «Связанные страницы». Создайте текстовый файл с расширением, которое обрабатывается doxygen, и просто добавьте туда комментарий. (Я использую .doc, но вы можете изменить это значение на другое, чтобы избежать путаницы с документами Word. Я также помещаю эти файлы в общий каталог docsrc, чтобы они были в одном месте.) Затем эти страницы отображаются в отдельном разделе в документации.

/*!      
\page foobar Foobar calculation

I am using the procedure outlined in the bla bla note to estimate
the foobar in our baz. Lorem ipsum dolor...

\section step1 1. Estimation of the foobar-efficiency of the baz system.

\author jdm
*/

Затем можно создать ссылки на страницу или разделы с помощью \ref foobar или \ref step1.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...