When I check the code from packages I see they use both // and /// to comment.
// is a normal comment.
/// is a highlighted comment.
It seems like using /// is better, so why do they using both of them? And does it make the app slower when using comments in Dart?
DO use /// doc comments to document members and types.
Using a doc comment instead of a regular comment enables dartdoc to find it and generate documentation for it.
Example:
/// The number of characters in this chunk when unsplit.
int get length => ...
See the official guide here.
For historical reasons, dartdoc supports two syntaxes of doc comments: /// (“C# style”) and /** ... */ (“JavaDoc style”). We prefer /// because it’s more compact. /** and */ add two content-free lines to a multiline doc comment. The /// syntax is also easier to read in some situations, such as when a doc comment contains a bulleted list that uses * to mark list items.
If you stumble onto code that still uses the JavaDoc style, consider cleaning it up.
do it make the app slow when using comment in Dart?
No, dart compiler will remove them from the release build.
First it's not affect on speed of your codes, the complier just igonre it, it's for you and for other developers.
Second, // it's just a normal comment for normal text or code you don't use for now. But /// it's used for document your code and explain what your function or code is supposed to do.
You can read full DartDoc from http://dartdoc.takyam.com/articles/doc-comment-guidelines/
Related
I was just commenting my application as i found out that you can use diffrent commenting. I'am curious if there are some commenting rules for this or has it something to do with the auto commenting of flutter it self?
My choice go's to the /// one since the color is different so it is better to see what i commented and what flutter did.
This make me wonder why there are two diffrent ways to comment
// <-- This is a way
/// <-- This is a way
Thanks in advance
In Flutter, // is used to create a single-line comment, which is ignored by the Dart compiler.
/// is used to create a documentation comment, which can be used to generate documentation for your code using the dartdoc tool. This type of comment is also ignored by the Dart compiler, but it can be used to provide additional information about a class, function, or variable for developers reading the code.
Example:
/// This is a documentation comment for a function
void myFunction() {
// this is a single-line comment
}
When you use dartdoc tool, it will extract the comments from the code and generates the documentation in HTML format.
In addition to this refer the official documentation about dartdoc guides-documenting-dart-libraries. For the usage and examples refer guides-dartdoc
Dart supports three kinds of comments:
// Inline comments
/*
Blocks of comments. It's not convention to use block comments in Dart.
*/
/// Documentation
///
/// This is what you should use to document your classes.
Also can give you a good hint
// TODO: some words
According to Effective Dart,
// is for a single-line comment, like you'd have on the inside of a function
/// is for multi-line (though single-lines are supported too) documentation comments, like you'd have above a function definition.
// is for a single-line comment, like you'd have on the inside of a function
/// is for multi-line used to documentation comments, like you'd have above a function definition.
The company I'm working for does not use Doxygen, and in their coding standard explicitly prohibits "parseable comment styles such as javadoc, etc".
However, I've still found it very useful to run Doxygen myself just so I can see the class structure, and get nice per-class documentation of all the methods the a class has, including inherited ones.
The company does document the classes in the header files, with simple comments above each method declaration. It would be very useful if I could configure Doxygen to treat these comments as the function descriptions, even though they don't start with any Doxygen markers.
So: is it possible to get Doxygen to treat comments on the line above declarations as if they are the description for that item even when the comment is not marked with Doxygen's "parse this comment" markers?
The next best thing is to click on the #include <foo.h> links at the top of the class file to jump to the file itself, which I have been using. That doesn't help for seeing all of a derived class's methods in one place, though.
When the comments above the methods have only "normal" comments i.e. with /* or // the best thing to do would be that you write a small filter (see e.g. INPUT_FILTER with sed or awk or ... ) in which you convert (all?) /* / // comments into /** / /// so the comment blocks are parsed by doxygen. The result is not as nice as with "full" doxygen comments.
It is just a workaround and can lead to unexpected results when the INPUT_FILTER does not exclude e.g. // inside strings from consideration.
I'm new to CoffeeScript and seems that I can't find any document generator for CoffeeScript using Javadoc syntax. The only one I could find is available as a patch to the CoffeeScript compiler.
So, what do you use to generate documentation from Javadoc comment on CoffeeScript or how do you document your function arguments and return values?
So, JavaDoc syntax has never really caught on with JavaScript developers. There are those who use something like it—notably Google—but it's kind of at odds with JS, which doesn't have static typing and allows any number of arguments to any function.
If you want to create beautiful documentation with CoffeeScript, the standard is Docco (its home page is an excellent example). If you want to create JavaDoc-style comments for every function... well, you'll have to create them by hand, and escape them with backticks.
Alternatively, you could work in CoffeeScript until your code is release-ready, then document the resulting JavaScript.
Docco is great for prozedural coding style. If you want to document an API, coffeedoc is for you.
People looking forward to using javadoc style documentation in coffeescript can checkout codo ( http://netzpirat.github.com/codo/ ) which provides support for a subset of javadoc and automatically infers class names, function names and parameters from source code.
I'm using YUIDoc. I can add comments using a syntax similar to Javadoc to my classes, methods and events. The documentation gets output as html/css files and you can even customize the page layout.
Check this documentation example: http://yui.github.com/yuidoc/api/
PS: It relies on Node.JS and you need to install the package yuidocjs
npm install yuidocjs -g
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.
I'm a big fan of GhostDoc's automatic comment generation in Visual Studio so am looking for an plugin that does the same job with my Java code in Eclipse. Any recommendations?
You can check JAutodoc (http://jautodoc.sourceforge.net/)
From the author:
JAutodoc is an Eclipse Plugin for
automatically adding Javadoc and file
headers to your source code. It
optionally generates initial comments
from element name by using Velocity
templates for Javadoc and file
headers.
This one is the one I've found closest to GhostDoc.
It is basically the equivalent of Javadoc, which can be generating in eclipse with the shortcut:
ALT+Shift+J
(when you are within the Java function you wish to add javadoc for)
From there, if you really want XML format, you can try and use a JELDoclet
GhostDoc has a nice extra feature that infers a description of what the method does by parsing the method name and providing this as skeletal documentation. For example, using GhostDoc on a method named GetDocumentName() might return the phrase "Gets the document name". While this is hardly more information than provided by the method name, it adds method documentation where previously none existed. Some might argue that this is barely useful. I argue to the contrary because it supports generating documentation from the source code (e.g., for tools like NDoc or SandCastle).
In my opinion the greatest benefit of GhostDoc over eclipse's "Generate Element Comment" is that it encourages programmers to begin adding documentation comments by adding an extremely fast and reliable way create this. The programmer can accept the inferred text, (suitable in 50 - 80% of cases), or expand on this for more complex methods. For the junior programmer who is not as familiar with how documentation comments are used, this can quickly shorten the learning curve and encourage good programming practices.
Javadoc is not like GhostDoc my friend. Javadoc only creates the structure so one can write the documentation from scratch. GhostDoc actually fills up the information according to the Method/Property name.
Example:
/// <summary>
/// Gets the user from id.
/// </summary>
/// <param name="id">The id.</param>
/// <returns></returns>
private string GetUserFromId(string id);
JAutoDoc is the closest I've found so far but it's not as magical as GhostDoc.
Never used GhostDoc, so not sure what extra functionality it gives, but if it's about generating type and method comments based on the name, parameters, return type etc. then eclipse has it built in, so no extensions needed.