Not sure if it will do what you need, but it's worth a shot!
I have currently implemented a somewhat stable return tag generator, but my question is when should a return tag actually be added?
There are a few stances I can see on this:
Should every function comment stub have a return tag, then, whether something is explicitly defined or not?
The current implementation is unreliable in more complex code:
Would it be better to leave a return tag off completely, and let the user decide, or is an educated guess good enough?
The return tag is unimportant to me:
The return type may not be all that critical in a lot of cases, and when it is, it isn't that big of a deal to type it in myself.
Which approach would you rather I take?
-Always create a return tag
-Guess when to add the return tag
-Never create a return tag
Thanks for your input/suggestions!
I would prefer that you always include the return tag. It's easy enough to delete if it's really not wanted. Like you said, every JS function returns something, so maybe it's appropriate to document what it returns, even if it's `undefined`.
Thanks for your response Joseph, I had completely forgotten about this post! I really need to bring the 2010 version of this extension up to date with the 2012 version. I have an options UI in the 2012 version, and I think it would make sense to simply add an option to determine when to add the return tag. (Always, Never, Auto)
Since writing this post, I also agree Always would be better, especially if you're like me and write the comment for the function before writing the code itself.
Currently, it is not possible. It is not because it would be difficult to do so, I just have not had the time to test it in an html/aspx/cshtml file, so I did not want to include it. I'll try looking into it this evening and see how it fares.
Yes, I am definitely replying to myself, this is as much for me to remember what needs to be fixed as to let everyone know about current issues.
-Extension Crashes when no parentheses are on the same line as a function declaration
-On Extension Crash, the file is rendered un-editable until closing and re-opening the file.
Now that I feel I have something stable for VS2010 SP1, that is something I would like to look into. I'll let you know more when I get a chance to look into the details of supporting VS11. Since I am new to VS extensions, I do not know if that is something that will be really quick to do, or if it will take some time.
Thanks Daniel, for suggesting I create the extension for Visual Studio 2011. I've created the extension page here: http://visualstudiogallery.msdn.microsoft.com/0cb7304b-ad78-4283-ba2b-42804657fcdd
You can also download it through the extension manager in VS11.
If you run into any issues with it, don't hesitate to mention it in the discussions on that extension page.