私はいくつかのテストを行いましたが、良いニュースと悪いニュースがあります:)。@borrows
良いニュースは、Singleton doc コメントにタグを入れることでこれを機能させることができるように見えることです:
/**
* This is the singleton.
*
* @namespace Something.Singleton
* @borrows Something.Singleton-_foo as foo
*/
Something.Singleton = (function() {
// etc
})());
しかし、これにはいくつかの影響があり、良い面と悪い面があります。
foo
機能は とマークされていますstatic
。私はあなたのコードを理解しているので、これはおそらく良いことです。
- 現在表示されているコード (つまり、シングルトンのメソッドがないなど) を使用すると
@lends
、わかりやすくするためにタグを含めたくない場合を除き、タグを完全に省略することができます。すべてのメソッドが@borrows
最上位のシングルトン名前空間にリストされている場合、返されたオブジェクトでそれらをさらに文書化する必要はありません。繰り返しますが、これはおそらく良いことです。
- 悪いニュースは、借用したメソッドが明示的にマークされていない限り、これを機能させることができなかったことです
@public
。これにより、ドキュメントに重複して表示されます。これはやむを得ないと思います.jsdoc-toolkitがメソッドを非公開と判断した場合、ドキュメントが作成されないため、参照できません(私はWARNING: Can't borrow undocumented Something.Singleton-_foo.
. メソッドが公開されている場合は、ドキュメントに表示されます。
したがって、これは機能します:
/**
* This is the singleton.
*
* @namespace Something.Singleton
* @borrows Something.Singleton-_foo as foo
*/
Something.Singleton = (function() {
/**
* @public
* Foo method.
*
* @return {String} this method always returns with <code>bar</code>
*/
function _foo() { return "bar"; }
return {
foo: _foo
};
}());
_foo
... のドキュメントをにコピーしますが、ドキュメント ページにもfoo
表示されます。_foo
Method Summary
<inner> _foo()
<static> Something.Singleton.foo()
おそらく最善の回避策は、doc コメントのように@borrows
完全かつ明示的に名前_foo
を付けるのを忘れて、それをパブリック関数としてマークすることです (内部関数にアンダースコアを付けなかった場合は省くことができますが、これは jsdoc-toolkit に処理するように指示します)別段の指示がない限り、非公開として):Something.Singleton.foo
@public
/**
* This is the singleton.
*
* @namespace Something.Singleton
*/
Something.Singleton = (function() {
/**
* @name Something.Singleton#foo
* @public
* @function
* Foo method.
*
* @return {String} this method always returns with <code>bar</code>
*/
function _foo() { return "bar"; }
return {
foo: _foo
};
}());
これにより、探しているコード ドキュメントが作成され、関連する実際のコードの横にコメントが表示されます。コンピューターにすべての作業を行わせるというニーズを完全に満たすことはできません-コメントで非常に明確にする必要があります-しかし、それはあなたが最初に持っていたものよりも、そうではないにしても、同じくらい明確だと思います.はるかにメンテナンスが必要だとは思いません (元の例でも、名前を変更した場合はすべてのドキュメント コメントを変更する必要がありますSomething.Singleton
)。