GhostDoc, эквивалентный для Eclipse (Java)
Я действительно не вижу потребность, поскольку модуль с функциями (и не класс) служил бы хорошо в качестве одиночного элемента. Все его переменные были бы связаны с модулем, который нельзя было инстанцировать неоднократно так или иначе.
, Если Вы действительно хотите использовать класс, нет никакого способа создать частные классы или частных конструкторов в Python, таким образом, Вы не можете защитить от нескольких инстанцирований, кроме только с помощью соглашения, используемого из Вашего API. Я все еще просто поместил бы методы в модуль и рассмотрел бы модуль как одиночный элемент.
3 ответа
It is basically the equivalent of Javadoc, which can be generating in eclipse with the shortcut:
ALT+Shift+J
(when you are within the Java function you wish to add javadoc for)
From there, if you really want XML format, you can try and use a JELDoclet
Никогда не использовал GhostDoc, поэтому не уверен, какие дополнительные функции он дает, но если речь идет о генерации комментариев к типам и методам на основе имени, параметров, типа возвращаемого значения и т. Д., Тогда в eclipse он встроен, поэтому никаких расширений не требуется.
GhostDoc имеет приятную дополнительную функцию, которая выводит описание того, что делает метод, путем анализа имени метода и предоставления его в виде скелетной документации. Например, использование GhostDoc для метода с именем GetDocumentName () может вернуть фразу «Получает имя документа». Хотя это едва ли больше информации, чем указано в названии метода, он добавляет документацию по методу там, где ее раньше не было. Некоторые могут возразить, что это бесполезно. Я утверждаю обратное, потому что он поддерживает создание документации из исходного кода (например, для таких инструментов, как NDoc или SandCastle).
На мой взгляд, наибольшее преимущество GhostDoc перед «Генерировать комментарий элемента» в eclipse заключается в том, что он побуждает программистов начать добавление комментариев к документации путем добавления чрезвычайно быстрого и надежного способа создания этого. Программист может принять предполагаемый текст (подходит в 50-80% случаев) или расширить его для более сложных методов. Для младшего программиста, который не так хорошо знаком с тем, как используются комментарии к документации, это может быстро сократить кривую обучения и поощрить хорошие практики программирования.