python - どの PEP 8 ガイドラインを無視し、どのガイドラインに固執しますか?

Question

何年にもわたって Python を書けば書くほど、ほとんどのガイドラインに同意するようになりましたが、私自身の理由で一貫して意図的に一部を破っています。

私は、PEP 8 (あるいは他の PEP もそうかもしれません) で、人々が宗教的に固執するものとその理由、そして人々が不便または不十分だと思うものを知りたいと思っています。

私の場合 (そして一般的に職場で)、逸脱しているものはほんの一握りです。

• アンダースコアで区切られた小文字の名前は、間違いなく一貫しているため、その要点は理解できますが、時折いくつかの不一致が発生する場合でも、lowerCamelCase を使用する傾向があります (部分的または誤った大文字の頭字語や次の単語など)。多くの場合、その場しのぎの呼び出しまで)。ほとんどの場合、私たちが日常的に使用するほぼすべての API がキャメルケース (一部は上位、一部は下位) を使用しており、何らかの理由で読みやすく、アンダースコアを分離トークンまたは規定のマングリング/不明瞭化として予約する傾向があるためです。

• 私はまだ、PEP がオブジェクトの内部で規定している方法で物事を配置することができません。new と init クラスの同じ範囲の機能に貢献するメソッド (init、get、set など) をクラス名と引数と共にすぐに読みたいので、空白行を入れずにクラスのすぐ下に残す傾向があります。同じ属性または一連の属性の）私は単一のスペースだけ離れており、クラス間の3つのスペースとメソッド間の2つのスペースが好きで、そのオブジェクトのマップに精神的に集約しません。これも、純粋にコードの視覚的な影響と読みやすさのためです。フロー制御内の非常にコンパクトなコンテンツと、メソッドとオブジェクト間のこの種の間隔により、コードが保留されてから数か月後に再読み取りすると、一貫して目的の場所に正確に目を向けることができます。

• 代わりに、別の方法で書かれたものを読むと頭がおかしくなるのは、スペースではなくタブです（特に、使用するアプリ内エディターの一部にタブ置換機能が実際にはなく、コードベースの汚染に大きく貢献している場合）試作段階）。

• インポートなどの順序、インポート内容、グローバルなど。インポートが大量にあるファイルが混同されていたり、順序が間違っていたりすると、本当に気が遠くなります。

• ステートメント内の空白、特に人々がタブを使用し、変数名の長さが異なる行にまたがって代入操作を整列させようとする場合 (そして、Excel のように見えるコードがきちんとしていないことをそれを行う人に納得させる方法はないようです ;) ) .

• また、制御ブロック内の間隔、特に同じフロー制御ブロック内で明らかにランダムな間隔が表示され、メソッドのオブジェクト内で同様の量の間隔が使用されていることがわかります。いまいましいものを読み始める前に、それらを編集せざるを得ません。

つまり、これらは私のものであり、私の PEP の「違反」の背後にある理由です (共有されたものもあれば、同僚に眉をひそめられたものもあります)。他のPythonistasがそれらの点で何をして何をしていないかを読むことに非常に興味があります.

Answer 1

「1行あたり79文字」の部分はナンセンスです。彼ら自身の例は、これを行うとコードが読めなくなることを示しています。

class Rectangle(Blob):

    def __init__(self, width, height,
                 color='black', emphasis=None, highlight=0):
        if width == 0 and height == 0 and \
           color == 'red' and emphasis == 'strong' or \
           highlight > 100:
            raise ValueError("sorry, you lose")
        if width == 0 and height == 0 and (color == 'red' or
                                           emphasis is None):
            raise ValueError("I don't think so -- values are %s, %s" %
                             (width, height))
        Blob.__init__(self, width, height,
                      color, emphasis, highlight)

このように書かれたニュース記事
を読もうとしているようなものです。

80 列の端末は、10 年以上本格的な開発環境ではありませんでした。ピンチで不自由な 80x25 環境から編集する必要がある場合、エディターのラッピングは少し不便です。それを避けるためだけに、通常の開発中にコードを台無しにするつもりはありません。

