Not logged inOpenClonk Forum
- - By MrBeast [de] Date 2010-08-06 15:04 Edited 2010-08-06 15:09
I think it would be positive to have an automaticily created documentation from the original objects. This isn't something we need to push yet, but to avoid unneccessary work I would suggest to apply the following documentation guidelines for newly created objects instead the old.

Documentation Guidlines


First, every object should have an description what it is for. This block should be at the beginning of every script.

Example:
/** An cool object.
* This object can do many cool things, for example, beeing cool or letting your clonks getting an cold. Should be used with care.
* @sa VeryCoolObject
* @author Spell
*/


The first line is the summary. Typically it should be only an one liner.
The second line is the detailed description, it should tell what the object and how you typically use it.
@sa is an abreviation of "see also" it adds an paragraph to the documentation saying "See also:" with links to the listed identifiers.
@author let you define an author or an list of authors to the documentation if you want to be named.

Secondly, every identifer (Methods and Variables) can have an documentation, and those which are most likely to be used outside should've an documentation.

Example:
/** Makes \a target freezed.
* @param target The object which shall be freezed.
* @param time The time in frames till \a target will get freed again.
* @return \c true if \a target was sucessfully freezed, \c false otherwise.
*/
public func FreezeClonk(object target, int time)
{
  [...]
}


The first line is the description of the method.
The second and the third lines are the descriptions of the parameters.
The forth line tells what the return value is.
\a, \b and \c are for visual enhencmant, \a makes the next word italic, \b makes it bold and \c makes it proportional. Alternativly Doxygen support HTML Elements like <i>,<b> and <tt> for further formatting.

This are the basics. You can find more informations at in the Doxygen Manual especially in the list of the commands

doxyC4S.py


doxyC4S is an Python-Script which I've written for the creation to beeing able to use Doxygen together with C4Script. To use it you need to put the Script in the directory of your Doxyfile and setting either the INPUT_FILTER value or the FILTER_PATERN value to it. (INPUT_FILTER = doxyC4S.py  or FILTER_PATTERNS = *.c=doxyC4S.py). You can download the script here.

The script has some extra functionality which you may want to use:

Enums
//? Start Enum <Name> says doxyC4S that the following static constants (till the next //? End Enum) should be interpreted as part of the enum.

Example:
/** Damage Types. */
//? Start Enum DMG_Type
static const DMG_Melee=0;
static const DMG_Explosion=1;
static const DMG_Fire=2;
static const DMG_Other=3;
//? End Enum


Doxygen Only Lines
With //?- you can define Lines which are only interpreted by Doxygen but not by Clonk. This is for overiding the declaration of the methods, for example for saying Doxygen that you want an Enum and not really an int as you say clonk.

Example:
/** Returns the resistance of the object to the given \a damageType.*/
//?- public func GetResistance(DMG_Type damageType)
public func GetResistance(int damageType)
{
  [...]
}
Attachment: doxygen.patch - An patch adding neccessary files for generation of an doxygen documentation. (83k)
Reply
Parent - - By Newton [de] Date 2010-08-07 02:44 Edited 2010-08-07 13:37
Wow! Great examples, good work! Even though, regarding your example with the static consts, I'd not like to hide from the developer that the constants are integers.
But yeah, IMO this kind of docs would be a great way to easily maintain some docs without about something we never had docs before but for which docs would be actually pretty important. Especially for the libraries. And that with the least possible effort, I think. We actually already discussed this a bit before. Also, I think this should be slowly deployed after our struggles for the release.
What I don't like about doxygen syntax at all is this \x annotation for bold/italic/whatever text. It is much more common to have *this* as bold, /this/ as italic and _this_ as underscore. Also, I never was a big fan of those @Javadoc annotations because it seems a redundant for me - as if it wouldn't be possible to program this documentation-parser-smart enough to recognize parameter descriptions without the @param in front or at least make it look less littered. F.E.
/** Makes /target/ freezed.
* target - The object which shall be freezed.
* time - The time in frames till target will get freed again.
* returns |true| if /target/ was sucessfully freezed, *false* otherwise.
*/

reads natural in the source code but would also still be perfectly clear to parse. I am not sure if doxygen offers also such a more natural syntax. But speaking of natural, why did you choose Doxygen and not NaturalDocs, by the way?
Parent - - By MrBeast [de] Date 2010-08-07 13:23
Some things:
1. I am more an fan of technical (but human readable), not so verbose syntaxes
2. Doxygen has some nice features like inheritance diagrams which I don't really want to miss
3. In fact, I've not yet really used Natural Docs
Reply
Parent - - By Newton [de] Date 2010-08-07 13:38

>1. I am more an fan of technical (but human readable), not so verbose syntaxes


Hmm? Which would be more in the style of naturaldocs and not the javadoc syntax, right?
Parent - - By MrBeast [de] Date 2010-08-07 14:04
No, The Syntax of Natural Docs is maybe more human readable but it needs to consist of many unneccessary elements to look "right" while the Javadoc/Doxygen Syntax only needs a few elements and it's always clear how to interpret them. It should be point of the generation tool to format the data not of the one who is writing it.

For comparence:

Doxygen:
/** Makes \a target freezed.
* @param target The object which shall be freezed.
* @param time The time in frames till \a target will get freed again.
* @return \c true if \a target was sucessfully freezed, \c false otherwise.
*/

Natural Docs:
/*
  Function: Freeze Clonk
 
  Makes \a target freezed.
 
  Parameters:
 
    target - The object which shall be freezed.
    time - The time in frames till *target* will get freed again.
 
  Returns:
 
    true if *target* was sucessfully freezed, false otherwise.
*/


See? Natural Docs need a lot more formating while telling exactly the same.
Reply
Parent - - By Newton [de] Date 2010-08-07 14:50
Thats true. When I saw this, I was not very astonished. But I assumed that the extra spaces there are unnecessary. So it could be at least:

/*
  Function: Freeze Clonk
  Makes a target freezed.

  Parameters:
    target - The object which shall be freezed.
    time - The time in frames till *target* will get freed again.

  Returns: true if *target* was sucessfully freezed, false otherwise.
*/


Still, I think there is some "verbosity" in it, thats why I was hoping that you'll point me to some alternative doxygen syntax which will have these features... ;-)
Parent - - By MrBeast [de] Date 2010-08-07 15:28
No, there are some alternative syntaxes for doxygen but those are only provided for compatiblity with other documentation tools and have in fact only minimal differences.

The example could also look like:
/*! Makes <i>target</i> freezed.
* \param target The object which shall be freezed.
* \param time The time in frames till <i>target</i> will get freed again.
* \return <tt>true</tt> if <i>target</i> was sucessfully freezed, <tt>false</tt> otherwise.
*/

But I don't think that that is what you want.
Reply
Parent - By Newton [de] Date 2010-08-07 15:30
These html-tags are used in javadoc iirc
Parent - - By Nachtschatten Date 2010-08-07 19:25

> But I assumed that the extra spaces there are unnecessary.


