-
-
Notifications
You must be signed in to change notification settings - Fork 388
Document the preferred Phobos documentation style #2129
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -395,6 +395,38 @@ class MyClass | |
| ------------------------------- | ||
| ) | ||
|
|
||
| $(LISTSECTION phobos_documentation, Documentation, | ||
| $(LI Every public symbol be exposed on the documentation:) | ||
| --- | ||
| /// A public symbol | ||
| enum myFancyConstant; | ||
| --- | ||
| $(LI Every public function should have a Ddoc description and documented | ||
| `Params:` and `Returns:` sections (if applicable):) | ||
| --- | ||
| /** | ||
| Checks whether a number is positive. | ||
| `0` isn't considered as positive number. | ||
|
|
||
| Params: | ||
| number = number to be checked | ||
|
|
||
| Returns: `true` if the number is positive, `0` otherwise. | ||
|
|
||
| See_Also: $(LREF isNegative) | ||
| */ | ||
| bool isPositive(int number) | ||
| { | ||
| return number > 0; | ||
| } | ||
| --- | ||
| $(LI Text in sections (e.g. `Params:`, `Returns:`, `See_Also`) should be indented by one level if spans more than the line of the section.) | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I explicitly wanted to allow this: As it's a lot more concise than:
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ... if it spans ... |
||
| $(LI Documentation comments should not use more than two stars `/**` in the header line.) | ||
| $(LI Block comments (`/**`) should be used - not nesting block comments (`/++`)) | ||
| $(LI Global functions shouldn't indent their documentation block nor use stars as indentation.) | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is probably the most controversial bit. /**
Capitalize the first character of $(D s) and convert the rest of $(D s) to
lowercase.
Params:
input = The string to _capitalize.
Returns:
The capitalized string.
See_Also:
$(REF asCapitalized, std,uni) for a lazy range version that doesn't allocate memory
*/vs. /**
* Capitalize the first character of $(D s) and convert the rest of $(D s) to
* lowercase.
*
* Params:
* input = The string to _capitalize.
*
* Returns:
* The capitalized string.
*
* See_Also:
* $(REF asCapitalized, std,uni) for a lazy range version that doesn't allocate memory
*/While I can understand that the latter is used for symbols in structs, classes etc., I generally don't like the extra work and noise added by the stars.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we're going to require
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. AFAIK, the vast majority of ddocs in Phobos use Plus, I don't think
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Both styles are used heavily in Phobos, so if we want to normalize the docs, we'd be changing a ton of code either way. I'd be fine with not requiring one over the other, but I see zero advantage to
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. both are good stars are preferred
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If both are considered okay, then we shouldn't require one or the other in the style guide but should just state that we don't want leading stars or pluses on each line. On a related note, I don't know why we'd want to not indent the documentation. I believe that most of the existing ddoc comments are indented, though fortunately, most don't use the leading stars.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
| $(LI Text example blocks should use three dashes (`---`) only.) | ||
| ) | ||
|
|
||
| $(BR) | ||
| $(P | ||
| We are not necessarily recommending that all code follow these rules. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: Every public symbol should be exposed in the documentation: