Страницы

Поиск по вопросам

Показаны сообщения с ярлыком документация. Показать все сообщения
Показаны сообщения с ярлыком документация. Показать все сообщения

суббота, 22 февраля 2020 г.

Исходный код в документации

#java #python #любой_язык #документация #javadoc


Можно ли в Javadoc указывать ссылку на исходный код классов и методов, чтобы не нужно
было каждый раз искать по каталогам нужный файл? Если да, то как это сделать? 

Вот пример для Python: документация SymPy содержит ссылки на исходники классов и методов.

Есть ли вообще какие-либо традиции для разных языков, каким способом публикуется
исходный код? Когда уместно прямо в документации выкладывать исходники, а когда достаточно
ссылки на Github?
    


Ответы

Ответ 1



У javadoc есть опция -linksource, которая включает исходный код в сгенерированную документацию. Например, в документации Guava есть ссылки на исходники в названиях классов и методов. Если код хранится в другом месте, можно использовать простую HTML ссылку .

воскресенье, 16 февраля 2020 г.

Исходный код в документации

#java #python #любой_язык #документация #javadoc


Можно ли в Javadoc указывать ссылку на исходный код классов и методов, чтобы не нужно
было каждый раз искать по каталогам нужный файл? Если да, то как это сделать? 

Вот пример для Python: документация SymPy содержит ссылки на исходники классов и методов.

Есть ли вообще какие-либо традиции для разных языков, каким способом публикуется
исходный код? Когда уместно прямо в документации выкладывать исходники, а когда достаточно
ссылки на Github?
    


Ответы

Ответ 1



У javadoc есть опция -linksource, которая включает исходный код в сгенерированную документацию. Например, в документации Guava есть ссылки на исходники в названиях классов и методов. Если код хранится в другом месте, можно использовать простую HTML ссылку .

четверг, 13 февраля 2020 г.

Форматирование текста в документации к Java методам/классам - отображение дженериков

#java #документация #javadoc


Дано:

Пытаюсь добаваить к описанию класса в конструкции

/**
*
*/


строку 

ArrayList

но отображается (как и тут, в цитате):


  ArrayList


Пробовал эти варианты:


Экранирование


ArrayList<\String>

получилось:


  ArrayList\String>



Больше экранирования:


ArrayList\<\String>

получилось:


  ArrayList\ \String>



Оборачивание тегом :


ArrayList

ничего не выходит:


  ArrayList

    


Ответы

Ответ 1



Старый метод: ArrayList<String>. Современный поход (начиная с JDK 1.5): использовать теги @literal или @code. при этом надо обернуть тег и его содержимое фигурными скобками При использовании первого тега содержимое внутри не будет рассматриваться как HTML разметка (например, удобно для описания математических выражений). Второй тег используется для обертки кода.

Ответ 2



/** * {@code ArrayList} bla-bla-bla */ ?

понедельник, 10 февраля 2020 г.

Правильно ли писать в README.md описания методов?

#java #github #документация


Есть README.md. Как лучше оформить описание методов? Мне кажется, что сейчас неправильно.


  VerticalHorizontalScrollView
  
  I did not find the ScrollView with two scrolls and decided to write it myself :D
I present VerticalHorizontalScrollView - ScrollView with both scroll directions and
little customization!
  
  scrollTo (int x, int y)
  
  Scroll container to X and Y axis without smooth animation
  
  smoothScrollTo (int x, int y)
  
  Scroll container to X and Y axis with smooth animation and default speed
  
  smoothScrollTo (int x, int y, int speed)
  
  Scroll container to X and Y axis with smooth animation and animation duration (ms)
  
  setOnScrollListener (OnScrollListener listener)
  
  Set listener for scroll action
  
  OnScrollListener.onScroll (int x, int y)
  
  Current X and Y axis scroll position

    


Ответы

Ответ 1