120 列の折り返しは、現代の開発にとって完全に賢明であり、私は 140 で何の問題もありません。

Answer 2

PEP8 は、「代入 (または他の) 演算子の周りに複数のスペースを入れて、別の演算子と揃える」ことを避け、数学演算子の周りに「複数のスペースを使用しない」ように言っていますが、私はこれに従いません。

隣接する行が関連している、または非常に似ているが、まったく同じではない場合、「余分な空白」を追加することがよくあります。

search_start = (f - f_1/3) * n/fs
search_stop  = (f + f_1/3) * n/fs

 

b_lpf, a_lpf = filter(N, 2*pi*fc, 'low',  analog=True)
b_hpf, a_hpf = filter(N, 2*pi*fc, 'high', analog=True)

 

p[x >  1] =                         np.cosh(order * np.arccosh( x[x >  1]))
p[x < -1] = (1 - 2 * (order % 2)) * np.cosh(order * np.arccosh(-x[x < -1]))

 

b0 =  (1 + cos(w0))/2
b1 = -(1 + cos(w0))

---

同様に、ライブラリ自体によって通常フォーマットされている読み取り可能な方法でフォーマットされた数値の配列に対して、コード スタイルの警告が表示されるのは面倒です。

a = array([[-0.198,  0.248, -1.17 , -0.629,  1.378],
           [-1.315,  0.947, -0.736, -1.388,  0.389],
           [ 0.241, -0.98 ,  0.535,  0.951,  1.143],
           [-0.601,  1.286, -0.947,  0.037, -0.864],
           [ 0.178, -0.289, -1.037, -1.453, -0.369]])

これにより、一連の E201 E202 E222 違反が発生します。

PEP8 では、可読性が向上したとしても、コンマの前またはブラケットの後に余分な空白を入れることはできないため、明らかに次のようにフォーマットすることをお勧めします。

a = array([[-0.198, 0.248, -1.17, -0.629, 1.378],
           [-1.315, 0.947, -0.736, -1.388, 0.389],
           [0.241, -0.98, 0.535, 0.951, 1.143],
           [-0.601, 1.286, -0.947, 0.037, -0.864],
           [0.178, -0.289, -1.037, -1.453, -0.369]])

Answer 3

PEP8は言う

最も重要なことに、複数行のdocstringを終了する「」は、それ自体が1行にあり、できれば空白行が前に付いている必要があります。例：

"""Return a foobang

Optional plotz says to frobnicate the bizbaz first.

"""

これは単なる「余分な空白」であり、明確な理由がないため、開始引用符を終了引用符とは異なる方法で処理するため、これはかなり奇妙だと思います。

理論的根拠はPEP257にあります：

BDFLは、複数行のdocstringの最後の段落とその終了引用符の間に空白行を挿入し、それ自体で1行に終了引用符を配置することをお勧めします。このようにして、Emacsのfill-paragraphコマンドを使用できます。

Emacs、本当に？特定の編集ツールの特定のコマンドの特異性に対応するために、誰もが奇妙なことをする必要がありますか？

また、終了引用符は独自の行にあると主張しながら、引用符と同じ行にdocstringの先頭を置くのは奇妙だと思います（必須ではありませんが、推奨されます）。これはより論理的であり、単一行と複数行の両方のdocstringに使用する必要があると思います。

def foobang(bizbaz, plotz=None):
    """
    Return a foobang

    Optional plotz says to frobnicate the bizbaz first.
    """

    if plotz is not None:
        ...

更新：太字の部分が削除され、「終了引用符を1行に配置する」とだけ表示され、「要約行は開始引用符と同じ行または次の行にある可能性があります」と表示されます。

Answer 4

標準は重要であり、PEP8は私が主張する非常に優れたスタイルガイドです。私が同意しない唯一のガイドラインは、数学演算子の周りの間隔です。たとえば、PEP8は次の間隔を要求します

