Unsurpassed Code Documentation comment generation for only $9.99. Create & update Documentation Xml, Doxygen, Qt or JavaDoc comments in C#, C++/CLI, C++, C, Java and Visual Basic code to keep them accurate, well structured and tidy with a minimum of effort.
As a professional programmer for over 30 years, I have experienced and used many programmer support applications. Atomineer stands tall amongst those, with an understanding and focus on solving the problem at hand. It is rare to find a developer who not only delivers, but supports in a speedy and exemplarary fashion.
Kudos to Jason Williams, and I look forward to the improvements and enhancements to Atomineer that i am sure to come
It has saved me countless hours of copy pasting documentation templates and mindlessly typing in the same things. Now, I manually write the 10% of the documentation which is worth 90% and the rest is automatically generated. No matter your hourly rate, you will get back your 10$ the very first day.
Works well and saves me a lot of time documenting methods, properties, values etc. Adds surprisingly good comments for uncommented code, but maintains the text of your own comments if they already exist.
It's great, use it if you want to find documenting less dull.
Excellent set of utility functions that this adds to Visual Studio for documenting your programs. I have used this in various forms for a long time now and find it indispensible.
I am looking to maintain our API documentation side-by-side with our products and we have a couple of user requirements for our documentation solution.
- Developers need to edit documentation freely while in code but can't add to much bloat so only using the /// tags that are used by IntelliSense while in code. All other documentation needed for API: code samples, best practices, etc. need to be stored in a linking xml document using the /// <include tag.
- Documentation Specialist (none developers) - Need to edit documentation while not interfering with actual source code. Their primary focus will be in the supporting xml document.
- Supporting documentation could be as simple as: each code file has a corresponding .docxml file that will be checked into source code repository (Example: Foo.cs has a supporting xml document file Foo.cs.docxml). This file would be used only by the code file Foo.cs’s /// <include tags. The supporting documentation file would follow the same schema as the output XML Documentation generated by Visual Studio.
Thoughts on how I might be able to leverage your product within my source code?
AtomineerUtils will make the code side of this simple to achieve - it handles all the documentation needs of your coders, and you can use it to enforce the tags that the developers can put in their comments (i.e. any "illegal" tags can be removed automatically).
You can also set up your templates so that AU will automatically put <include> tags into the doc comments - these can be filled in by default, using the class name so that every class automatically references a unique include file (e.g. Foo.cs.docxml). If you have any trouble setting this up, just email your requirements to me (support@atomineerutils.com) and I'll help you tweak the templates as required.
AtomineerUtils probably can't do much to help you with the external supporting documentation - but that shouldn't be a problem as you don't want your coders to be involved with this file anyway.
If you have any thoughts about features in AU that could help with your situation, just drop me a line - time permitting, I try to add support for whatever features people need.
The installer has a field where you can enter the install folder. It defaults to the official Visual Studio Addins folder, but you can install it wherever you like. An additional manual step is then required to add that path to Visual Studio so it knows where to look for the add-in.
The installer is sub-optimal for an "All Users" installation. I'm not going to review your app yet, cuz I don't want to give it a poor score, but seriously, you supply an installer, and it should allow for this common scenario.
Thanks for the feedback. It's relatively easy to install for all users by adjusting the install path to a shared location, but I agree that 'All Users' should be a standard option - I'll try to implement it soon.
Maybe the author can help me.
In the settings of atomineer I can chose a top separator comment style which looks like this:
/**------ etc. and a matching bottom separator. However, Doxygen doesn't seem to be able to parse these comment correctly.
Is it somehow possible to make Doxygen ignore the hyphens in the top- and bottom separators?
When can I use these separators? Just with the built in XML functionality for the intellisense?
Hi, @akjoshi.
I'm not sure how to get Doxygen to ignore the hyphens, but I'd try putting whitespace between the /** and the hyphens, and check that options like the JAVADOC_AUTOBRIEF mode is disabled (in this mode, Doxygen will assume that the text following the /** is the brief description instead of requiring an explicit '\brief' command). Doxygen is very configurable though.
As far as AtomineerUtils is concerned you can use virtually any text for custom top/bottom separators. However, to make this text compatible with other tools the options are reduced (e.g. to keep the source code compilable, you need to embed the separators in comments). For Doxygen to work well with your comments you may ultimately need to try a different separator style (e.g. ///// or /*****).
Which of these two is better for auto commenting hte code?
GhostDoc - http://visualstudiogallery.msdn.microsoft.com/en-us/46A20578-F0D5-4B1E-B55D-F001A6345748
(I'm the author of AtomineerUtils but I try to be objective in the text below):
AtomineerUtils has a number of basic features that are simply missing from other doc-commenting tools - it covers a greater number of programming languages (5 rather than only 2), it handles Doxygen and JavaDoc documentation styles (in addition to DocXML), it has more sophisticated automatic documentation (better use of existing documentation from other members and base classes, and it also documents things like exceptions that are thrown within a method), and it uses its own code parser so it even works for partially-complete code.
In a more general sense, other auto-documentation tools use a few tens of simple word re-ordering (e.g. "FileList" -> "List of files") rules and little else, so while they work well in many cases, they often produce very poor results. AtomineerUtils has thousands of specific rules that cover common methods and common naming conventions, so it usually makes a better stab at the auto-documentation.
But don't take my word for it - there are plenty of examples of the results at http://www.atomineerutils.com/examplesxml.php - and there's a FREE trial, so you can give it a try on your own code to see how it fares.
(And if you find anything it doesn't handle well, let me know and I'll improve it :-)
Cheers,
Jason
View Large
