I'm documenting my code using long sets of slashes to make them stand out in the code.
//////////////////////////////////////////////////////////////////////
/// #brief This is a simple test struct.
//////////////////////////////////////////////////////////////////////
struct Foo
{
//////////////////////////////////////////////////////////////////////
/// #brief Function with single line brief to demonstrate issue.
//////////////////////////////////////////////////////////////////////
void a() {}
};
I've built doxygen from a fresh subversion checkout and when it's run on the code above the line of slashes at the end of each block are included in the brief description. The problem doesn't exist in doxygen 1.8.1 that's installed on my system, so this appears to be a bug in the doxygen trunk.
I've submitted bug 700345 to the doxygen project, but am interested in taking a shot at fixing this myself.
I'm having trouble finding the code doxygen uses to detect the end of comment blocks. Does anyone have experience working with this part of the code and have a moment to point me in the right direction?
FYI, a quick solution to this is to add a blank comment line after the #brief. I'm not interested in going through ~100k lines of code to identify problematic comment blocks and add a blank line (yet).
See my proposed fix attached to the bug report you submitted.
Related
Is there any way by which I can add a useful message to a line in VS Code Editor which is not written in code but is like a note (Similar to like comments on a line in a Pull Request in Git) which can be deleted later on.
Here are the two extensions that I came across, hope this helps:
1). Line Note: https://marketplace.visualstudio.com/items?itemName=tkrkt.linenote
2). Code Annotation: https://marketplace.visualstudio.com/items?itemName=tkcandrade.code-annotation
I preferred Code Annotation for it's seemingly active org admin and the team of contributors and for marking notes as DONE or PENDING feature.
The "Line note" extension https://marketplace.visualstudio.com/items?itemName=tkrkt.linenote is probably what you are looking for…
Many languages allow you to append a comment to the end of a line. In python for example, you could have the following:
import numpy as np
a = 13.6 # a is the density of material
anser = a * b # where b is the volume in meters/cubic centimeters
...
Do not know what your language is but maybe this could work.
Comments can be added to code based on what language you are using. They are not specfic to the editor for the most part.
For example, in C++ you can comment by putting double slashes before the line such as // Random Comment.
Look up the commenting syntax for whatever code language you are using.
The publish function in MATLAB works for both scripts and functions,
while the one for Octave works only for scripts: if I enter
publish myFunc.m
Octave gave
error: publish: Only Octave script files can be published.
Am I able to publish a function in Octave? If yes, how?
You can use Octave Forge generate_html package which is meant to generate html of individual functions. It is mostly used to generate the documentation of Octave Forge packages, and its defaults reflect that, but you could add any style you want.
This package will use the same help text that the help function in Octave sees which is the first block of comments in the file that does not start by Copyright or Author. You can have it in plain text but for nicer formatting, you can use Texinfo. In that case, the first line of the help text should be -*- texinfo -*-. There is a page on the Octave wiki with tips on how to write nice help text including a short section on Texinfo syntax (the actual Texinfo manual can be a bit overwhelming).
In addition to the help text, the generate_html package also identifies %!demo blocks and generates a section with the demo code and output it generates, including figures.
The best way to see how help text and demo blocks work in Octave is to check the source (as #Andy pointed out in the comments). For example, see the source for inpolygon (scroll to the bottom to find the %!demo blocks, right before %!test and %!error). The generate_html package generates this page (note the Demonstration blocks).
This is a "multiple questions in one" question, making lots of assumptions in between, so let's address those first:
1. I'll start by the question in the comment, since that's the easiest: Matlab's publisher is not a code documentation tool. It's a "make a quick report that includes both text and code to show at your supervisor meeting or write a quick point in a blog" tool. So the link you point to is simply irrelevant in this case, since that talks about documentation for matlab code.
2. The fact that matlab's publisher also "works for functions", particularly given the first point here, should be considered to be more of a bug than a feature, or at most as a trivial undocumented extension. If you look at the matlab documentation for the publish command, you'll see it expects a filename, not a function with arguments, and the documentation only talks about scripts and makes no mention of 'function' compatibility.
3. Furthermore, even if you did want to use publisher as a "documentation tool", this is counterintuitive for functions in this format, since you need to provide arguments in order for publisher to work (which will not be shown in the actual report), you'll need a modified version that displays intermediate calculations (as opposed to your normal version which presumably does not), and the function just spews an ugly ans= blabla at the end of the report. If your end goal is documentation, it might be best to write a bespoke script for this anyway, showing proper usage and examples, like matlab does in its actual documentation.
Having said all that, yes, there is a 'cheat' you can do to include a function's code in your published report, which is that, in octave (also matlab since R2016b), functions can be defined locally. A .m file that only contains function definitions is interpreted as a function file, but if there are other non-function-declaration instructions preceding the function definitions (other than comments), then it is seen as a script. So if you publish this script, you effectively get a published report with function code in it:
%% Adding function
% This function takes an input and adds 5 to it.
%% Example inputs
In = 10;
%% The function itself
% Marvel at its beauty!
function Out = myfun(In)
%% Here is where the addition takes place.
% It is a beautiful addition
Out = In + 5;
end
%% Example use
Out = myfun(In)
(If you're not happy about having to create a 'wrapper script' manually, you can always create your own wrapper function that does this automatically).
However, both the matlab and octave publishers are limited tools by design. Like I said earlier, it's more of a "quick report to show numbers and plots to your supervisor" tool, rather than a "make nice documentation or professional reports" tool. Instead, I would invest in a nice automated latex workflow, and have a look at code formatting tools for displaying code, and simply wrap that code in a script that produces output to a file that you can then import into latex. It may sound like more work, but it's a lot more flexible and robust in the long term, particularly since the formatting commands can be very quirky as well as limited.
doxygen has support for code fence blocks that also have syntax highlighting in the output.
Here is the documentation:
http://www.doxygen.nl/manual/markdown.html#md_fenced
It looks like this:
~~~{.c}
int somefunc(int somevar);
~~~
I want to support .sql; I tried it, but it did not highlight.
My two questions are:
How do I determine what code types doxygen supports for code fence blocks?
Is there some way to define a new one? I am quite happy with just a keyword highlighter; it does not need to be a full parse.
Since my comment, I have looked into adding SQL syntax highlighting to fenced code blocks and \code blocks.
It should now be available if you build from source at https://github.com/doxygen/doxygen or it will be available in the next version (1.8.13).
Here is an example of the syntax highlighting:
If you could test it before the next release, that would be nice, as well.
I have a mainpage.dox file which is invoked in the configuration file as:
USE_MDFILE_AS_MAINPAGE = ../mainpage.dox
Inside the document I provide instructions on compiling. I would like to list the compiler option as -L/$(MKLROOT)/lib/intel64 -lmkl_rt, however the $(MKLROOT) part is expanded. Is there a way to prevent this from happening?
When I put the following in mainpage.md
1 Test with backticks `-L$(MKLROOT)/lib/intel64 -lmkl_rt`
2 Test without backticks -L\$(MKLROOT)/lib/intel64 -lmkl_rt
3 Test with code <code>-L\$(MKLROOT)/lib/intel64 -lmkl_rt</code>
#verbatim
4 Test with verbatim -L$(MKLROOT)/lib/intel64 -lmkl_rt
#endverbatim
The $(MKLROOT) in the first example gets (incorrectly) expanded.
The other three examples work as expected (using doxygen 1.8.5)
Note that USE_MDFILE_AS_MAINPAGE expects a pure markdown file, not something with a /*! .. */ comment block.
FWIW the latest version of Doxygen as of this writing (1.8.15) still behave in the same way and escaping the backslash still doesn't work. I'm using the following workaround for now:
`-L$``$(MKLROOT)`
which, while ugly, works and doesn't require adding the <code> tags everywhere.
I've also created an issue in Doxygen asking for this to be changed.
I know different methods of introducing multi-line comments in Perl. But I want to know why it doesn't have something simpler multi-line comment feature such /* comment */, which would make it much easier.
I currently follow http://www.perlmonks.org/?node_id=560985 to achieve multi-line comments. Are there any plans to include this feature in Perl anytime soon?
C-style comments come with a variety of difficult problems, including the inability to comment-out comments. Additionally, convenient syntax for one-line encourages concise writing, which makes your code easier to read. The absence of 10-line "Author: ... Input: ... Output: ... Favorite Color: ..." blocks that you see from time to time in C and C++ is another benefit.
Multi-line comments encourage long writing that is better expressed more concisely or as documentation, so this is what Perl encourages with its # and =pod operators (respectively).
Finally, if you are having trouble with Perl's style of commenting, you should configure your editor to edit programs, not text. In Emacs, if you start writing something like # this is a comment that is getting longer and longer and longer and oh my goodness we are out of space on this line what to do now and type M-q, Emacs will automatically insert the # at the beginning of each line that it creates.
If you just want to comment-out a block of code, then you need look no further than M-x comment-region and M-x uncomment-region, which will comment out the region in pretty-much any language; including Perl.
Don't stress about the syntax of comments; that's the computer's job!
There was a discussion regarding this on the perl6-language#perl.org mailing list. Although in the end the discussion was inconclusive, the summary posted here makes for interesting reading.
As with any multiline comment structure, there will be a "open" and a "close" comment condition, and that leads to problems with nested comments.
for example, C uses /* as the open and */ as the close. How does a multiline comment system handle comments within comments? C will fail if you try to comment a block that is already commented.
Note that line-based comments (e.g. c++ // comments) do not suffer this problem.
Simplicity is in the eye of the beholder. That said, there are already a number of ways to do multi-line comments. First, void string literals:
q{This text won't do anything.
Neither will this.};
This has the unfortunate side effect of triggering a warning:
Useless use of a constant in void context at - line 4.
Another option is using a heredoc in void context - for some reason this doesn't cause a warning:
<<ENDCOMMENT;
Foo comment bar.
ENDCOMMENT
As you can see, the problem isn't the lack of syntax as such (python doc comments look vaugely similar to the q{} method in fact) - it's more just that the community of perl programmers has settled on line comments using # and POD. Using a different method at this point will just confuse people who have to read your code later.