Without PEP8                           With PEP8                
---------------------------------------------------------------- 
y = sqrt(x**2 + y**2)                  y = sqrt(x ** 2 + y ** 2) 
a*x**3 + b*x**2 + c*x + d              a * x ** 3 + b * x ** 2 + c * x + d 
10**(a*x + b)                          10 ** (a * x + b)  
F = V/(sqrt(g*h) + epsilon)            F = V / (sqrt(g * h) + epsilon) 
a*cos(nx/pi) + b*sin(nx/pi)            a * cos(nx / pi) + b * sin(nx / pi) 

私は適合しようとしていますが、これは私が苦労している1つの領域です。他の誰かも、PEP8の間隔が数学を読みにくくしていると感じていますか？

アップデート：

PEP8は、右側のフォーマットを推奨しない一方で、左側のフォーマットを推奨するように修正されました。

はい：

i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

いいえ：

i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

Answer 5

私はこれに同意しません:

- Imports should usually be on separate lines, e.g.:

    Yes: import os
         import sys

    No:  import sys, os

私はいつも単純なインポートを一緒に書いています。それらをすべて別々の行に書くことに利点はありません。それは、各ソースファイルの先頭に肥大化を追加し、簡潔で入力しやすいものをボーダーラインボイラープレートに変えるだけです。非常に冗長で、他のファイルからコピーして貼り付けたくなるようなものです。

これはすぐに読みやすく、理解できます。

import sys, os, time, gc, inspect, math, doctest

短く、スキミングしやすく、追加も簡単です。もちろん、1 行に多くのステートメントがある場合、またはインポートimportが必要な場合は、複数のステートメントを使用します。from

また、私は通常、標準ライブラリのインポートを自分のモジュールや他のライブラリのインポートとは別にしています。これは、PEP8 が推奨するグループ化の概念に同意しています。

Answer 6

私の「違反を認める」は「if」に関するものです

PEP8 では、1 行に複数のステートメントはないと述べているため、これを行う必要がある場合は次のようになります。

if cond:
    actions
    ...

しかし、アクションが 1 つしかない場合は、すべてを 1 行にまとめることを好みます。

if a == 0: b = 0

よりも：

if a == 0:
     b = 0

Answer 7

複数行の条件など: PEP-8では、二項演算子の前ではなく後でブレークするよう明示的に指示されています。その魅力が見えないのではないかと心配しています。条件文の前で改行する方がはるかに理にかなっているので、折り返し/継続行では、各サブ行が条件文で始まります。

if (condition1 \
        or condition2 \
        or condition3):
    do_something()

ご覧のとおり、下のブロックから視覚的にオフセットされるように、サブラインに余分なインデントを追加するのも好きです。PEP-8 はこれについて明示的なことは何も述べていませんが (そうですか?)、例には左括弧に沿ってサブ行が並んでいます。

Answer 8

PEP 8 の「問題」は、ほとんどのプログラマーにとって非常に大きな感情にさらされる個人的な好みの領域を踏みにじることです。

個人的には、キャメルケースとアンダースコア、および列配置ディレクティブは常に問題でした。ここで他の多くの応答にもポイントがあり、その特定のケースでは単に「理にかなっている」ため、意図的に PEP 8 を壊すことがあります。

Python プログラミングのキャリアの中で、単純にあきらめて PEP 8 に (使用する) ようになったポイントがありました。ほとんどの項目で比較的簡単だったので、現在でも残っている唯一の大きな問題は列の配置です。それは従うにはあまりにも乱雑です（とにかく嫌なことをしますが）。とにかく、私の「あきらめ」の結果として、私のコードは同僚にとってはるかに読みやすくなりました-そして-驚くべきことに、私にとっても(列の配置を除いて:p)。

また、PEP 8 が Python 自体に対して行ったことも認識しなければなりません。2.x (非準拠) と 3.x (準拠) の間では、特定の関数の名前がどうなるかを「常に知る」方がはるかに簡単です。Python の「バッテリー」は、より適切にソートされるようになりました。

Answer 9

PEP 8 は次のように述べています。

はい：

x = 1
y = 2
long_variable = 3

いいえ：

x             = 1
y             = 2
long_variable = 3

私は通常それに従いますが、読みやすくするために別のバリアントを使用することがあります。

