如何在 JsDoc 中返回 void?

在 JsDoc 中是否有一种特定的方法来声明一个返回 void 的方法或函数?目前,我认为 void是默认的返回值,其他返回值必须明确提供:

/**
* @return {Integer} The identifier for ...
*/
52000 次浏览

I don't believe you have to choose from a set of types in JsDoc... you can use any type name you wish (the curly braces indicate it's a type), so you can simply do:

@return {void}

Although, this is probably more correct for JavaScript:

@return {undefined}

Closure Compiler

According to the documentation of Google's Closure Compiler if nothing is being returned, the @return annotation should be omitted.

If there is no return value, do not use a @return tag.

Source: https://developers.google.com/closure/compiler/docs/js-for-compiler#tags

jsdoc-toolkit

However further documentation also states that the returnType and returnDescription are optional parameters.

returnType - Optional: the type of the return value.

returnDescription - Optional: any additional description.

Source: https://code.google.com/p/jsdoc-toolkit/wiki/TagReturns

Summary

You could either leave out the return annotation or include it without any parameters.

To help to decide between the other answers, there is one benefit in explicitly written @return {void}. Although @return can be omitted, for a documenting coder, seeing the @return {void} works as a memory aid. It tells the coder that the return documentation is written. If there is no @return written, then the coder might need to inspect did he forget to write the return value documentation or does the function truly return nothing.

Of course, the return value documentation might be outdated. That is something the coder cannot directly know from the docs and needs to read the code to verify. Still, seeing the return value written gives the coder a bit of certainty that the documentation is correct and not just hastily written.

Looking at the ESlint docs they use @returns {void}

Source: http://eslint.org/docs/rules/valid-jsdoc

Since I need to provide an @returns for each function to pass tests in order to push code for certain projects this is required in my case.

I find this less ambiguous than leaving out the @returns:

@returns {} Nothing is returned.

or even

@returns {} Nothing is returned because this is a broadcast receiver.

Just an idea.