They are. Except from your Returns-line (where I'm not sure if NaturalDocs accepts that), this looks just fine.
Reply
Parent - - By Newton [de] Date 2010-08-07 21:41
You know/you use naturaldocs?
Parent - - By Nachtschatten Date 2010-08-07 22:14
Yes, I used NaturalDocs for one of my last Clonk projects. At the time, I chose it over Doxygen for its more natural/human-like syntax, and I liked the generated documentation better. However, that was about two years ago, when NaturalDocs 1.4 was just released.
Reply
Parent - - By Newton [de] Date 2010-08-07 23:51
Which clonk project? Can you show us the documentation? Also, if you have naturaldocs installed,...

>Except from your Returns-line (where I'm not sure if NaturalDocs accepts that),


Perhaps you can easily check this?
Parent - - By Nachtschatten Date 2010-08-08 04:16

> Which clonk project? Can you show us the documentation?


An unfinished port of JUnit to C4Script, you can download its documentation from Launchpad.

> Perhaps you can easily check this?


Of course I can. I tested this with the latest version of NaturalDocs (hey, finally I had a reason to update). The parameters section is good. The function name should exactly match the actual function in the script, so assuming it would be called public func FreezeClonk(), the space in between the words should be removed. If it is there, the documentation is generated without a syntax-highlighted function header at the beginning of the description. Also, a linebreak seems to be necessary after "Returns:". I additionally recommend specifying the return type ("bool - true if ..."), but it works without as well.
Reply
Parent - - By Newton [de] Date 2010-08-08 11:25

>The function name should exactly match the actual function in the script


This seems to be a bit redundant for me. The function name is already below the comment, right? Is "Function: yaddayadda" necessary?

>linebreak seems to be necessary after "Returns:"


Too bad :-/

>C4Script JUnit


So, this means that NaturalDocs works fine with C4Script?
Parent - - By Nachtschatten Date 2010-08-08 13:36

> Is "Function: yaddayadda" necessary?


NaturalDocs needs this so-called "topic line" to identify documentation paragraphs in comments. Technically, Function, Parameters and Returns are all topics, but only the last two are optional. The upside of this verbosity is that it's valid to include several unrelated topic inside a single comment, which is mainly useful for file headers.

> So, this means that NaturalDocs works fine with C4Script?


It does, because C4Script is still similar enough to C/C++. It's basically the same as with syntax highlighting in code editors.
Reply
Parent - By MrBeast [de] Date 2010-08-08 14:00

>The upside of this verbosity is that it's valid to include several unrelated topic inside a single comment, which is mainly useful for file headers.


Doxygen can do that, too, but still doesn't need the verbosity.
/** @fn Foo
* Does Foo.
*
* @fn Bar
* Does Bar.
*/
Reply
Parent - By Newton [de] Date 2010-08-07 13:46

> inheritance diagrams


While there is a big inheritance in OC (as opposed to CR), I think it is not worth the effort (and maintenence work) to document the public methods of the objects which just use the libraries: They normally offer no public interface to be used by other objects or to be inherited by other objects. Thus, I am not sure if this is needed at all for a C4Script (library) documentation.
Or what do you think?
Parent - - By AlteredARMOR [ua] Date 2010-08-07 13:59
Looks a lot like JavaDoc... Nice if it is going to work just as good.
Reply
Parent - By Newton [de] Date 2010-08-07 14:01
Did you want to reply to Spell?
Parent - By Isilkor Date 2010-08-08 13:31

> I'd not like to hide from the developer that the constants are integers.


Why not? If the only valid values are the ones from the "enum", then for all intents and purposes the parameter isn't an int.
Reply
Parent - By Newton [de] Date 2010-08-15 14:22
By the way, since NaturalDocs syntax is really pretty verbose, I agree that JavaDoc-like syntax is the best way to go. As Spell said, please "apply the following documentation guidelines for newly created objects instead the old.". Somewhen later, we can create these docs for all important objects.
Parent - - By Maikel Date 2010-08-18 13:01
What about translating the docs to other languages, some people on the clonk.de forum might kill you for introducing English-only docs, judging from the recent activity.
Parent - - By Newton [de] Date 2010-08-18 14:34
We need to talk about how we organize the docs in the future anyway. But using javadoc can't be a bad idea cause it requires low maintenance. These generated Javadocs could be translated into German using the same technology as currently wich the originally german docs (C4Script Documentation).
Parent - By Maikel Date 2010-08-18 14:58 Edited 2010-08-18 15:00
Can you or Spell merge the guidelines in this thread with the wiki?

But before we even use this we should consider this first.
Parent - - By MrBeast [de] Date 2010-08-18 21:18
Doxygen has an Feature for writing muiti-language docs:
/** \~english An cool object. \~german Ein cooles Objekt.
     \~english This object can do many cool things, for example, beeing cool or letting your clonks getting an cold. Should be used with care.
     \~german Diese Objekt kann viele coole Sachen machen, unter anderem cool sein und Clonks erkälten. Sollte vorsichtig benutzt werden.
     \~ @sa VeryCoolObject
         @author Spell
*/
Reply
Parent - By Maikel Date 2010-08-18 21:55
In my opinion that's just too much garbage in scripts.
Parent - By Luchs [us] Date 2010-08-21 03:34
That seems to make documenting some function just more difficult and less readable in the code.

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill