Создание документации для [закрытых] классов Python
Вы можете просто добавить новую переменную для учета состояния «завершена загрузка».
Вот решение: добавьте finishedLoading: boolean = true; к вашему классу. Тогда:
checkRouterEvent(routerEvent: Event): void {
if (routerEvent instanceof NavigationStart) {
this.finishedLoading = false;
this.loading = false;
setTimeout(() => {
if (!this.finishedLoading) {
this.loading = true;
}
} , 300);
}
if (routerEvent instanceof NavigationEnd ||
routerEvent instanceof NavigationCancel ||
routerEvent instanceof NavigationError) {
this.finishedLoading = true;
this.loading = false;
}
}
5 ответов
Я использовал epydoc для генерации документации для модулей Python от встроенных docstrings. Это довольно просто в использовании и генерирует симпатичный вывод в нескольких форматах.
python.org теперь использует сфинкса, поскольку это - документация.
Мне лично нравится вывод сфинкса по epydoc. Я также чувствую, что реструктурированный текст легче прочитать в docstrings, чем epydoc разметка.
Сфинкс может быть полезен для генерации очень подробных и информативных документов, которые выходят за пределы того, что простые документы API дают Вам. Однако во многих случаях Вы будете лучше обслуживаться для использования Wiki для подобных документов. Также рассмотрите функциональные испытания записи, которые демонстрируют использование Вашего кода вместо того, чтобы документировать в словах, как использовать Ваш код.
Epydoc очень хорош в сканировании Ваших docstrings и рассмотрении Вашего кода для генерации документов API, но не обязательно хорош в предоставлении намного большей всесторонней информации.
Существует достоинство к наличию обоих типов документации для проекта. Однако при входе уплотнение времени, всегда более выгодно иметь хорошее тестовое покрытие и значимые тесты, чем документация.
См. ответы на can-i-document-python-code-with-doxygen-and-does-it-make-sense, особенно те, которые упоминают Epydoc и pydoctor.
Я использую Sphinx для своего проекта не только потому, что он хорошо выглядит, но и потому, что Sphinx поощряет писать документацию для чтения людьми , а не только компьютерами ].
Мне очень грустно читать документацию в стиле JavaDoc, созданную такими инструментами, как epydoc. Слишком часто программист бездумно «документирует» аргументы и возвращаемые типы просто потому, что в противном случае в документации API был бы пробел. Таким образом, вы получаете строку кода this (которая должна выглядеть как Java, но с тех пор, как я написал Java, прошло некоторое время, поэтому она может не компилироваться ...)
/**
* Set the name.
*
* @param firstName the first name.
* @param lastName the last name.
*/
public void setName(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
В ней очень мало информации, поэтому -называется "документация".