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

Correctly document the functions #73

Open
claucece opened this issue Mar 18, 2018 · 6 comments
Open

Correctly document the functions #73

claucece opened this issue Mar 18, 2018 · 6 comments

Comments

@claucece
Copy link
Member

claucece commented Mar 18, 2018

A style format for how to manually document functionality is needed.

For the actual documentation of all the functionality, we need the whole 'Full OTRv4 flow #2' done and issue #72 done.

@claucece claucece added the API label Mar 18, 2018
@giovaneliberato giovaneliberato removed their assignment Apr 5, 2018
@claucece
Copy link
Member Author

claucece commented Apr 10, 2018

Let's document with this structure:

For functions:

/**
  * @brief Define what the function does in summary
  *  
  *  @params 
  *  [out] the out parameter
  *  [in] the in parameter
  *
  * @return (if present)
  *
  * @details Details around this function if any
  *
  * @warning
  * Any warning
 **/

For structures:

** 
  * @brief A summary of what is this structure
  * 
  *  [type] 
**/

@giovaneliberato

@olabini
Copy link
Contributor

olabini commented Apr 12, 2018

One open question. This proposal uses [out] and [in] parameters. I used a different style, using [bla] where bla is the name, and not specifying whether it's an out or in parameter (I expected that to be clear from the description of the parameter). We should decide what form to use.

@claucece
Copy link
Member Author

I guess things are already documented that way, so:

/**
  * @brief Define what the function does in summary
  *  
  *  @params 
  *  [bla1] the bla1 parameter
  *  [bla2] the bla2 parameter
  *
  * @return (if present)
  *
  * @details Details around this function if any
  *
  * @warning
  * Any warning
 **/

should be fine. :)

@olabini
Copy link
Contributor

olabini commented Apr 12, 2018

Great, thanks! =)

@olabini olabini closed this as completed Apr 12, 2018
@giovaneliberato
Copy link
Contributor

Agreed!

@claucece claucece added the importance high An issue that is absolutely necessary to have done before final release label Jun 26, 2018
@claucece claucece reopened this Jun 26, 2018
@olabini
Copy link
Contributor

olabini commented Mar 9, 2019

This depends on #6

@olabini olabini added waiting and removed importance high An issue that is absolutely necessary to have done before final release labels Mar 9, 2019
@claucece claucece added this to the architecture milestone Oct 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants