Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions dstyle.dd
Original file line number Diff line number Diff line change
Expand Up @@ -395,6 +395,38 @@ class MyClass
-------------------------------
)

$(LISTSECTION phobos_documentation, Documentation,
$(LI Every public symbol be exposed on the documentation:)
Copy link
Contributor

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:

---
/// 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.)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I explicitly wanted to allow this:

Returns: The capitalized string.

As it's a lot more concise than:

Returns:
     The capitalized string.

Copy link
Contributor

Choose a reason for hiding this comment

The 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.)
Copy link
Contributor Author

@wilzbach wilzbach Jan 26, 2018

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

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

If we're going to require /++ +/ or /** */, can we please require /++ +/:

#2133

Copy link
Member

Choose a reason for hiding this comment

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

AFAIK, the vast majority of ddocs in Phobos use /** */. Changing that to /++ +/ is going to introduce huge amounts of churn converting from the former to the latter.

Plus, I don't think /++ +/ gives us very much advantage at all... the only time you'd want comments inside a ddoc is when there are code examples, and Phobos nowadays almost exclusively uses ddoc'd unittests where any comments are actual comments rather than comments embedded inside ddoc comments. Not to mention that comments in code examples tend to be brief (otherwise they really belong in the ddoc text rather than inside the example), so // would serve just as well.

Copy link
Member

Choose a reason for hiding this comment

The 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 /** */ if we're going to require one or the other.

Copy link
Member

Choose a reason for hiding this comment

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

both are good stars are preferred

Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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.
Expand Down