x =             1
y =             2
long_variable = 3

Answer 10

私は常に 4 つのスペースを使用します。1 行あたり最大 79 文字を使用しようとしますが、いつかは不可能です。過去に「import sys、os」などのインポートも使用しました。一般的に、私は PEP 8 に固執しようとします。

編集：また使用：

def foobar():
    """
    foobar
    """

ドキュメンテーション用

Answer 11

小さなスクリプトを書いているときは、2 つのスペースだけを使用することがよくあります。

docstring には常に同じパターンを使用します。

def function():
    """
    Even if it's a single line.
    """

Answer 12

python-mode.el、https: //launchpad.net/python-mode

一方、スタイルのカスタマイズを許可します:

Mx カスタマイズ変数 RET py-docstring-style RET

デフォルト値は pep-257-nn です

実装されているスタイルは、DJANGO、ONETWO、PEP-257、PEP-257-NN、SYMMETRIC、および NIL です。

NIL の値は、引用符の位置を気にせず、docstring を通常の文字列として扱います。その他の値を指定すると、次の docstring スタイルのいずれかになります。

ジャンゴ:

"""
Process foo, return bar.
"""

"""
Process foo, return bar.

If processing fails throw ProcessingError.
"""

ワンツー:

"""Process foo, return bar."""

"""
Process foo, return bar.

If processing fails throw ProcessingError.

"""

PEP-257:

"""Process foo, return bar."""

"""Process foo, return bar.

If processing fails throw ProcessingError.

"""

PEP-257-NN:

"""Process foo, return bar."""

"""Process foo, return bar.

If processing fails throw ProcessingError.
"""

対称:

"""Process foo, return bar."""

"""
Process foo, return bar.

If processing fails throw ProcessingError.
"""

Answer 13

私は pylint http://pypi.python.org/pypi/pylintを使用しています。これは、コードをクリーンに保ち、コードにアクセスする他の開発者が読みやすいようにするための優れたツールです。

ただし、あなたが言ったすべてのトピックをカバーしているわけではありませんが、非常に便利です.

次のようなレポートを作成できます。

carlos@debian:~/src/fcl/cltools$ pylint numbertoletters.py
No config file found, using default configuration
************* Module numbertoletters
C:  1: Missing docstring
C: 56:es_numero: Missing docstring
C: 56:es_numero: Invalid name "s" (should match [a-z_][a-z0-9_]{2,30}$)
C: 56:es_numero: Invalid name "s" (should match [a-z_][a-z0-9_]{2,30}$)
C: 69:convertnumbertoletters: Empty docstring
C: 90:convertnumbertoletters: Operator not preceded by a space
    numero='%(numero)09d' % {'numero' : int(parte_entera)}
          ^
C: 92:convertnumbertoletters: Comma not followed by a space
    for i in [0,3,6]:
               ^^

W: 69:convertnumbertoletters: Unused argument 'languaje'
C:108:unidades: Empty docstring
C:108:unidades: Invalid name "x" (should match [a-z_][a-z0-9_]{2,30}$)
C:108:unidades: Invalid name "x" (should match [a-z_][a-z0-9_]{2,30}$)
C:112:unidades: Invalid name "u" (should match [a-z_][a-z0-9_]{2,30}$)
C:118:teens: Empty docstring
C:118:teens: Invalid name "x" (should match [a-z_][a-z0-9_]{2,30}$)
C:118:teens: Invalid name "x" (should match [a-z_][a-z0-9_]{2,30}$)
C:122:teens: Invalid name "t" (should match [a-z_][a-z0-9_]{2,30}$)
C:127:tens: Empty docstring
C:127:tens: Invalid name "x" (should match [a-z_][a-z0-9_]{2,30}$)
C:127:tens: Invalid name "x" (should match [a-z_][a-z0-9_]{2,30}$)
C:131:tens: Invalid name "t" (should match [a-z_][a-z0-9_]{2,30}$)
C:137:tercia: Empty docstring
C:141:tercia: Operator not preceded by a space
    numero='%(numero)03d' % {'numero' : int(num)}
          ^
