표준 파이썬 docstring 형식은 무엇입니까? [닫은]


887

파이썬에서 docstring을 작성하는 몇 가지 다른 스타일을 보았습니다. 공식 또는 "합의 된"스타일이 있습니까?


6
python.org/dev/peps/pep-0008 문서 문자열에 전념 전체 섹션있다
mechanical_meat

30
나는 PEP-257 및 PEP-8은 문서화 문자열에 대해서만 기반을 구축하고 있기 때문에이 질문은 분명 충분하지라고 생각하지만, 방법에 대한 epydoc, doxygen, sphinx? 누구든지 통계를 가지고 있습니까? 이러한 옵션이 너무 많은 경우 상처를 줄 수있는 경우 다른 통계를 대체 할 것입니다.
sorin

1
@sorin, 나는 또한 어떤 마크 업이 가장 보편적인지 알고 싶습니다. 그러나 그 대답은 그다지 보편적 인 것이 없다는 것입니다. 사람들은 html로 변환하지 않고 Python 소스를 직접 보는 것을 선호합니다. 따라서 일관성은 있지만 사람의 가독성에 최적화 된 방식으로 명시적인 마크 업이없는 것이 가장 유용합니다.
poolie

3
PyCharm은 다소 흥미로운 방식으로 자동 완성되며,이를 실행하는 데 필요한 지침을 def foo(self, other):\n\t"""\n\t(blank line)\n\t:param other: \n\t:return:\n\t"""
훌륭하게

1
다음 중 VS 코드 설명서 파서에서 기본적으로 작동하는 답변은 무엇입니까?
William Entriken '11

답변:


1019

체재

