In my C++ application I have about 10 different classes that define certain 'behaviors' (let's call them A, B, C, ...). Other places (methods) in the code might use these behaviors in any combination. E.g. method M1 uses behaviors A and B, method M2 uses behaviors A, C and D, ...
In practice the code is similar like this:
BehaviorCollection coll;
BehaviorA ba;
coll.push_back(&ba);
BehaviorB bb;
coll.push_back(&bb);
someComplexFunctionality (coll);
I want to generate a clear overview of which method uses a behavior, preferably in the documentation of the specific behavior, so that the class documentation of every behavior contains a list like:
BehaviorA is used by the following methods:
- method1
- method3
- method7
I could hard-code this list but after a while it will become outdated because new methods are added, methods starts to use additional behaviors, or methods stop using behaviors.
So, to make this maintainable, I prefer to have something in the method using the behaviors, telling Doxygen "this code is using these behaviors, so add something in the documentation of that behavior".
Tools like "Visual AssistX" or "Understand for C/C++" allow me to perform the lookup but they still require some manual actions every time you want to do the lookup. Therefore I want to automate this in my documentation generation system.
I am considering using defgroup and ingroup, but I'm not sure this will work for code fragments.
What is the best approach to use?
I found a solution by using the xrefitem tag.
In every method using a behavior I added a line like this:
//! \xrefitem group_behaviorA_users "Behavior A users" "Behavior A Users"
And then the behavior itself contains a documentation line like this:
See \ref group_behaviorA_users for an overview of all users of this behavior.
Problem solved.
Related
I'm using Eclipse with the OcaIDE-Plugin to write my ocaml-project.
I have written several ocaml-functions that I want to document (comment, return values and params).
I've created my documentation in the .ml-files like described in this link: http://caml.inria.fr/pub/docs/manual-ocaml/ocamldoc.html
Here is an example of one function:
(** sorting tuples where first element is key *)
let my_comp x y = (*Some code*)
Unfortunately, my comments don't show up, when I press F2 at one of the functions, it only shows the name and the file it is contained.
When writing comments in an mli-file, it works as expected, but i also want to document "private" functions that are not accessible from the outside. Can I define functions in the mli, that are NOT accessible from the outside, just for the documentation?
How can I make Eclipse to show my documention?
Well, as you said, you would like to show the documentation but not export the function out of the module. That, sadly, won't work.
I guess OcaIDE can be considered as incomplete but it doesn't look like it's something people care about (I don't know a single person working on OcaIDE). If you like having autocompletion etc, maybe try to program with emacs and install merlin (look, I found the perfect post for you : here)
As for the suggestion of defining a function in the mli not accessible from the outside, it's completely opposed to why mli files are created, so don't expect that to be possible. ;-)
I hoped I've been able to help you.
I'm doing some competitions on a website called topcoder.com where the objective is to solve algorithmic problems. I'm using Eclipse for this purpose, and I code in Java, it would be help me to have some predefined templates or macros that I can use for common coding tasks. For example I would like to write methods to be able to find the max value in and int[] array, or the longest sequence in an int[] array, and so on (there should be quite many of these). Note I can't write these methods as libraries because as part of the competition I need to submit everything in one file.
Therefore ideally, I would like to have some shortcut available to generate code both as a method and as a calling statement at once. Any ideas if this is possible?
Sure you can - I think that's a nifty way to auto-insert boilerplate or helper code. To the point of commenters, you probably want to group the code as a helper class, but the general idea sounds good to me:
You can see it listed in your available templates:
Then as you code your solution, you can Control+Space, type the first few characters of the name you gave your template, and you can preview it:
And then you can insert it. Be sure if you use a class structure to position it as an inner class:
Lastly - if you want to have a template inserts a call to method from a template, I think you would just use two templates. One like shown above (to print the helper code) and another that might look like this, which calls a util method and drops the cursor after it (or between the parentheses if you'd like, etc):
MyUtils.myUtilMethod1();${cursor}
All,
I'm using QScintilla to syntax-highlight and autocomplete my domain specific language (DSL).
I wrote a custom lexer by re-implementing (QsciLexerCustom) and I'm trying to use the auto-completion.
My problem is that the auto-completion doesn't work like I want.
I'd like my custom lexer to work like the QsciLexerPython. That is, if i add 'toto.titi.tata' to the api, when i type 'toto.' in my qscintilla editor, it suggests me 'titi.tata'. As of now, it is suggesting me toto.titi.tata. :(
I tried to add 'autoCompletionWordSeparators' to my lexer but it is not working.
How can i make my custom lexer auto-complete work like the QsciLexerPython?
Thanks a lot !
Lexer = customlexer(self.text)
api = QsciAPIs(Lexer)
api.add('toto.titi.tata')
api.prepare()
Lexer.setAPIs(api)
self.text.setLexer(Lexer)
class lexer(QsciLexerCustom):
def __init__(self, parent):
QsciLexerCustom.__init__(self, parent)
def autoCompletionWordSeparators(self):
return ['.']
The current QScintilla APIs provide no way to do this.
The main obstacle is that many of the virtual methods you need to reimplement in a QsciLexerCustom subclass aren't public. This is why the code in your example doesn't work - your autoCompletionWordSeparators method is ignored when the lexer is set, and the base-class method from QsciLexer is called instead (which returns an empty list).
You might also think you could use QsciScintilla.setAutoCompletionWordSeparators to work around this, but alas, this only works if no lexer has been set!
The only way to solve this issue is to either implement auto-completion yourself (which is doable, but a lot of work), or make a feature request on the Qscintilla mailing list to get the necessary virtual methods added to the public API for QsciLexerCustom.
The methods in question are listed here (the names are shown in bold black, rather than as a link).
This is the problem:
Create a class and set the access to be private for some of the properties or methods.
Use the doc command for the created class. This will auto-generate documentation from your comments and show it in the built-in help browser.
doc classname
The problem is that documentation for the private properties and methods is not shown in the help browser. Is there any way to overcome this problem?
So I spent like 10 minutes using the debugger, jumping from one function to the next, tracing the execution path of a simple doc MyClass call.
Eventually it lead me to the following file:
fullfile(toolboxdir('matlab'),'helptools','+helpUtils','isAccessible.m')
This function is called during the process of generating documentation for a class to determine if the class elements (including methods, properties, and events) are publicly accessible and non-hidden. This information is used later on to "cull" the elements.
So if you are willing to modify MATLAB's internal functions, and you want the docs to always show all methods and properties regardless of their scope, just rewrite the function to say:
function b = isAccessible(classElement, elementKeyword)
b = true;
return
% ... some more code we'll never reach!
end
Of course, don't forget to make a backup of the file in case you changed your mind later :)
(on recent Windows, you'll need to perform this step with administrative privileges)
As a test, take the sample class defined in this page and run doc someClass. The result:
This behaviour is by design - the auto-generated documentation is intended for users of the class, who would only be able to access the public properties and methods.
There's no way that I'm aware of to change this behaviour.
You could try:
Use an alternative system of auto-generating documentation such as this from the MATLAB Central File Exchange (which I believe will document all properties, not just public).
Implement your own doc command. Your doc command should accept exactly the same inputs as the built-in doc command, detect if its inputs correspond to your class/methods/properties etc, and if so display their documentation, otherwise pass its inputs straight through to the built-in doc. Make sure your command is ahead of the built-in on the path.
Do you use table-of-contents for listing all the functions (and maybe variables) of a class in the beginning of big source code file? I know that alternative to that kind of listing would be to split up big files into smaller classes/files, so that their class declaration would be self-explanatory enough.. but some complex tasks require a lot of code. I'm not sure is it really worth it spending your time subdividing implementation into multiple of files? Or is it ok to create an index-listing additionally to the class/interface declaration?
EDIT:
To better illustrate how I use table-of-contents this is an example from my hobby project. It's actually not listing functions, but code blocks inside a function.. but you can probably get the idea anyway..
/*
CONTENTS
Order_mouse_from_to_points
Lines_intersecting_with_upper_point
Lines_intersecting_with_both_points
Lines_not_intersecting
Lines_intersecting_bottom_points
Update_intersection_range_indices
Rough_method
Normal_method
First_selected_item
Last_selected_item
Other_selected_item
*/
void SelectionManager::FindSelection()
{
// Order_mouse_from_to_points
...
// Lines_intersecting_with_upper_point
...
// Lines_intersecting_with_both_points
...
// Lines_not_intersecting
...
// Lines_intersecting_bottom_points
...
// Update_intersection_range_indices
for(...)
{
// Rough_method
....
// Normal_method
if(...)
{
// First_selected_item
...
// Last_selected_item
...
// Other_selected_item
...
}
}
}
Notice that index-items don't have spaces. Because of this I can click on one them and press F4 to jump to the item-usage, and F2 to jump back (simple visual studio find-next/prevous-shortcuts).
EDIT:
Another alternative solution to this indexing is using collapsed c# regions. You can configure visual studio to show only region names and hide all the code. Of course keyboard support for that source code navigation is pretty cumbersome...
I know that alternative to that kind of listing would be to split up big files into smaller classes/files, so that their class declaration would be self-explanatory enough.
Correct.
but some complex tasks require a lot of code
Incorrect. While a "lot" of code be required, long runs of code (over 25 lines) are a really bad idea.
actually not listing functions, but code blocks inside a function
Worse. A function that needs a table of contents must be decomposed into smaller functions.
I'm not sure is it really worth it spending your time subdividing implementation into multiple of files?
It is absolutely mandatory that you split things into smaller files. The folks that maintain, adapt and reuse your code need all the help they can get.
is it ok to create an index-listing additionally to the class/interface declaration?
No.
If you have to resort to this kind of trick, it's too big.
Also, many languages have tools to generate API docs from the code. Java, Python, C, C++ have documentation tools. Even with Javadoc, epydoc or Doxygen you still have to design things so that they are broken into intellectually manageable pieces.
Make things simpler.
Use a tool to create an index.
If you create a big index you'll have to maintain it as you change your code. Most modern IDEs create list of class members anyway. it seems like a waste of time to create such index.
I would never ever do this sort of busy-work in my code. The most I would do manually is insert a few lines at the top of the file/class explaining what this module did and how it is intended to be used.
If a list of methods and their interfaces would be useful, I generate them automatically, through a tool such as Doxygen.
I've done things like this. Not whole tables of contents, but a similar principle -- just ad-hoc links between comments and the exact piece of code in question. Also to link pieces of code that make the same simplifying assumptions that I suspect may need fixing up later.
You can use Visual Studio's task list to get a listing of certain types of comment. The format of the comments can be configured in Tools|Options, Environment\Task List. This isn't something I ended up using myself but it looks like it might help with navigating the code if you use this system a lot.
If you can split your method like that, you should probably write more methods. After this is done, you can use an IDE to give you the static call stack from the initial method.
EDIT: You can use Eclipse's 'Show Call Hierarchy' feature while programming.