Pythonのコメント：Pythonのソースコード内のコメントを入れて、「標準」の方法については＃対文字列

Question

：

def func(): 
    "Func doc" 
    ... <code> 
    'TODO: fix this' 
    #badFunc() 
    ... <more code> 

def func(): 
    "Func doc" 
    ... <code> 
    #TODO: fix this 
    #badFunc() 
    ... <more code> 

私が代わりに＃の年代を接頭辞の文字列として一般的なコメントを書くことを好みます。 公式のPythonスタイルのガイドでは、文字列をコメントとして使用することについて言及していません（私がそれを読んでいる間にそれを見逃さなかった場合）。

私はそれが主に私が#という文字がコメントブロックで醜いと思うので、そんなことが好きです。私が知る限り、これらの文字列は何もしません。

これにはいくつかの欠点がありますか？

Answer 1

文字列（操作なしの文）をコメントとして誤用しないでください。 Docstrings（例：モジュール、クラス、または関数の最初の文字列は特別であり、絶対に推奨されます。

docstringsはドキュメントであり、ドキュメントとコメントは2つの異なることに注意してください。

• ドキュメントは、の意味は何ですか、のコードはそうです。
• コメントの説明どのようにコードがそれを行います。

ドキュメントが使用あなたのコードの人々によって読まれ、したい人のコメントには、例えば、あなたのコードを理解しますそれを維持するために。これは、文字列が何もしないことを知らない人が混乱

• ：コメント用の文字列を使用して

  は、以下の（潜在的な）欠点があります。

• コメントと文字列リテラルは、コードエディタでは異なる方法で強調表示されるため、スタイルによってコードを読みにくくすることがあります。それは、次のとおりです。
• それは、パフォーマンスおよび/またはメモリ使用量に影響を与える可能性がある
が が

は、Pythonプログラマのための最も重要な

（文字列はバイトコードのコンパイル時に除去されていない場合は、コメントを削除するには、その決定的安いので、スキャナレベルで行われます） pythonicでない：

それを行うには1つ、好ましくは1つの方法が必要です。

コメントを使用してください。

Answer 2

定義（またはクラス）の最初の文字列リテラルのみが「特別」であると考えられます。つまり、インタプリタによって定義されたオブジェクト（またはクラス）docstringに格納されます。

あなたがコードに入れる他の文字列リテラルは、最悪の場合、実行時に文字列値を構築してから、それを放棄することを意味します。これは、コードを文字列定数で捨てることによって "コメント"を行うことは、パフォーマンス面でコストがかかることを意味します。

もちろん、私はこれをベンチマークしていないし、Pythonインタプリタもよく分からない。

Answer 3

不利な点は、誰かがそれを読んでいると、コード文字列とコメント文字列がインターリーブされていることがわかります。混乱する可能性があります。