Описание методов Вы вообще не должны документировать методы и классы в readme. Для этой задачи существуют javadoc-комментарии в коде. Такие комментарии в том числе показываются в среде разработки, что гораздо удобнее, чем заглядывать в ридми. Даже дублировать комментарии из кода в ридми вручную не нужно, потому что вы создадите себе лишнюю работу и неизбежно будете обновлять эти комментарии с задержкой. Как ещё можно и нужно улучить эти комментарии: Опишите принимаемые параметры с помощью @param x ... Опишите возвращаемое значение с помощью @return ... Опишите предусловия метода, когда они важны: когда можно вызывать метод, когда нельзя, что необходимо сделать перед этим. Например, что будет, если вызвать smoothScroll в то время, как ещё не закончился другой smoothScroll? Опишите постусловия метода: что получится в результате. Пример: /** * Scroll container to X and Y axis without smooth animation * * @param x horizontal coordinate, [0..screen width] * @param y vertical coordinate, [0..screen height] */ public void scrollTo( final int x, final int y) { // code here } Создаём документацию из кода В Java есть стандартный инструмент — Javadoc. Он может создавать статические веб-страницы с документацией по коду Java. Эти страницы вы можете деплоить на GitHub Pages вручную или с помощью сервера непрерывной интеграции. Можете использовать облачный сервер Travis, он бесплатен для opensource-проектов. Что делать с Readme? Там должны быть совсем другие вещи: описание проекта, лицензия, инструкция по тому, как добавить библиотеку в свой проект. Подробнее: Как написать хороший README? Пара советов по code-style для markdown Ставьте пустую строку после заголовков Объединяйте тематические блоки под одним заголовком и внутри него используйте заголовки на уровень ниже: # Methods ## scrollTo ## smoothScrollTo # License Каждое предложение в абзаце начинайте с новой строки. Можно ещё больше дробить предложения, желательно так, чтобы длина строки была не больше сотни символов.

Ответ 2



Method name // description { codeblock } Мне кажется будет самое то, если ещё подключить HighlighterJS или ему подобные. Ещё вариант # Global Method ## Method1 //description { codeblock } ## Method2

суббота, 1 февраля 2020 г.

Список @идентификаторов , TODO или что это такое?

#java #cpp #документация #комментарии


Я видел что в некоторых исходных кодах JS например JQuery комментируют так:

// Define a local copy of jQuery


но это просто строка для людей а

// TODO:


это уже обнаруживается большинством IDE но JS не типизированный язык поэтому спрашиваю
про другие например я видел в некоторых исходных кодах на Java (в основном помоему)
или C++ (какой код здесь и придумал) в комментариях вставляют описания определяемых
ф-ции и т.д. примерно (взял с потолка потому что не знаю что это такое и Java) так:

/*
 @function getSquare
 @args:
 @x int 
 @returns int
*/
int getSquare(int);
...
int getSquare(x){
  return x*x;
}


Что это вообще такое за @... все поисковики уже измучал не нашёл мне кажется что
есть и @TODO просто в JS @ можно опускать. Или @ это что то типа директивы препроцессора
в Java (типа # в c++) или это надо применять в документации а не в исходном коде? 
Сильно не пинайте я уже спрашивал  Научиться писать документацию и хорошо комментировать
код только про JS и только @lampa сказал 


  У вас что, на калькуляторе поиск сломался?


а @Котик:


  Ахаха


но это было про JS а этот вопрос про C++ Java etc. Вопрос к профессионалам объясните
что за @... и т.д и какие можно в исходном коде и документации использовать ключевые слова
    


Ответы

Ответ 1



Говоря простым языком, это называется самодокументированием кода в стиле JavaDoc. Пример: class Test { /** * Разделить одно число на другое * * @param int x * @param int y * @return int */ public int divide(int x, int y) { return x/y; } } Где все, что начинается с "собачки" - называется тегами описания. Из примера: Эти теги, они стандарты. Не нужно придумывать своих. Самые основные: Тег @param int x - означает какой параметер будет передам в функцию Тег @return - означает какое возращаемое значение мы ожидаем Тег @author - означает кто автор Тег @copyright - Авторские права Тег @license - Лицензия Тег @version - Версия итд их много, если нужны все в гугл: JavaDoc Style JavaDoc Style используется не только в Java, но также и в C#/C/C++ и PHP для само-документирования классов и методов. Некоторые используют даже в JavaScript. Это нужно для того чтобы, облегчить чтение/понимание кода. Это общепринятый стандарт/правило для документирования своего кода.

Ответ 2



Ну вот же, документирование кода Java. У Вас действительно поиск сломался?

Ответ 3



Почитайте про полузабытый API Java Taglet

пятница, 10 января 2020 г.

Посоветуйте сервис генерации документации для Python

#python #документация


Мне понадобилось написать документацию для API, написанного на базе Python (cherrypy).
Хотелось бы максимально автоматизировать процесс, например добавить комментарий с
тэгом к функции, чтобы сервис сам собрал все функции и их параметры из файла в справочный
html файл.
Есть ли такой сервис?
Очень не хочется заниматься тупым копированием.
    


Ответы

Ответ 1



Широкоиспользуемой библиотекой для генерации документации является Sphinx—как CPython так и многие Питон библиотеки её используют. Sphinx autodoc расширение может генерировать документацию из docstrings. Могут быть использованы различные форматы, к примеру numpydoc позволяет autodoc распознавать специфичный для numpy формат документации, используемой в docstrings. Для быстрого просмотра документации, сохранённой в docstring, можно использовать pydoc модуль/команду из стандартной библиотеки. Встроенная help() использует pydoc для генерации текстовой документации для просмотра в консоли. Примеры других инструментов по генерации документации для проектов написанных на Питоне, можно в вики посмотреть.

Ответ 2



Один из самых распространенных инструментов для автогенерирования API документации называется swagger. При желании вместе с функциональностью "сделай мне документ по описанию API" можно использовать целую экосистему open-source инструментов, так или иначе облегчающих работу с вашим API. Не знаю насколько он популярен среди питонистов, но с питоном работать тоже умеет.

Ответ 3



Я использовал apidoc достаточно просто, быстро. Вот страничка

четверг, 9 января 2020 г.

Документация проектов C# на нескольких языках в VisualStudio

#c_sharp #visual_studio #документация


Необходимо задокументировать весь код в проекте, чтобы при использовании метода,
студия подсказывала о нём всё, что только можно. Единственное, что я смог найти для
своей ситуации - это XML документация, для .csproj. Но, насколько я понял, это получается
не слишком красиво и очень громоздко в исходниках, тем более, если делать через xml:lang="LANG_ID".

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



UPDATE #1

Сейчас мне пришла в голову очень странная идея, для моей задачи, мне нужна просто
документация для какой-то DLL на разных языках и всё. Думаю написать какое-нибудь ПО,
которое будет подниматься на prebuild событии и выставлять везде где нужно документацию,
чтобы студия собрала XML файл. А на postbuild событии будет подниматься ПО, которое
будет очищать все выставленные строчки. Этот подход позволить сделать код чистым от
доки и полностью автоматизировать процесс (только саму доку придется править).
    


Ответы

Ответ 1



Не хочу расстроить, но XML-комментарии, это то единственное, что позволит вам достичь желаемого результата. А для того чтобы процесс их написания не был таким "болезненным" и скучным, от себя могу порекомендовать расширение для Visual Studio под названием GhostDoc, которое позволяет автоматизировать и стандартизировать некоторые рутинные действия и операции.

понедельник, 6 января 2020 г.

Документация (summary) во внешнем файле

#c_sharp #xml #visual_studio #документация #intellisense


Имеется библиотека. В ней методы, поля (свойства), которые хорошо бы описать, чтобы
при использовании Visual Studio высвечивала описание и подсказки для того или иного
поля/метода. 

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

Но если я сейчас прямо в коде начну писать описание, то код заметно удлинится. Можно
ли как-то в отдельном файле написать эту документацию? 

Чтобы в коде не было , но IntelliSense смог отображать эту информацию? 
    


Ответы

Ответ 1



Да, это возможно. Используйте тег include. Теперь достаточно Аннотировать нужный метод так: /// public void MethodName(string arg) { } Создать файл external_summary.xml, имеющий такую структуру: Описание метода Описание параметра arg В результате после компиляции сборки с опцией /doc вы получите следующую xml-документацию: Application Описание метода Описание параметра arg

суббота, 4 января 2020 г.

Как написать хороший README?

#документация


Я думаю, каждый видел README-файлы. Хотелось бы получить подробное руководство о
том, как написать исключительный README и при этом потратить как можно меньше сил.


Что такое "файл README"?
Что мне написать в нем?
Каким образом я должен отформатировать его?

    


Ответы

Ответ 1



README должен быть простым и коротким. Хороший README поможет сэкономить время, особенно, если это README для чего-то вроде библиотеки, разбирающей параметры командной строки. Вот что он должен включать в себя: имена проектов, всех подмодулей и библиотек (иногда они называются по-разному и путают новых пользователей) описание каждого проекта, всех подмодулей и библиотек 5-строчный сниппет (фрагмент кода) с примером использования (если это библиотека) копирайт и информация о лицензии (или ссылка на лицензию) инструкция, как найти документацию инструкции по установке, настройке и запуску инструкция по получению свежих исходников и подробная инструкция по сборке (или быстрый обзор и ссылка на инструкцию по установке) список разработчиков или ссылка на файл с описанием авторов инструкции по отправке сообщений об ошибках, пожеланий и запросов на изменения, патчей, а также о том как получать анонсы, присоединиться к списку рассылки или к сообществу разработчиков в других формах контактная информация (адрес электронной почты, сайт, название компании, адрес и т.д.) краткая история изменений, если это обновление или форк другого проекта юридическая информация (для криптографического ПО) У HTTP-сервера Apache простой, но хороший README. Другой хороший пример - README для GNU make, доступный онлайн. О форматировании: придерживаться традиций Unix насколько это возможно, и/или использовать markdown, особенно для проектов на Github, который рендерит README.md в html-файл. Только ASCII-символы, если README написан на английском языке пишите его на английском языке, если это возможно, и добавляйте файл с переведенной версией. Добавляйте к такому файлу расширение из двух букв, соответствующее языку, например README.RU не более 80 символов в строке одна пустая строка между абзацами подчеркивайте строку заголовка символами "минус" для отступов используйте пробел (0x20), а не табуляцию Соберём все вместе... Документация ------------- GNU make полностью документирован в справочнике по GNU make, который содержится в этом дистрибутиве как файл make.texinfo. Вы также можете найти он-лайн, PostScript и DVI версии на сайте FSF. Там же приведена информация о заказе документации в печатном виде. http://www.gnu.org/ http://www.gnu.org/doc/doc.html http://www.gnu.org/manual/manual.html Википедия определяет README так: Файл README (или READ ME), содержит информацию о файлах в папке или архиве и обычно распространяется с ПО. Википедия перечисляет части README: инструкции по настройке инструкции по установке инструкции по эксплуатации файл манифеста информация об авторских правах и лицензировании контактная информация для дистрибьютора или разработчиков известные ошибки устранение неполадок сведения об авторах и благодарности список изменений

четверг, 2 января 2020 г.

Как сделать документацию к функции?

#python #python_3x #python_2x #документация



Как сделать документацию к функции?
Как автоматически сохранить документацию в файл?
Также как получить документацию из какой-либо
функции?

    


Ответы

Ответ 1



Документировать функции очень важно. Это помогает не только узнать что делает функция, но и подсказывает какие именованые аргументы она принимает и что в следствии может возвращать. Документировать функции очень просто. Просто и обращаться к документации каждой функции. Чтобы создать описание функции, внутри функции перед её телом нужно сделать многострочный комментарий(делается он с помощью трёх знаков '''). Этот комментарий будет рассматриваться, как аттрибут .__doc__ и будет появляться при вызове help(), но об этом чуть позже. Давайте сделаем небольшую функцию: def to_str_smth(smth, step=1): smth = str(smth) return smth[::step] Функция есть, давайте сделаем к ней описание для тех, кто будет, например, импортировать модуль с ней. def to_str_smth(smth, step=1): """ to_str_smth(smth, step=1) Makes the input data string and return it sliced with step """ smth = str(smth) return smth[::step] Теперь вызовем нашу документацию: print(to_str_smth.__doc__) Документацию можно вызвать и с помощью команды help(), но тогда свернётся весь наш аутпут и откроется что-то типа подокна (если вы знакомы с редактором nano, то вам будет проще понять), из которого можно выйти, нажав q help(to_str_smth) Почему не вызывем документацию у to_str_smth(), указывая скобки? Потому что так функция затребует аргументы, если они обязательны. К тому же, таким образом мы можем вернуть документацию подфункции, если она указана в return. Посмотрим, например, на эту функцию: def plus(a, b): """ plus(a, b) Return a + b, typed float """ return float(a + b) Давайте попробуем вывести на экран документацию для неё, указав скобки: print(plus().__doc__) Как мы видим, функция запросила аргументы. Теперь давайте попробуем их передать и снова вызывать документацию: print(plus(2.3, 2.7).__doc__) Не совсем то, что хотелось бы видеть... Важно соблюдать одинаковое форматирование при написании документации, как и при написании кода. Ознакомиться с рекомендациями по тому, как стоит документировать функции и классы, можно в справке PEP257. Кстати, всё, что заключённо между парой ''' игнорируется интерпретатором и таким образом можно спрятать блоки кода при его тестах. Если мы хотим сохранить документацию, сделать это можно с помощью программы, которая идёт в комплекте с Python под названием pydoc. Для каждой версии есть свой pydoc, так что убедитесь, что вы запускаете ту версию pydoc'а, иначе может возникнуть конфликт импорта модулей. Сделать это можно следующим образом (подразумевается, что запуск идёт из директории с модулем): pydoc3.6 -w ./mymodule # также подойдёт pydoc -w ./mymodule.py Таким образом будет создан html файл с вашей документацией для модуля mymodule. Дизайн не очень, зато быстро. Для стартапов пойдёт. К тому же, помимо pydoc есть множество программ, которые генерируют документацию в файл. Вот некоторые из них: HappyDoc pudge epydoc Обращаясь к документации с помощью help() или .__doc__, мы можем разрешить множество вопросов, связанных с импортируемыми модулями, а документируя свой код - не забыть что он делает, возвращает и для чего он нужен спустя долгое время.

пятница, 27 декабря 2019 г.

Существует ли общепринятый способ описать в документации сигнатуру фукции/метода?

#java #c_sharp #cpp #bash #документация


Допустим есть некая функция, которая сама разбирает список аргументов

foo(...){

}


Сначала она ожидает агрумент bar, потом неограниченное число пар baz quux

foo(bar baz1 quux1 baz2 quux2 baz3 quux3)


Есть ли общепринятый способ описать аргументы функции? Что-то на подобие uml, но
в виде текста. Например такое:

# Function foo
# foo( [ ]...)
foo(...){

}

    


Ответы

Ответ 1



Вот ссылки на документацию по оформлению кода. Конвенция для java Раздел 5.2 Стандарты С++, PDF и ISO 17 C# и XML-стандарт

понедельник, 23 декабря 2019 г.

Книга по веб-стандартам? [закрыт]

#веб_программирование #книги #ui #документация


        
             
                
                    
                        
                            Закрыт. Данный вопрос необходимо конкретизировать. Ответы
на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы он был сосредоточен только на одной проблеме, отредактировав его.
                        
                        Закрыт 1 год назад.
                                                                                
           
                
        
Подскажите, пожалуйста, хочу прочитать или книгу или документацию по веб-стандартам,
чтобы я мог аргументировать почему в форме справа кнопка сохранить, а слева отменить(это
например) и тд. 
Что посоветуете?
    


Ответы

Ответ 1



То, что вам нужно, называется User Interface Guidelines. Однако для web-а нет никаких документально зафиксированных рекомендаций, поэтому можете поискать подобные документы для широко используемых настольных операционных систем, опыт взаимодействия с которыми является стандартом де-факто: User Experience Guidelines для Windows, Human Interface Guidelines для OS X.

суббота, 21 декабря 2019 г.

От какого лица и в какой форме писать комментарии в документации на английском?

#документация #комментарии


Допустим, я пишу комментарий к функции для документации. Мне нужно описать что она
делает. Форматирование пока опустим. Предположим, это функция загрузки файла с сервера.
По-русски я напишу что-то вроде этих вариантов:

/*
 * Функция загрузки файла
 *  или
 * Загрузка файла
 */


Я слабо владею английским. В русском языке принято описывать алгоритм от третьего
лица, но на английском часто встречал описание от второго лица. Как правильно написать
такую функцию на английском? Нужно ли подразумевать 'it' и писать от третьего лица?
Или вовсе писать в неопределенной форме? Сейчас я пишу так:

/*
 * Loads a file
 */

    


Ответы

Ответ 1



Ваш вариант вполне хорош, он описывает что делает функция, как будто мы объясняем её кому-то используя только комментарии: /* Loads a file */ /* Processes the queue */ /* Opens a remote resource */ Второй вариант, который я встречал, это описание того, что мы хотим сделать этой функцией: /* Load a file */ /* Process the queue */ /* Open a remote resource */ Эти два варианта самые частовстречающиеся, используйте любой, который предпочитаете лично.

Ответ 2



Используйте Simplified Technical English (STE) Пишите коммент как commit message в Git: Update default policies... Add support for configuring... Add shared_storage_test methods... Add CPU arch filter... Следуйте модели "50/72": Первая строка: длина первой строки - не более 50 символов Вторая строка: пустая Третья и следующие: длина ограничена 72 символами

среда, 18 декабря 2019 г.

Как писать комментарии к параметрам метода?

#c_sharp #документация #комментарии


В каком виде следует писать комментарии к параметрам метода, чтобы при вызове метода
в его подсказке были эти комментарии?
    


Ответы

Ответ 1



Есть такая штука - xml-комментарии. Они отличаются от обычных тем, что предваряются тремя слэшами, а не двумя. Например: /// /// Описание метода /// /// Описание параметра /// Ogbcfybt возвращаемого значения public int SomeMethod(string arg)

Ответ 2



Ставите /// слеша перед именем члена, далее студия сгенерирует вам заглушку для комментариев. Заполнить ее можно как в примере. /// /// Некоторый метод. /// /// Количество /// public void Method(int count) { }

Научиться писать документацию и хорошо комментировать код [закрыт]

#документация #javascript #opensource #комментарии


        
             
                
                    
                        
                            Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Update the question so it
can be answered with facts and citations by editing this post.
                        
                        Закрыт 1 год назад.
                                                                                
           
                
        
Хочу создать свой проект на JavaScript (уже в работе), затем хочу создать для него
(хоть и бесплатный) сайт где можно будет им поинтересоваться скачать и т.д. Может размещу
на code.google (уже занял место). Суть: Мне рано или поздно придётся написать документацию
(объекты,методы входящие в состав). И мой код должен быть доступен для скачивания (opensource)
и соответственно красив. Где можно найти статьи (или стандарты) для написания документации
и статьи про хорошее комментирование кода.    


Ответы

Ответ 1



Документирование кода не может быть "хорошим" - оно может быть правильным и соответствующим стандартам. Например один из них и всесторонне поддерживаемый - JSDoc По поводу "контроля качества кода" - тут немного сложнее. Дело в том что для разных спецификаций и диалектов языка - разные стандарты. И то что мы сейчас понимаем под JavaScript - это не сам язык, а различные скриптоязыки и диалекты из спецификации ECMAScript и другое - например JSX итд. Поэтому выбор "стандарта" - зависит от конкретного проекта. Использовать для контроля можно 'lint' или 'eslint' - пакеты в npm. А какие плагины и какие настройки к нему использовать - зависит от используемой спецификации языка, платформы и фреймфорков.

воскресенье, 15 декабря 2019 г.

В чем вести / генерировать тех. документацию API растущего проекта?

#документация #api #проектирование


Пишем немаленький проект. Растет число разработчиков, ролей, серверов, протоколов.
Хочется иметь четкую, хорошо форматированную документацию, как, например, у Google : )
В чём, и как её лучше вести и генерировать html?     


Ответы

Ответ 1



Зависит от того, что именно вы хотите. Если вопрос об удобном формате для написания документации, то попробуйте AsciiDoc/AsciiDoctor. Это plain-text формат, напоминающий Markdown и вики-разметку. Он позволяет отделить текст документации от шаблона оформления (приятные шаблоны "из коробки") и умеет собираться и в HTML, и в PDF, и в DocBook, и по всякому. Активно развивается инфраструктура вокруг него. Его удобно хранить в контроле версий (это plain-text формат, который легко диффать и мержить) и работать с ним как с исходным кодом документации. Если вопрос о готовой системе хранения документации и совместной работы - посмотрите Atlassian Confluence: довольно приятная штука, много плагинов, интегрируется как с инфраструктурой Atlassian (багтерекер JIRA, билдсервер Bamboo, и т.п.) так и с популярными тулами вроде Balsamiq Mockups. Еще доводилось пользоваться для этой цели MediaWiki, но у нее, как мне кажется, порог вхождения выше. Если речь об автоматизации документирования всяких REST API, то я не так давно в ходе поисков нашел отличную вещь - Swagger. Этот проект представляет собой попытку стандартизировать описание REST службы в виде набора xml/json-документов, на основе которых можно сгенерить как "живую" online (с возможностью подергать сервисы прямо со страницы) так и обычную offline-документацию, и заглушки для клиентской части под разные языки.

Ответ 2



Пишу документацию/справочник по разрабатываемой системе. Тоже озадачился, на чем это делать. Нашел интересную вещь Outwiker http://jenyay.net/Soft/Outwiker

суббота, 14 декабря 2019 г.

Поиск по командам в linux

#linux #документация


В играх на source есть очень удобная команда find, которая позволяет искать по всем
командам и их описанию. И тут я подумал, а нет ли чего-нибудь подобного под linux?
    


Ответы

Ответ 1



help для внутренних команд оболочки (cd, echo, exit и т.д. и т.п.) есть внутренняя команда оболочки help: $ help command если после набора help поставить пробел и нажать два раза tab, то отобразится список внутренних команд оболочки, для которых можно получить справку. начать лучше с: $ help help man многие программы/команды/функции имеют т.н. man-страницу с детальным описанием аргументов/опций/клавиатурных сокращений для запуска/использования. просмотреть их можно с помощью программы man: $ man zip если после набора man поставить пробел и нажать два раза tab, то отобразится список man-страниц, которые можно почитать. начать лучше с: $ man man apropos программа apropos позволяет искать по заголовкам и кратким описаниям man-страниц ключевые слова. например: $ apropos reboot info программы, разрабатываемые в рамках проекта gnu, обычно имеют документацию в формате texinfo, к которой можно обратиться с помощью программы info: $ info gcc если после набора info поставить пробел и нажать два раза tab, то отобразится список доступных руководств. начать лучше с: $ info info info -k с помощью опции -k ключевые слова можно искать документацию, содержащую любое из перечисленных ключевых слов. а если заключить строку в кавычки, будет производиться поиск именно этой строки: $ info -k "regular expressions" ... "(sed)Invoking sed" -- Extended regular expressions, choosing ... затем можно просмотреть найденный документ: $ info "(sed)Invoking sed" опция -h многие программы имеют «встроенную» справку, выдаваемую при вызове этой программы с опцией -h (--help): $ firefox -h

вторник, 10 декабря 2019 г.

Описать не только методы, но и свойства объектов в gitbook

#объекты #документация


Пишу документацию по lua модулю. В нём фигурирует объект, у которого кроме методов
есть ещё и свойства. В свою очередь, плагин theme-api для gitbook позволяет описать
только методы. Как, в таком случае, описать свойства объекта в gitbook?
    


Ответы

Ответ 1



У него нет такого так как он сделан для описания веб-сервисов. Посмотрите исходники, они небольшие - там нигде нет упоминания о переменных класса.

суббота, 7 декабря 2019 г.

XML документация кода с generics

#c_sharp #документация


Есть проект на c# с подробной документацией в xml, вот пример документации:

    /// ... - много-много текста
    /// 
    /// Классический пример использования:
    /// 
    ///     
    ///     public delegate void MyDelegateMethod(int value);
    ///     ...
    ///     
    ///     Type type = assembly.GetType("Data.Test");
    ///     MyDelegateMethod fooMethod = type.GetMethod("Foo");
    ///     fooMethod.Invoke(42);
    ///     
    /// 
    /// 
    public static T GetMethod(this Type type, string name) where T : class {
        return GetMethod(type,name,true);
    }


Далее, есть VisualStudio нескольких версий - 2012 и 2015. Так вот, с точки зрения
XML данные доки ошибочны, так как генерик-метод:

type.GetMethod("Foo");


интерпретируется как открытие тега MyDelegateMethod, который, не закрывается.

Скрин из MS Visual Studio 2012, при попытке прочитать документацию всплывающим контекстом:


С точки зрения документации - всё чисто (код написан в ограничивающих тегах 
).

В поисках истины, прочитал я рекомендации с англоязычных ресурсов:


Замена символов '<' и '>' на < и >
Замена символов '<' и '>' внутри генерик на '{' и '}'


Но, всё это сделает код внутри тегов  не рабочим. (Что это значит - найдётся
горе-программист, который скопирует код из этой документации и искренне удивится что
без редактирования этот код не работает ни под одним из существующих шарпов) Кроме
того, код вида:

MyDelegateMethod fooMethod = type.GetMethod("Foo");


воспринимается сразу, и без серьёзных рассуждений, в свою очередь, код такого вида:

MyDelegateMethod fooMethod = type.GetMethod<MyDelegateMethod>("Foo");


сходу сложно определить.

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


Ответы

Ответ 1



Для тегов наподобие вам нужно использовать {}-синтаксис, он не зависит от языка (C#/VB/...) и распознаётся парсером документации. /// /// Uses class /// Для примеров кода лучше всего, вероятно, использовать блок CDATA: /// /// /// (new Range().Go()); /// ]]> /// ///

четверг, 5 декабря 2019 г.

Как описать документацию для PowerShell командлета на C#?

#c_sharp #powershell #документация


Не понимаю, откуда берёт документацию Get-Help, и как написать её для своих командлетов.
    


Ответы

Ответ 1



Для бинарных командлетов запрограммированных на C# Команда Get-Help ищет файл %moduleName%.dll-Help.xml в папке с самой скомпилированной сборкой модуля, содержащий документацию. Есть не очень внятный набор гайдов на msdn, написан коряво и не объясняет как и что. Есть пошаговый тутор с примерами, из которого уже понятно как это делать.