66

私はこのようなコードを持っています。休憩は生理の前または後に発生する必要がありますか？

# before
my_var = somethinglikethis.where(we=do_things).where(we=domore).where(we=everdomore)

# this way
my_var = somethinglikethis.where(we=do_things) \
                          .where(we=domore) \
                          .where(we=everdomore)

# or this way
my_var = somethinglikethis.where(we=do_things). \
                           where(we=domore). \
                           where(we=everdomore)
4

4 に答える 4

108

\PEP 8では、必要がないように括弧を使用することをお勧めします。また、二項演算子の後ではなく、前で中断することをお勧めします。したがって、コードをフォーマットするための好ましい方法は次のとおりです。

my_var = (somethinglikethis
          .where(we=do_things)
          .where(we=domore)
          .where(we=everdomore))

関連する2つのパッセージは、[最大行長]セクションの次のパッセージです。

長い行を折り返すための推奨される方法は、かっこ、角かっこ、中かっこ内にPythonの暗黙の行継続を使用することです。式を括弧で囲むことにより、長い行を複数の行に分割できます。これらは、行の継続に円記号を使用するよりも優先して使用する必要があります。

...そして全体二項演算子の前または後に改行する必要がありますか？セクション：

二項演算子の前または後に改行する必要がありますか？

何十年もの間、推奨されるスタイルは二項演算子の後に破ることでした。ただし、これは2つの点で読みやすさを損なう可能性があります。演算子は画面上のさまざまな列に散らばる傾向があり、各演算子はオペランドから前の行に移動します。ここで、目はどのアイテムが追加され、どのアイテムが削除されるかを判断するために追加の作業を行う必要があります。

# No: operators sit far away from their operands
income = (gross_wages +
          taxable_interest +
          (dividends - qualified_dividends) -
          ira_deduction -
          student_loan_interest)

この読みやすさの問題を解決するために、数学者とその出版社は反対の慣習に従います。Donald Knuthは、彼のComputers and Typesettingシリーズの従来の規則について次のように説明しています。「段落内の数式は常に二項演算と関係の後に壊れますが、表示される数式は常に二項演算の前に壊れます」

数学の伝統に従うと、通常、より読みやすいコードになります。

# Yes: easy to match operators with operands
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)

Pythonコードでは、規則がローカルで一貫している限り、二項演算子の前後で中断することができます。新しいコードについては、Knuthのスタイルが提案されています。

上記の引用で示されているように、PEP 8は、後世のために以下に引用されている、演算子を回避する場所について反対のアドバイスを提供するために使用されたことに注意してください。

長い行を折り返すための推奨される方法は、かっこ、角かっこ、中かっこ内にPythonの暗黙の行継続を使用することです。式を括弧で囲むことにより、長い行を複数の行に分割できます。これらは、行の継続に円記号を使用するよりも優先して使用する必要があります。続く行を適切にインデントしてください。二項演算子を回避するのに適した場所は、演算子の前ではなく、演算子の後です。いくつかの例：

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)
于 2011-10-30T00:42:11.843 に答える
5

PEP 8は、オペレーターの前にブレークすることが好ましいと述べています。

Donald Knuthは、彼のComputers and Typesettingシリーズの従来の規則について次のように説明しています。「段落内の数式は常に二項演算と関係の後に壊れますが、表示される数式は常に二項演算の前に壊れます」。

..。

Pythonコードでは、規則がローカルで一貫している限り、二項演算子の前後で中断することができます。新しいコードについては、Knuthのスタイルが提案されています。

https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator

于 2016-05-09T11:54:42.507 に答える
3

うまくいくことをしなさい。

また、 Pythonのインデントの神話に関するこのホワイトペーパーも確認してください。それはここで見つけることができます。

それは次のように始まります：

「空白はPythonソースコードで重要です。」

いいえ、一般的ではありません。ステートメントのインデントレベルのみが重要です（つまり、ステートメントの左端にある空白）。他の場所では、空白は重要ではなく、他の言語と同じように好きなように使用できます。何も含まない（または任意の空白のみを含む）空の行をどこにでも挿入することもできます。

それがお役に立てば幸いです。

于 2011-10-30T00:39:50.630 に答える
2

FWIW、autopep8（--aggressiveフラグ付き）は、元のコードからこれを生成しました：

my_var = somethinglikethis.where(
    we=do_things).where(
    we=domore).where(
    we=everdomore)

しかし、私は同意します-バスティエンのソリューションはよりエレガントです。

于 2014-02-18T15:44:38.677 に答える