Unsurpassed Code Documentation comment generation. Create & update Documentation Xml, Doxygen, Qt or JavaDoc comments in C#, C++/CLI, C++, C, Java, UnrealScript and Visual Basic code to keep them accurate, well structured and tidy with a minimum of effort.
well, i just found it two days a go, have tried many addons like this before and never got what i wanted, so, when i downloaded the trial version i was telling myself that it's waste of time again, but after one hit and getting the resault, in both c# winapplication and even c#script for unity 3D game development, i called my friend that had a bank account out side of country and told him that i want it in less than 3 hours ! god i never was happier than this about spending dollars on something other than minecraft !
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.
I am a developer working with a mixture of C# and C++ projects. Our code standards specify qt style Doxygen comments in C++ projects and standard DocXML in C#. I find automineer auto comments very handy as a starting point for documentation but am forced to only use it in one language currently (c++). Is there any way to associate a specific fiule extension (.cs, for example) with a documentation style? Would make things much easier.
I've looked at the advanced customisation but, to be honest, failed to accomplish anything there, since i need two very distinct types of customisations (including blank line formatting, etc) for each and the prefs.xml doesn't seem to be picked up by the search path definition (I mostly need prefs.xml to be different in different projects).
Surely, there is some way of achieving what I need without me constantly re-configuring atomineer when switching between projects?
Yes, what you want to do is quite easy to achieve using the "rules search path". Using the %solutionPath% or %projectPath% variables in the search path allows you to store a different set of preferences in each project/solution, so you can have custom settings for C++ and C#.
Details on this are here:
If you have any trouble setting this up, please contact email@example.com and I'll be happy to help you get it working.
(Watch this space - an improved preferences system is in the pipeline that will make this even easier - coming soon)
I seem to have gotten it to work. I mostly use C# code, so I started by first configuring C++ code for doxygen-style comments. Once I've saved my settings, I opened prefs.xml in automineer installation directory and copied <Doxygen>, <Format> and <DocComment> sections into individual XML files called Doxygen.xml, Format.xml and DocComment.xml
I then setup project search path to be %projectPath%\Automineer
Next I went into automineer and reconfigured it for DocXml format to be used with C# and saved changes.
Now all I have to do is add a folder to my C++ projects called "Automineer" and put my 3 xml files inside and I get doxygen comments in C++ files and DocXml in C# as I wanted.
It would be nice to automate this somehow though, perhaps allow different style templates depending on file extension. So am looking forward to configuration improvements mentioned.
It is a bit clunky right now but it works and that is what matters the most. I find automineer very handy and much more usable than the alternatives I've tried (including the one most commonly suggested, GhostDoc)
It took slightly longer than expected to implement, but 8.02 has now been released with a new preferences system - this now allows you to easily set up Atomineer to support independent documentation system and formatting preferences for each coding language you use.
I have used the new settings system and have to say - it is great. Setting up different comment standards for different languages is now a breeze and quite intuitive. Whilst the quick setup wizard for specific language is disabled, it is still trivial to manually set specific configuration. And there is no longer any need to add custom configuration files as part of the project to achieve required operation.
I can see that the override system remains in place, so if further custom alterations are required, they can be implemented still (i.e. not breaking what was already preset by some people).
All in all, I have to say - the new build is great and I am enjoying it a lot.
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 (firstname.lastname@example.org) 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?
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 /*****).
(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 :-)