Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update docs/Documenting.md #1265

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Dragorn421
Copy link
Collaborator

Let's actually formalize an agreement on how to handle documentation

@Dragorn421
Copy link
Collaborator Author

Also we need to discuss the documentation style on structs because // comments on struct fields are completely ignored by doxygen (it expects ///, //!, /** or /*! https://doxygen.nl/manual/docblocks.html )
And it would be great to be able to expand explanations on more than a single line

@EllipticEllipsis
Copy link
Contributor

(our current style would require //!<: https://doxygen.nl/manual/docblocks.html#memberdoc )

Other directives that may be used for documenting functions:

- `@see` to reference something else ([see below](#linking-related-information)).
- `@note` to bring attention to some of the function behavior.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is appropriate to have something stronger than @note for some things where stuff will break badly if instructions are not followed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah and i think the default should be @remark since @note is not for trivia stuff but it would end up being / already is used this way

The problem would be that graduation is completely arbitrary though, or can we come up with actual clear "rules"?

I made this to showcase @remark, @note, @attention, @warning

/**
 * Spawn an object file of a specified ID that will persist through room changes.
 *
 * This only starts loading the object, the data will not be available immediately when the function returns.
 *
 * Used for gameplay_keep, Link's object, and the subkeep if any.
 *
 * @return The new object slot corresponding to the requested object ID.
 *
 * @remark This function is not meant to be called externally to spawn object files on the fly.
 * @note When an object is spawned with this function, all objects that come before it in the entry list will be treated as
 * @attention persistent, which will likely cause the memory available for object space to run out.
 * @warning This function is only meant to be called internally on scene load, before the object list from any room is processed.
 */

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually use @remark like I'd use "Remark:" in a paper, as a tangential thing that's not usage(/argument)-specific, like what the original name of the function is if known.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually use @remark like I'd use "Remark:" in a paper, as a tangential thing that's not usage-specific, like what the original name of the function is if known.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@warning is tricky because it can be mixed up with compiler warnings, but I don't love @attention.


It is possible to include HTML and LaTeX in documentation comments.

However it is prefered not to do so, so that the raw text stays readable when looked at as plain text, for example when browsing the source code.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think there are systems where LaTeX is useful enough to make it worth it (the matrix stuff, probably sys_math3d), but I know I'm in the minority.

(I suppose fundamentally my point would be that "there is no way to write this clearly in the code, and the next best thing is for it to be clear in the Doxygen".)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can find a compromise where LaTeX is its own part and doesn't add information besides math, and there's a main separate explanation part that is readable as plain text?

Do you have an example in MM maybe, there's not much LaTeX in OoT and idk how to find it

* If there is no current buffer or it is time to swap, this buffer will be swapped to
* immediately, otherwise it will be swapped to later in Sched_HandleRetrace.
*
* @see Sched_HandleRetrace
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Doxygen generate the correct links if function names are not followed by ()?

@fig02 fig02 added the Needs discussion There is a debate or other required discussion preventing changes from being made label Aug 27, 2022
@Dragorn421 Dragorn421 added Needs contributor approval Waiting for author There are requested changes that have not been addressed labels Sep 30, 2022
Copy link
Collaborator

@fig02 fig02 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read over this document again after not having read it in a long time, and everything in it mostly still applies to how we approach documentation today.

We still dont really have clear preferences on different doxygen tags like "@note". I tend to not use them at all and just the word "note:" or "see:"
We can either take that section out or make it clear that we arent strict about it at the moment.

I think overall its clear that most people prefer reading docs straight in the source code and dont even bother with generating docs with doxygen.

Comment on lines +16 to +17
A simple example of documenting a function withjust a description (note the leading `/**`):

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need a space between "with" and "just"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs discussion There is a debate or other required discussion preventing changes from being made Waiting for author There are requested changes that have not been addressed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants