Pythonコーディング標準/ベストプラクティス
python一般的に PEP 8-スタイルガイドPython Code をコーディング標準/ガイドラインとして使用しますか？あなたが好む他の正式な標準？
Python Idioms and Efficiency ガイドライン、Rob Knightに従います。これらはPEP 8とまったく同じですが、より合成的であり、例に基づいています。
WxPythonを使用している場合は、Chris Barkerによる wxPythonコードのスタイルガイド も確認することもできます。
私はPEP-8に非常に忠実に固執しています。
PEP-8に変更するのが面倒なことは3つあります。
括弧、括弧、または中括弧のすぐ内側にある余分な空白を避けてください。
推奨：
spam(ham[1], {eggs: 2})とにかくこれを行います：
spam( ham[ 1 ], { eggs: 2 } )どうして？ 30年以上の染み込んだ習慣が、関数名または（Cで）ステートメントキーワードに対して（）を寄り添っています。 70年代のFortran IVから。
算術演算子の前後にスペースを使用します。
推奨：
x = x * 2 - 1とにかくこれを行う：
x= x * 2 - 1どうして？ Griesのプログラミング科学は、これを、割り当てと状態が変更される変数との関係を強調する方法として提案しました。
複数の割り当てまたは拡張された割り当てではうまく機能しません。そのため、私は多くのスペースを使用しています。
関数名、メソッド名、インスタンス変数名について
推奨：小文字。読みやすくするために、必要に応じて単語をアンダースコアで区切ります。
とにかくこれを行う：camelCase
どうして？ 80年代のPascalから始まる、20年以上のラクダケースの染み込んだ習慣。
Anthony Baxterの Effective Python Programming （OSON 2005以降）に関するプレゼンテーションをご覧ください。
抜粋：
# dict's setdefault method turns this:
if key in dictobj:
dictobj[key].append(val)
else:
dictobj[key] = [val]
# into this:
dictobj.setdefault(key,[]).append(val)
PEP 8は優れています。もっと難しくなって欲しいのは、Tabs-vs-Spacesの聖戦だけです。
基本的に、Pythonでプロジェクトを開始する場合は、タブまたはスペースを選択してから、すべての違反者を目撃する必要があります。
私は非常に厳密にそれに従います。 PEP-8以前の唯一の神は、既存のコードベースです。
はい、できる限り厳密にそれに従うようにします。
他のコーディング標準には従いません。
私はPEP8に従います。これはすばらしいコーディングスタイルです。