blocks|key|46779|text|我认为最完整的功能是google+closure+compiler使用的功能|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|46780|使用google+closure编译器最酷的一件事是，它将对标记了类型信息的函数进行类型检查。|46781|我能感受到你的痛苦，我整天都在处理这件事。这是一个非标准特性的示例，我必须对其进行编码/文档处理。Ext-JS使用@cfg来记录您传递给小部件的初始化对象的属性。我使用的集成开发环境IntelliJ使用JSDoc提供更好的代码建议，它甚至可以理解Ext的方言。在大多数情况下，它工作得很好。然而，很多时候我不得不以某种方式复制文档，以使我的IDE和doc工具(Ext版本的jsdoc)都能理解它，这并不是很枯燥。这里有一个例子：|style|CODE|46782|...
/**+
+*+@cfg+{string}+title+//+Ext-JS+grabs+the+type+from+this+line
+*+@type+string+//+My+IDE+grabs+the+type+from+this+line
+*/
+title:+null+//+My+IDE+requires+this+line+to+recognize+the+cfg
+++++++++++++//+as+a+property+of+the+object+even+though+all+cfgs
+++++++++++++//+are+available+in+the+object
...|code-block|syntax|javascript|46783|entityMap|0|LINK|mutability|MUTABLE|url|https://developers.google.com/closure/compiler/docs/js-for-compiler|1|http://docs.sencha.com/ext-js/4-1/#!/api/Ext.grid.Panel^0|A|N|0|0|0|1L|4|1D|6|1|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|13|8|@$A|14|B|15|H|I]]|9|@$A|16|B|17|1|18]]|C|$]]|$1|J|3|K|5|L|7|19|8|@]|9|@]|C|$M|N]]|$1|O|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]]|P|$Q|$5|R|S|T|C|$U|V]]|W|$5|R|S|T|C|$U|X]]]]

The one I think is the most feature complete is the one used by <a href="https://developers.google.com/closure/compiler/docs/js-for-compiler" rel="nofollow">google closure compiler</a> 

One of the cool things about using google closure compiler is that it will do type checking on your functions that have been marked with type information.

I feel your pain, I deal with this all day long. Here's an example of a non-standard feature that I have to code/doc around. <a href="http://docs.sencha.com/ext-js/4-1/#!/api/Ext.grid.Panel" rel="nofollow">Ext-JS</a> uses <code>@cfg</code> to document the properties for the initialization object you pass into a widget. The IDE I use, IntelliJ, uses JSDoc to provide better code suggestions and it even understands Ext's dialect. For most things, it works well. However, many times I have to duplicate the documentation somehow to make both my IDE and the doc tool (Ext's version of jsdoc) understand it, not very DRY. Here's one example: 

<pre><code>...
/** 
 * @cfg {string} title // Ext-JS grabs the type from this line
 * @type string // My IDE grabs the type from this line
 */
 title: null // My IDE requires this line to recognize the cfg
 // as a property of the object even though all cfgs
 // are available in the object
...
</code></pre>

blocks|key|2734252|text|我也分担你的痛苦。令人恼火的是，这不是标准化的。虽然我同意Juan+Mendes先生的观点，闭包编译器的特性是最完整的(可能也是最棒的！)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2734253|我一直认为在这里找到的http://code.google.com/p/jsdoc-toolkit/w/list标签列表是我们拥有的最接近真正规范的东西。它可能已经过时了，但它可能更接近于许多解析器和IDE的实现，而不是闭包编译器。|offset|length|2734254|另请参阅维基百科，了解关于应该有哪些标签的最低限度的共识。http://en.wikipedia.org/wiki/JSDoc|2734255|不过，如果你的产品支持JSDoc的闭包编译器风格，这将使它离成为事实上的标准更近一步。:D|2734256|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/jsdoc-toolkit/w/list|1|http://en.wikipedia.org/wiki/JSDoc^0|0|B|19|0|0|T|Y|1|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

I too share your pain. It's annoying that this isn't standardized. While I agree with Mr. Juan Mendes that Closure Compiler's features are the most complete (and probably the most awesome!),

I've always thought of the tag list found here <a href="http://code.google.com/p/jsdoc-toolkit/w/list" rel="nofollow">http://code.google.com/p/jsdoc-toolkit/w/list</a> as being the closest thing we have to a real spec. It might be out of date, yet still it might be closer to what many parsers and IDEs implement, moreso than Closure Compiler would be.

See also Wikipedia for the bare minimum of consensus on what tags should be there. <a href="http://en.wikipedia.org/wiki/JSDoc" rel="nofollow">http://en.wikipedia.org/wiki/JSDoc</a>

Though if your product supports the Closure Compiler flavour of JSDoc, that will bring it one step closer to becoming the defacto standard. :D

I know there are various flavours of JSDoc around. And it seems that each implementation of a JSDoc parser recognizes its own set of tags. For example, consider the differences in tags between <a href="http://usejsdoc.org/" rel="nofollow noreferrer">http://usejsdoc.org/</a> and <a href="http://www.techrepublic.com/blog/programming-and-development/create-useful-relevant-javascript-documentation-with-jsdoc/451" rel="nofollow noreferrer">http://www.techrepublic.com/blog/programming-and-development/create-useful-relevant-javascript-documentation-with-jsdoc/451</a>.

At this point, I am just confused. Is there a canonical implementation of JSDoc or a widely recognized set of core tags? Is there best implementation of JSDoc?

<hr>

EDIT

As asked in the comment below, the reason for this question is that I need to parse JSDoc comments for use with a tool that we are creating. See this question": <a href="https://stackoverflow.com/questions/11851556/are-there-any-open-source-jsdoc-parser-written-in-javascript">Are there any open source JSDoc parser written in Javascript?</a>

I'm concerned that I will have to roll my own parser, and if I do, I need to know which tags need to be supported. 

But, on a deeper level, it's concerning to me that that there is no consistent specification (or reference implementation). This makes JSDoc feel a bit ad hoc to me.

Is there a JSDoc standard?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我知道周围有很多不同口味的JSDoc。似乎JSDoc解析器的每个实现都能识别自己的一组标记。例如，考虑一下和之间在标记方面的差异。在这一点上，我只是感到困惑。是否有JSDoc的规范实现或一组广泛认可的核心标记？有没有最好的JSDoc实现？编辑正如在下面的注释中所问的，这个问题的原因是我需要解析JSDoc注释，以便与我们...

问有没有JSDoc标准？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问有没有JSDoc标准？EN