파이썬 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 에서 사용하는 reST ( reStructuredText ) 형식입니다 . 참고 : 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에는 자주 사용되는 자체 형식 이 있습니다. 또한 스핑크스 (예 : 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.
"""

심지어 더 많은 예제

-누 피독

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
reST가 JetBrains PyCharm에서 기본적으로 사용되는 것을 추가 할 수 있습니다. 메소드를 정의한 후 삼중 따옴표를 입력하고 Enter 키를 누르십시오. jetbrains.com/pycharm/help/creating-documentation-comments.html
Felipe Almeida

12
가장 포괄적 인 답변에는 역사 감각과 현재 모범 사례가 포함됩니다. 이제 우리에게 필요한 것은 새로운 "최상의"형식에 대한 공동체 운동의 감각과 다른 모든 도구에서 새로운 도구로 마이그레이션 도구를 만드는 데 대한 추가적인 공동체 노력으로, 실제로 모범 사례를 발전시킬 수 있습니다.
BobHy

2
yo @daouzli, Google 스타일 링크는 404 입니다. 이것이 옳다는 것을 믿습니다 . 스핑크스 Google 스타일 예제 도 추가 할 수 있습니다 . 큰 대답 btw. 편집 : 귀하의 답변을 직접 편집했습니다.
voy

4
좋은 대답입니다. PyCharm (JetBrains) : Settings-> Tools-> Python Integrated Tools-> Docstring format에서 기본 docstring 형식을 변경할 수있는 곳을 감히 말하고 있습니다. 행운을 빕니다!
Jackssn

4
나는 첫 번째 텍스트 줄에 대해 아무도 언급하지 않았습니다. 현재 엄격하게 말하고 있지만 선호하는 방법은 첫 번째 줄에 삼중 따옴표 바로 뒤에 놓는 것 같습니다. PEP 8 및 PEP 257은 거의 모든 예에서이를 수행합니다. PEP 287은 귀하의 방식으로 수행하지만 내 경험상 그렇게 일반적이지 않습니다.
Lapinot

323

구글 스타일 가이드는 훌륭한 파이썬 스타일 가이드가 포함되어 있습니다. 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+의 경우 함수 주석 이 훨씬 깔끔한 방법입니다. pseudo-strong-types를 사용하면 더 나빠집니다 .Python은 오리 타이핑에 훨씬 좋습니다.
Evpok 2016 년

27
그래,하지만 최소한 어떤 오리가 기대되는지에 대한 힌트를 제공하고 대부분의 개발자들은 아직 파이썬 3에 있지 않다
Anentropic

3
@Evpok 개인적으로는 함수 주석이 마음에 들지 않습니다. 클래스를 사용하려면 불필요한 가져 오기를 수행해야하고, 문자열을 사용하려면 가로 공간이 부족하여 빠르게 설명 할 수 있습니다. 지금까지 나는 아무것도 사용하지 않는 것을 보지 못했습니다.
OdraEncoded

5
@Nathan의 Google 스타일 가이드는 "대표에서 행 가져 오기"보다 "대표에서 행 가져 오기"와 같이 선언적이 아니라 설명적인 주석을 권장합니다. 따라서 "Calculate ..."을 "Calculates ..."로 변경하면 예가 "Returns"및 "Raises"와 같은 나머지 주석과보다 일관되게됩니다.
gwg

2
nit : Google 스타일에 따라 명령형보다는 설명적인 형식을 사용하십시오 (예 : "Calculates ..."및 "Adds ..."
sbeliakov

228

문서 문자열 규칙은 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

그리고 더 긴 docstring에서 첫 줄에 주석을 남기는 경향이 있습니다.

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

의미 나는 이렇게 시작되는 docstrings가 지저분하다는 것을 알았습니다.

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

90
PEP-8은 구체적으로 docstring이 설명이 아닌 명령 / 명령으로 작성되어야한다고 명시하고 있습니다. """Return the squared result"""오히려 """Returns the squared result""". 개인적으로, PEP의 말에도 불구하고 팀이 어떻게 지 냈는지 내 글을 씁니다.
캠 잭슨

63
나는 또한 하나의 문장보다 길면 어색하게 들리기 때문에 그 명령에 동의하지 않습니다 (명령형 시제 사용). 또한 독자에게 무엇을 해야할지 말하지 않고 함수를 설명 하고 있습니다.
mk12

14
참고 : 서술 적 문서화 문자열이 아닌 규범 적 지정은 실제로 PEP-8이 아니라 PEP- 257에 나타납니다 . 필자는 함수를 설명하는 Java의 전통에서 왔지만 프로그래밍 패러다임이 객체 지향에서 절차로 전환 될 때 명령형 시제를 사용하기 시작했습니다. 그리고 pycco 를 사용하여 문맹 프로그래밍 스타일의 문서를 생성 하기 시작했을 때 왜 명령형 시제가 제안되었는지가 매우 분명해졌습니다. 패러다임에 따라 선택해야합니다.
karan.dodia 2016 년

25
명령형은 문법적 분위기 입니다. (죄송합니다.)
Denis Drescher

5
@ Mk12 Git 커밋 메시지는 설명 대신 명령으로 작성해야합니다. 또한 " 코드 변경 사항을"독자에게 무엇을 지시하지 않는지 " 설명 하고 있습니다. 설명을 명령으로 작성하는 것이 단지 관습이라고 생각합니다.
원피스

58

아무 것도 언급하지 않았 으므로 Numpy Docstring Standard를 사용할 수도 있습니다 . 과학계에서 널리 사용됩니다.

@Nathan의 답변으로 권장되는 Google 스타일 docstring을 구문 분석하기위한 Napolean 스핑크스 확장은 Numpy 스타일 docstring을 지원하며 두 가지를 짧게 비교 합니다.

마지막 예제는 다음과 같습니다.

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 은 공식적인 파이썬 코딩 표준입니다. 여기에는 docstring에 대한 섹션이 포함되어 있으며, 이는 docstring에 대한 완전한 사양 인 PEP-257 을 나타냅니다 .


8
"매개 변수, 반환 값, 예외 발생 등을 올바르게 문서화해야하는 방법"이라는 맥락에서 PEP-257을 언급하는 것은 농담입니다. 코드 예제에는 일부가 표시되어 있지만 말이 아닙니다. 가독성과 기능면에서 IMHO Google 형식을 선택하는 것이 좋습니다.
Semanino

9

파이썬입니다. 무슨 일이든 상관 없습니다 . 문서게시 하는 방법을 고려하십시오 . 소스 코드를 읽는 사람을 제외하고는 문서 스트링이 보이지 않습니다.

사람들은 웹에서 문서를 탐색하고 검색하는 것을 정말로 좋아합니다. 이를 위해서는 문서 도구 Sphinx를 사용하십시오 . 파이썬 프로젝트를 문서화하기위한 사실상의 표준입니다. 제품은 아름답습니다-https: //python-guide.readthedocs.org/en/latest/를보십시오 . Read the Docs 웹 사이트에서 문서를 무료로 호스팅합니다.


22
나는 일상적으로 ipython라이브러리를 테스트 구동하는 데 사용 하며, docstring을 읽는 것이 간단 your_module.some_method_im_curious_about?합니다.
Thanatos

8
a의 사용자 라이브러리 또는의 API 또는 누가 작성하는 플러그인은 모든 코드와 그것의 감각을 만들 필요가 볼 가능성이 높다. 유형이 선언되지 않았기 때문에 Java 또는 C #보다 Python에서 주석이 훨씬 중요하다는 것을 알았습니다. 의견이 대략 어떤 종류의 오리가 전달되고 반환되는지에 대한 아이디어를 제공하면 많은 도움이됩니다. (그렇지 않으면 실제로 모든 코드를 걸어서 주어진 매개 변수가 ... 여기서 반복 가능해야합니다 ... 여기서 색인 생성 지원 ... 끝에서 숫자 빼기 지원 ... 아하! 기본적으로 int array. 댓글이 도움이 될 것입니다!)
Jon Coombs

아뇨 문서화 문자열은 하지 보이지 않는 그 지점의 약간이다. help문서화 된 function / method / class 에서 함수 를 실행 하면 컴파일 된 모듈에만 액세스 할 수있는 경우에도 docstring을 볼 수 있습니다. 개인적으로 나는 docstring 규칙을 선택할 때 이것을 명심해야한다고 생각합니다 (즉, 그대로 읽도록 의도되어 있음).
skyking

7

Vladimir Keleshev의 pep257 Python 프로그램을 사용하여 매개 변수, 반환 등을 설명하기 위해 PEP-257Numpy Docstring Standard 와 비교하여 문서 문자열을 확인 하는 것이 좋습니다 .

pep257은 표준에서 발산되는 차이를보고하며 pylint 및 pep8과 같습니다.


"매개 변수, 반환 값, 예외 발생 등을 올바르게 문서화해야하는 방법"이라는 맥락에서 PEP-257을 언급하는 것은 농담입니다. 코드 예제에는 일부가 표시되어 있지만 말이 아닙니다. NumPy 형식 IMHO는 와이드 스크린 모니터에는 거의없는 수직 공간을 너무 많이 사용합니다 (90도 회전 한 것을 사용하지만 대부분의 사람들은 그렇지 않은 것 같습니다). 따라서 IMHO Google 형식은 가독성과 기능면에서 좋은 선택입니다.
Semanino

1
@Semanino PEP-257이 아닌 pep257 프로그램의 맥락에서 Numpy Docstring Standard를 언급하고 있습니다. 이 프로그램은 이제 pydocstyle이라고합니다. pydocstyle을 사용하면 pydocstyle --select=D4 tmp.py섹션 이름 지정을 포함한 다양한 docstring 내용 문제를 확인하는 등 몇 가지 numpydoc 확인을 수행 할 수 있습니다 .
핀 아룹 닐슨
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.