C:143:tercia: Invalid name "a" (should match [a-z_][a-z0-9_]{2,30}$)
C:144:tercia: Invalid name "b" (should match [a-z_][a-z0-9_]{2,30}$)
C:145:tercia: Invalid name "c" (should match [a-z_][a-z0-9_]{2,30}$)
C:163:tercia: Operator not followed by a space
                resultado ='veinti '+unidades(c)
                          ^
C:165:tercia: Operator not followed by a space
        elif b >=3 and b <= 9:
               ^^
C:178:tercia: Operator not followed by a space
                resultado ='ciento '+unidades(c)
                          ^
C:192:tercia: Operator not followed by a space
                resultado ='ciento veinti '+unidades(c)
                          ^
C:204:tercia: Operator not preceded by a space
            prefix='quinientos '
                  ^
C:206:tercia: Operator not preceded by a space
            prefix='setecientos '
                  ^
C:208:tercia: Operator not preceded by a space
            prefix='novecientos '
                  ^
C:210:tercia: Operator not preceded by a space
            prefix=unidades(a)+'cientos '
                  ^
R:137:tercia: Too many return statements (23/6)
R:137:tercia: Too many branches (41/12)
R:137:tercia: Too many statements (73/50)


Report
======
141 statements analysed.

Raw metrics
-----------

+----------+-------+------+---------+-----------+
|type      |number |%     |previous |difference |
+==========+=======+======+=========+===========+
|code      |144    |68.25 |NC       |NC         |
+----------+-------+------+---------+-----------+
|docstring |5      |2.37  |NC       |NC         |
+----------+-------+------+---------+-----------+
|comment   |57     |27.01 |NC       |NC         |
+----------+-------+------+---------+-----------+
|empty     |5      |2.37  |NC       |NC         |
+----------+-------+------+---------+-----------+



Statistics by type
------------------

+---------+-------+-----------+-----------+------------+---------+
|type     |number |old number |difference |%documented |%badname |
+=========+=======+===========+===========+============+=========+
|module   |1      |NC         |NC         |0.00        |0.00     |
+---------+-------+-----------+-----------+------------+---------+
|class    |0      |NC         |NC         |0           |0        |
+---------+-------+-----------+-----------+------------+---------+
|method   |0      |NC         |NC         |0           |0        |
+---------+-------+-----------+-----------+------------+---------+
|function |6      |NC         |NC         |0.00        |0.00     |
+---------+-------+-----------+-----------+------------+---------+



Duplication
-----------

+-------------------------+------+---------+-----------+
|                         |now   |previous |difference |
+=========================+======+=========+===========+
|nb duplicated lines      |0     |NC       |NC         |
+-------------------------+------+---------+-----------+
|percent duplicated lines |0.000 |NC       |NC         |
+-------------------------+------+---------+-----------+



Messages by category
--------------------

+-----------+-------+---------+-----------+
|type       |number |previous |difference |
+===========+=======+=========+===========+
|convention |32     |NC       |NC         |
+-----------+-------+---------+-----------+
|refactor   |3      |NC       |NC         |
+-----------+-------+---------+-----------+
|warning    |1      |NC       |NC         |
+-----------+-------+---------+-----------+
|error      |0      |NC       |NC         |
+-----------+-------+---------+-----------+



Messages
--------

+-----------+------------+
|message id |occurrences |
+===========+============+
|C0103      |14          |
+-----------+------------+
|C0322      |6           |
+-----------+------------+
|C0112      |5           |
+-----------+------------+
|C0323      |4           |
+-----------+------------+
|C0111      |2           |
+-----------+------------+
|W0613      |1           |
+-----------+------------+
|R0915      |1           |
+-----------+------------+
|R0912      |1           |
+-----------+------------+
|R0911      |1           |
+-----------+------------+
|C0324      |1           |
+-----------+------------+



Global evaluation
-----------------
Your code has been rated at 7.45/10

I hope it helps.

特に開発者のコ​​ミュニティでは、pylint を使用してコードを評価し、標準的なプログラミング方法を維持することを強くお勧めします。=)

お役に立てば幸いです。