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

Doc block guidelines #112

Open
nkkollaw opened this issue Aug 8, 2017 · 7 comments
Open

Doc block guidelines #112

nkkollaw opened this issue Aug 8, 2017 · 7 comments
Assignees

Comments

@nkkollaw
Copy link
Owner

nkkollaw commented Aug 8, 2017

I'm wondering, does it really make sense to add documentation to our functions, if they're barely a wrapper to the original ones?

Unless there are gotchas, I would just leave:

/**
 * @link http://php.net/manual/en/function.xxx.php
 */

If we change something apart from the name of the function itself, we could just add a note:

/**
 * @link http://php.net/manual/en/function.xxx.php
 *
 * NOTE: in Zubr, the $haystack argument is first, $needle last.
 */

What do you guys think? IMHO it's much cleaner, and this way one would actually read the comment and see what's going on. No point in documenting something that most people already know and is on php.net anyway...

@ddziaduch
Copy link
Contributor

hm, good idea 👍

@nkkollaw
Copy link
Owner Author

nkkollaw commented Aug 8, 2017

@radmen ..?

@nkkollaw
Copy link
Owner Author

nkkollaw commented Aug 8, 2017

...it might also make sense to always have the "NOTE" part, so even if the function didn't change from the original:

/**
 * @link http://php.net/manual/en/function.xxx.php
 *
 * NOTE: no change
 */

@ddziaduch
Copy link
Contributor

Ok, my proposal - @link tag for every function - but the functions with different order should use @param tag - @nkkollaw what about that?

@nkkollaw
Copy link
Owner Author

nkkollaw commented Aug 9, 2017

Yes, if functions have changes we have to document them with @param, @return if we return something different, etc.

I will create an example and put it in the CONTRIBUTING file.

@nkkollaw nkkollaw self-assigned this Aug 9, 2017
@nkkollaw nkkollaw changed the title Remove doc block? Doc block guidelines Aug 9, 2017
@radmen
Copy link
Contributor

radmen commented Aug 10, 2017

I'd say that we should keep bare minimum:

  • Short description - usually the first line from php.net (eg for strstr: Find the first occurrence of a string)
  • @param
  • @return
  • @link to docs on php.net

(sorry for late response, I'm still on vacation till end of week)

@nkkollaw
Copy link
Owner Author

I'd say that we should keep bare minimum

I don't know if we have to document PHP's functions. I think it's more useful to describe what we change, since we expect our target to know what they're doing if they're using and feel the need for this kind of library.

Personally, I'm fine with @param etc. if they're already there (e.g., if adding them doesn't slow us down0, but the description I would along the lines of:

No change from original (see php.net/strstr)

or:

NOTE: we switched $haystack with $needle as per our guidlines

sorry for late response, I'm still on vacation till end of week

No problem!

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