-
Notifications
You must be signed in to change notification settings - Fork 438
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
Inline Docs #3
Comments
This could be a good option :) |
I spent a little more time doing some research on this one and narrowed it down to two options. If anyone has suggestions for more, please share! phpDocumentor - The go-to standard over the years for auto generating docs and has gone over a pretty big overhaul in the last few years. There are many maintainers, frequent updates, and they are working to help create a PSR standard for writing docblocks. On the downside, the generated html for the docs is a little rough around the edges. apigen - Provides a powerful, yet simple interface to create your docs along with a straight forward setup process. The generated html includes a search feature which allows you to skim the docs quickly - this does not appear to be included in phpDocumentor. There seems to be a decent amount of support for the library, but issues can linger for some time. There are some issues that have been open for up to a year regarding PHP 5.6 support. With all that said, it is my understanding that on the whole the generated html won't be a dealbreaker as we are planning to pass generated json documents to a proprietary framework anyways. I'm leaning towards phpDocumentor still, but any thoughts are appreciated. |
JFYI Google App Engine documentation uses phpDocumentor: |
++phpdocumentor because of AppEngine |
PHPDoc works for me |
We would like to build the project with inline examples and hash documentation so we can parse the code out to match our docs found here. I would like to propose the following to fulfill these needs. The hash documentation is based on the PSR-5 PHPDoc standard. Thoughts? :) /**
* Pass in an array of configuration parameters to construct your client.
*
* Example:
* ```
* $client = new StorageClient([
* 'keyFilePath' => '/path/to/key/file.json',
* 'projectId' => 'myAwesomeProject'
* ]);
* ```
* Description for a second example
* ```
* $client = new StorageClient([
* 'keyFile' => $keyFile,
* 'projectId' => 'myAwesomeProject'
* ]);
* ```
*
* @param array $config Configuration options {
* @type callable $httpHandler Override the default http handler.
* @type string $keyFilePath The full path to your service account
* credentials .json file retrieved from the Google Developers
* Console.
* @type array $keyFile The contents of the service account credentials
* .json file retrieved from the Google Developers Console.
* @type string $projectId The project ID created in the Google
* Developers Console.
* }
* @return null
*/
public function __construct(array $config = [])
{
} |
This looks great! Although it may need to be where the psr is concerned, I'm not a fan of the introduction of the term |
I'm wondering if that's a typo in the example, according to this you would only use that notation when you expect every element to be a string. The first element is boolean 😖. |
ok cool, I agree |
Closing this out as we're running with phpdocumentor2! |
* Reorganize namespaces and fix tests * # This is a combination of 9 commits. # This is the 1st commit message: Reorganize namespaces and fix tests Update component versions via the CLI # This is the commit message #2: Create tags in components # This is the commit message #3: Send component name and version in user agent # This is the commit message #4: Add README files # This is the commit message #5: Fix CLI # This is the commit message #6: Add split to travis # This is the commit message #7: Test datastore release # This is the commit message #8: Compile splitsh # This is the commit message #9: Reintroduce full split process * # This is a combination of 2 commits. # This is the 1st commit message: Reorganize namespaces and fix tests Update component versions via the CLI Create tags in components Send component name and version in user agent Add README files Fix CLI Add split to travis Test datastore release Compile splitsh Reintroduce full split process Release patches # This is the commit message #2: Run split in each build matrix * Reorganize namespaces and fix tests Update component versions via the CLI Create tags in components Send component name and version in user agent Add README files Fix CLI Add split to travis Test datastore release Compile splitsh Reintroduce full split process Release patches Run split in each build matrix Release datastore patch enable set -e * Work with github API directly * Fix Vision class reference * Create VERSION file for all components * Remove componentName * Fix int64 snippet tests * Update component release target * Parse documentation separately for each component * This works now * Add flag to docs to use JSON_PRETTY_PRINT for debugging * Parse correct links between components * Fix unit tests * Doc links within component should not change version * Cross-component links should go to the correct version docs * Update snippets to remove refs to ServiceBuilder * Remove unnecessary env vars * Don't write VERSION for parent * Release packages * release v0.24.1 * Add autoloaders to each component * Pass libVersion to gax config * Update push docs command * add gcsUri helper * allow gcsUri or storage object * Release 0.24.2 * Update things again * this is the worst * Link to upstream tag * tag * Update table of contents * Reset versions * Update suggests and requires * fix build docs trigger * dont throw exceptions on decode * Fix docs link * Fix various doc issues * fix namespace
Find a standard library to write docs alongside the code, similar to JSDocs.
The text was updated successfully, but these errors were encountered: