標準のPython docstring形式とは何ですか?[閉まっている]


888

Pythonでdocstringsを書くいくつかの異なるスタイルを見てきましたが、公式または「合意された」スタイルはありますか?


6
python.org/dev/peps/pep-0008ドキュメント文字列に特化したセクション全体があります
Mechanical_meat

30
私は、PEP-257とPEP-8は、ドキュメンテーション文字列のための唯一の基盤を確立しているので、この質問は明確では十分ではなかったと思いますが、どのようにについてepydocdoxygensphinx?あまりにも多くのオプションが害を及ぼす可能性がある場合、誰かが何らかの統計を持っていますか、それらの1つは他のものを置き換えるつもりです。
ソリン2011

1
@sorin、もしあれば、どのマークアップが最も一般的かについても知りたいです。しかし、答えは、それらのどれもそれほど一般的ではないということだと思います。人々は、htmlに変換するのではなく、Pythonソースを直接見ることを好む傾向があります。したがって、一貫性を保つことが最も有用ですが、人間が読みやすくするために最適化されており、明示的なマークアップはありません。
poolie 2012年

3
私が考えるかなり興味深い方法でPyCharmのオートコンプリートは、それを実行するのに必要な命令の素敵な実装です:def foo(self, other):\n\t"""\n\t(blank line)\n\t:param other: \n\t:return:\n\t"""
マッテオフェルラ

1
これらの回答のうち、VS Codeドキュメントパーサーでデフォルトで機能するのはどれですか。
William Entriken

回答:


1019

フォーマット

他の投稿が示したように、Python docstringはいくつかの形式に従って記述できます。ただし、デフォルトのSphinx docstring形式は言及されておらず、reStructuredText(reST)に基づいています。このブログ投稿では、主なフォーマットに関する情報を入手できます。

reSTはPEP 287で推奨されていることに注意してください。

docstringに使用される主な形式は次のとおりです。

-Epytext

歴史的には、javadocのようなスタイルが普及していたため、Epydoc(呼び出されたEpytext形式)がドキュメントを生成するためのベースと見なされていました。

例:

"""
This is a javadoc style.

@param param1: this is a first param
@param param2: this is a second param
@return: this is a description of what is returned
@raise keyError: raises an exception
"""

- 残り

今日、おそらくより一般的なフォーマットは、ドキュメントを生成するためにSphinxによって使用されるreStructuredText(reST)フォーマットです。注:これはJetBrains PyCharmでデフォルトで使用されます(メソッドを定義してEnterキーを押した後、三重引用符を入力します)。また、Pymentの出力フォーマットとしてデフォルトで使用されます。

例:

"""
This is a reST style.

:param param1: this is a first param
:param param2: this is a second param
:returns: this is a description of what is returned
:raises keyError: raises an exception
"""

-Google

Googleには、よく使用される独自の形式があります。Sphinxで解釈することもできます(つまり、Napoleonプラグインを使用)。

例:

"""
This is an example of Google style.

Args:
    param1: This is the first param.
    param2: This is a second param.

Returns:
    This is a description of what is returned.

Raises:
    KeyError: Raises an exception.
"""

さらに多くの例

-Numpydoc

Numpyは、Google形式に基づいており、Sphinxで使用できる独自のnumpydocに従うことをお勧めします。

"""
My numpydoc description of a kind
of very exhautive numpydoc format docstring.

Parameters
----------
first : array_like
    the 1st param name `first`
second :
    the 2nd param
third : {'value', 'other'}, optional
    the 3rd param, by default 'value'

Returns
-------
string
    a value in a string

Raises
------
KeyError
    when a key error
OtherError
    when an other error
"""

変換/生成

Pymentのようなツールを使用して、まだドキュメント化されていないPythonプロジェクトにドキュメント文字を自動的に生成したり、既存のドキュメント文字列(複数の形式が混在している可能性があります)を別の形式に変換したりできます。

注:例はPymentのドキュメントから引用しています


10
reBはJetBrains PyCharmでデフォルトで使用されるものであると付け加えるかもしれません。メソッドを定義した後、三重引用符を入力してEnterキーを押してください。jetbrains.com/pycharm/help/creating-documentation-comments.html
フェリペアルメイダ、

12
最も包括的な答えは、歴史の感覚と現在のベストプラクティスを含みます。今必要なのは、新しい「ベスト」フォーマットへのコミュニティの動きの感覚と、他のすべてから新しいものへの移行ツールの作成に向けたコミュニティの取り組みです。これにより、実際にベストプラクティスを進化させることができます。
BobHy 2016年

2
yo @ daouzli、Googleスタイルのリンクは404 です。これは正しいと思います。スフィンクスのグーグルスタイルの例も追加できます。素晴らしい答えです。編集:私は自分で回答を編集しました。
2016

4
いい答えです。PyCharm(JetBrains)でデフォルトのdocstring形式をどこで変更できるかをあえて言います:設定->ツール-> Python統合ツール-> Docstring形式。幸運を!
Jackssn 2017年

4
最初のテキスト行について誰もコメントしなかったことに驚いています。現在は厳密に言えば正しいですが、最初の行の三重引用符の直後に配置することをお勧めします。PEP 8とPEP 257は、ほとんどすべての例でそれを行っています。PEP 287はあなたのやり方でそれを行いますが、私の経験ではそれはそれほど一般的ではありません。
Lapinot

323

Googleのスタイルガイドは優れたPythonのスタイルガイドが含まれています。PEP-257よりも優れたガイダンスを提供する、読みやすいdocstring構文の規則が含まれています。例えば:

def square_root(n):
    """Calculate the square root of a number.

    Args:
        n: the number to get the square root of.
    Returns:
        the square root of n.
    Raises:
        TypeError: if n is not a number.
        ValueError: if n is negative.

    """
    pass

このSphinxドキュメントチュートリアルで説明されているように、これを拡張して引数に型情報を含めることも好きです。例えば:

def add_value(self, value):
    """Add a new value.

       Args:
           value (str): the value to add.
    """
    pass

37
「docstringsのシグネチャ」スタイルは、非常に冗長で冗長です。Python 3+の場合、関数アノテーションはこれを行うためのよりクリーンな方法です。疑似強力型を使用する場合はさらに悪いことです。Pythonはダック型を使用する方がはるかに優れています。
Evpok

27
ええ、でも、少なくともそれはどんな種類のアヒルが期待されているのかについてのヒントを与え、
開発者の

3
@Evpok個人的には、関数アノテーションは好きではありません。それらでクラスを使用するには、不必要なインポートを行う必要があるかもしれません。それらで文字列を使用するには、それらを非常に迅速に記述する水平スペースが不足する可能性があります。これまでのところ、それらを何にでも使用する意味は見ていません。
OdraEncoded

5
@ネイサン、Googleのスタイルガイドでは、「ビッグテーブルから行を取得する」よりも「ビッグテーブルから行を取得する」のように、宣言的ではなく説明的なコメントを推奨しています。したがって、「Calculate ...」を「Calculates ...」に変更すると、例がコメントの残りの部分、つまり「Returns」および「Raises」とより一貫したものになります。
gwg 2014年

2
nit:Googleスタイルに従い、命令的な形式ではなく説明的な形式を使用します。つまり、「計算...」と「追加...」
sbeliakov '22

228

Docstringの規則はPEP-257にあり、PEP-8よりもはるかに詳細です。

ただし、docstringは他のコード領域よりもはるかに個人的なようです。異なるプロジェクトには独自の標準があります。

docstringは常に含める傾向があります。これは、関数の使用方法とその機能が非常に迅速に示される傾向があるためです。

文字列の長さに関係なく、一貫性を保つことを好みます。インデントと間隔が一貫している場合の外観のコーディング方法が好きです。つまり、私は以下を使用します。

def sq(n):
    """
    Return the square of n. 
    """
    return n * n

以上:

def sq(n):
    """Returns the square of n."""
    return n * n

そして、より長いドキュメント文字列の最初の行にコメントを残す傾向があります:

def sq(n):
    """
    Return the square of n, accepting all numeric types:

    >>> sq(10)
    100

    >>> sq(10.434)
    108.86835599999999

    Raises a TypeError when input is invalid:

    >>> sq(4*'435')
    Traceback (most recent call last):
      ...
    TypeError: can't multiply sequence by non-int of type 'str'

    """
    return n*n

つまり、このように始まるdocstringが乱雑であることがわかります。

