Rust: ドキュメントコメントスタイルガイドを作成する

作成日 2013年01月05日  ·  17コメント  ·  ソース: rust-lang/rust

1.0リリースの前に多くのライブラリコードが変更されると予想されるため、今これを行うことはあまり意味がありませんが、コアライブラリとstdライブラリはAPIドキュメントに一貫したスタイルを使用する必要があります。 ウィキは規則を指定しようとし

現在、いくつかのドキュメントコメントは第三者の指示で書かれています:

pub fn map<T, U>(opt: &Option<T>, f: fn(x: &T) -> U) -> Option<U> {
    //! Maps a `some` value by reference from one type to another

そしていくつかは命令で書かれています:

pub fn chain<T, U>(opt: Option<T>,
                   f: fn(t: T) -> Option<U>) -> Option<U> {
    /*!
     * Update an optional value by optionally running its content through a
     * function that returns an option.
     */

これらの2つの例は、別の矛盾を示しています。一部の要約(コメントの最初の行)には終止符がありませんが、他の要約はピリオドで終わります。

異なるもう1つのことは、コメントスタイル自体です。 一部のドキュメントコメントは次のようになります

/*!
 * foo...
 * bar...
 * baz...
 */

他の人はのように見えますが

/*!
 foo...
 bar...
 baz...
 */

これらのルール(およびその他のルール)が体系化されたら、ドキュメントのコメントを確認して更新を開始できれば幸いです。

P-low

最も参考になるコメント

記述的なスタイル:

命令型:

全てのコメント17件

:+1:これを議論するため。 私はドキュメントを寄稿したいのですが、それが終わった後、あなたのためにこれ以上の仕事をしたくありません。 ;)

比較のために、標準のPythonスタイルは、命令型の「Returnthe…」を使用することです。これはうまく機能すると思います。

http://www.python.org/dev/peps/pep-0257/#one -line-docstrings

Goは、命令型ではないスタイルに落ち着きました: http

トリアージのための訪問。

個人的には、命令動詞と最後のピリオドが好きです。 ドキュメントのコメントスタイルに関しては、少なくとも言語がそれを行うための複数の方法を定義している間は、特定の方法を別の方法に強制するべきではないと思います。 また、私の好みの方法は

/**
 * doc string
 */

私も命令を好みます。 スタイルには、型と引数を参照するための統一された構文も含める必要があるため、 rustdocはそれらに適切に注釈を付けたりハイパーリンクしたりできます。 しかし、それは道のりです

トリアージのための訪問。 私はこれについてほとんど意見がありません。

記述的なスタイル:

命令型:

メソッド定義は次のように指示するまで何もしないので、私は記述バージョンを自分で好みます。

class Machine
{
    // Self-destructs the machine, if necessary.
    void self_destruct();
};

// Self-destruct!
if ( emergency )
  machine.self_destruct();

私はkud1ingの議論に敏感です。 さらに、ドキュメントに示されている方法で行を読み上げると、次のようになります。

ゼロ加法単位元0を返します。

次に、宣言型はそれを実際の文"zero" returns the additive identity, 0.ます。

@Armavica :これは実際にはThe method "zero" returns the additive identity, 0短縮形です。

文書化とインターフェースは、聴衆に何かを提示しています。 実装で何が/どのように/なぜ起こっているのかを説明するときは、命令形の方が理にかなっていると思います。

ドキュメントの例のスタイルについては、 https://github.com/mozilla/rust/issues/9403もあります。

P-low。

ここでのコメントから、記述型(「バイトを文字列に変換する」など)は命令型(「バイトを文字列に変換する」)よりも人気があるようです。 どちらに行くかはあまり気にしませんが、正式に決定しておくといいでしょう。

これを命令型と呼ぶのは間違っていると思います。 誰かに何かをするように指示していないので、それは必須ではありません。 一人称プレゼントだと思います。 書きたいという衝動があるのではないかと思います

/// Frob the twaddle.
fn frob() {}

「私は機能です。私は何をしますか?」という考え方に由来するので、それは一人称の現在形を示しています。

ただし、ドキュメントを読むとき、ほとんどの読者は当然、機能を一人称の主題ではなく、三人称の単数の主題として扱います。 そのためには、ドキュメントは一人称ではなく三人称単数で書く必要があります。


これを一人称現在形ではなく命令型と見なすために私が見ることができる唯一の合理的な議論は、docstringがユーザーが実装することが期待される関数宣言を記述している場合です。 これはオブジェクト指向言語では非常に一般的ですが、Rustではトレイトメソッドにのみ適用されます。 このケースは、メソッドを正しく実装するために何をしなければならないかを示しているため、命令の使用を示唆しています。

しかし、私はこの議論が説得力があるとは考えていません。 ドキュメントの主な使用例は、APIの実装方法ではなく、APIの使用方法を読者に伝えることです。 APIの使用数は、実装の数を大幅に上回っています(最も難解な場合を除くすべての場合)。 したがって、特性法であっても、命令法を使用するよりも、第三者単数で現在形を使用する方が理にかなっていると思います。

対処すべきもう1つのこと:ハイフンまたはダッシュ:

https://en.wikipedia.org/wiki/Dash#Relationships_and_connections

これらの座標/関係/接続タイプの用語でハイフンの代わりにダッシュを優先することは、スタイルの優先事項の問題であり、固有の正書法の「正確さ」ではありません。 どちらも同じように「正しい」ものであり、一部のスタイルガイドではそれぞれが推奨されるスタイルです。

RFCを提出しました: https

このページは役に立ちましたか?
0 / 5 - 0 評価