def sq(n):
    """Return the squared result. 
    ...

90
PEP-8では、docstringは説明ではなく、コマンド/命令として記述する必要があると明記されています。"""Return the squared result"""というより"""Returns the squared result"""。個人的には、PEPが言っているにもかかわらず、私はティムがここにいる方法を私に書いています。
Cam Jackson

63
また、1つの文よりも長いと不自然に聞こえるようになるので(命令型の時制を使用して)そのアドバイスに同意しません。さらに、あなたは読者に何をすべきかを告げるのではなく、関数を記述しています。
mk12

14
注:記述的ではなく規範的なdocstringの仕様は、実際にはPEP-8ではなくPEP- 257に表示されます。 私はJavaの伝統から来て、関数を記述していましたが、プログラミングパラダイムがオブジェクト指向から手続き型に切り替わったとき、ようやく命令形を使い始めました。そして、私がpyccoを使用して文芸的プログラミングスタイルのドキュメントを生成し始めたとき、なぜ命令時制が提案されたのかが非常に明らかになりました。あなたのパラダイムに基づいて選択する必要があります。
karan.dodia 2013年

26
必須は文法的な気分です。(申し訳ありません。)
Denis Drescher

5
@ Mk12 Git commitメッセージも、説明ではなくコマンドとして記述する必要があります。また、コードの変更を「説明」しているのであり、「読者に何をすべきかを伝えていない」のです。したがって、説明をコマンドとして記述するのは単なる慣習だと思います。
ワンピース2015

58

どうやら誰もそれについて言及していません:Numpy Docstring Standardを使用することもできます。科学界で広く使用されています。

Googleスタイルのドキュメント文字列(@Nathanの回答で推奨)を解析するためのNapoleanスフィンクス拡張機能は、Numpyスタイルのドキュメント文字列もサポートしており、両方の短い比較を行います。

そして最後に、それがどのように見えるかについてのアイデアを与えるための基本的な例:

def func(arg1, arg2):
    """Summary line.

    Extended description of function.

    Parameters
    ----------
    arg1 : int
        Description of arg1
    arg2 : str
        Description of arg2

    Returns
    -------
    bool
        Description of return value

    See Also
    --------
    otherfunc : some related other function

    Examples
    --------
    These are written in doctest format, and should illustrate how to
    use the function.

    >>> a=[1,2,3]
    >>> print [x + 3 for x in a]
    [4, 5, 6]
    """
    return True

2
NumPy形式のIMHOは垂直方向のスペースが大きすぎるため、ワイドスクリーンモニターでは不足しています(90度回転したものを使用する場合を除きますが、ほとんどの人は使用しないと思います)。したがって、IMHO Google形式は、読みやすさと機能の点で優れた選択肢です。
Semanino

3
やや主観的なものだと思います。より複雑なdocstring(セクションが異なる、例などがある)があると、フォーマットに関係なく、とにかく多くの垂直方向のスペースが必要になります。numpydocフォーマットは、読みやすく/構造化されています。
joris

2
個人的には、このように長いdocstringは、ソースコードではなくドキュメントに配置する方がよいと思います。非常に長いと、モジュールの可読性が妨げられます。
Jonathan Hartley、

12

PEP-8は公式のPythonコーディング標準です。Docstring の完全な仕様であるPEP-257を参照する、docstringに関するセクションが含まれています。


8
「パラメーター、戻り値、発生した例外などを適切に文書化する方法」の文脈でPEP-257に言及することは冗談です-それらについて一言も言わない(コード例はいくつかを示しています)。IMHO Google Formatは、読みやすさと機能に関して良い選択です。
Semanino 2018年

9

それはPythonです。何でも行くドキュメントの公開方法を検討してください。Docstringは、ソースコードの読者以外は表示されません。

人々はウェブ上でドキュメンテーションを閲覧したり検索したりするのが本当に好きです。そのためには、ドキュメントツールSphinxを使用します。これは、Pythonプロジェクトを文書化するための事実上の標準です。製品は美しいです-https://python-guide.readthedocs.org/en/latest/をご覧ください。ウェブサイトのRead the Docsは無料でドキュメントをホストします。


22
私は日常的にipythonライブラリをテストドライブしており、それによってdocstringの読み取りが非常に簡単your_module.some_method_im_curious_about?になりました。入力する必要があるのは、docstringを含め、すべての素晴らしい印刷結果が得られることです。
タナトス2013年

8
ライブラリまたはAPIのユーザー、またはプラグインを作成しているユーザーは、コードを見て、それを理解する必要があります。型が宣言されていないため、コメントはJavaやC#よりもPythonの方がはるかに重要です。コメントが大まかにどんな種類のアヒルが渡され、返されているかについてのアイデアを与えるなら、それは多くの助けになります。(それ以外の場合は、実際にすべてのコードを調べ、特定のパラメーターがここで反復可能でなければならないことを集計する必要があります...ここで反復可能です...あそこでインデックス作成をサポートしてください...最後に数値減算をサポートしてください...あは! int array。コメントが役に立った
Jon Coombs 2014年

ええ、違います。Docstringは見えないわけではありませんが、それは少し重要です。help文書化されたfunction / method / classで関数を実行すると、docstringが表示されます(コンパイルされたモジュールにのみアクセスできる場合でも実行できます)。個人的には、docstring規約を選択するときは、このことを覚えておく必要があると考えます(つまり、そのまま読むことを意図しています)。
skyking

7

Vladimir Keleshevのpep257 Pythonプログラムを使用して、ドキュメント文字列をPEP-257およびNumpy Docstring Standardに対してチェックし、パラメーターや戻り値などを説明することをお勧めします。

pep257は、標準からの相違を報告し、pylintおよびpep8のように呼び出されます。


「パラメーター、戻り値、発生した例外などを適切に文書化する方法」の文脈でPEP-257に言及することは冗談です-それらについて一言も言わない(コード例はいくつかを示しています)。NumPy形式のIMHOは垂直方向のスペースが大きすぎるため、ワイドスクリーンモニターでは不足しています(90度回転したものを使用する場合を除きますが、ほとんどの人は使用しないと思います)。したがって、IMHO Google形式は、読みやすさと機能の点で優れた選択肢です。
Semanino

1
@Semanino PEP-257ではなく、pep257プログラムのコンテキストでNumpy Docstring Standardについて言及しています。そのプログラムは現在pydocstyleと呼ばれています。pydocstyleを使用すると、いくつかのnumpydocチェックを実行できます。たとえば、pydocstyle --select=D4 tmp.pyセクションの命名など、ドキュメント文字列のコンテンツの問題をチェックできます。
FinnÅrupNielsen
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.