数え切れないほどの Python のベスト プラクティスがオンラインで流通しているため、それぞれについての意見は質問する人によって異なります。インターネットにより専門知識が民主化され、私を含め誰もが自分の意見を共有できるようになりました。ただし、この記事では、幅広いコンセンサスを獲得し、基本的であると広くみなされている 10 個の時代を超えた Python のベスト プラクティスに焦点を当てます。

パンダのチートシート

Git コマンド チートシート

SQL インタビューの質問トップ 50

ヒント 1: 関数はパラメーターと戻り値の型を指定する必要があります
関数を定義するときは、引数の型と関数の結果が返すデータ型を常に指定する必要があります。これにより、あなたとチームの開発者の両方が、常に print ステートメントを使用して視覚的に理解する必要がなく、何が予想されるかを知るのに役立ちます。

ヒント 2: 関数は同じ抽象レベルである必要があります
同じ抽象レベルにある関数について話すとき、私たちは関数が明確に定義された単一のタスクを実行する必要があるという考えを指します。そのタスクは、関数全体を通じて一貫した抽象化レベルにある必要があります。言い換えれば、関数は特定のレベルの詳細または複雑さに重点を置く必要があり、すべての関数の操作は同じレベルで動作する必要があります。

ヒント 3: 関数は小さくする必要があります
関数は再利用可能であることを目的としています。そして、関数が大きくなるほど、再利用できる可能性は低くなります。これは、関数が 1 つのことだけを行う必要がある理由にも関係します。 1 つのことだけを行う場合は、小規模になる可能性が高くなります。

ヒント 4: オープンクローズの原則
オープンクローズ原則 (OCP) では、クラス、メソッド、または関数は拡張のためにオープンである必要がありますが、変更はできないと規定されています。これは、定義されたクラス、メソッド、関数は、コードを変更せずに簡単に再利用したり、複数のインスタンスに拡張したりできることを意味します。
新しい国ができるたびに、それを補完する新しい if ステートメントを作成する必要があるため、これは OCP に準拠していません。これは今では簡単に思えるかもしれませんが、考慮すべき国が 100 以上あると想像してください。それはどのように見えますか?

ヒント 5: コメントは絶対に避ける
コメントには真実であるかのように偽る可能性があります。これらは、コードが実際に行っていることから、他の人が言っていることに読者の意識を逸らさせます。

これは、時間が経ち、コードが更新または変更を受けると、非常に問題になる可能性があります。ある時点で、そのコメントは嘘になり、誰もが嘘のレンズを通して真実を観察しなければなりません。

コメントは絶対に避けてください。コメントは、せいぜい過去のあなたの考えを読者に継承させることになります。関数またはクラスが変更されても、ほとんどの場合、そのコメントは変更されません。おそらく、それらは読者が前向きに考えることを妨げます。

コメントは、作成者が適切に説明するクラス、関数、または変数名を提供する能力が精神的に無かったことを示します。これはプログラマーの精彩のない態度を暴露し、チームにそのような態度を継承させることを強います。

ヒント 6: マジックナンバーを避ける
マジック ナンバーはハードコードされた値であり、後の段階で変更される可能性がありますが、そのため更新が難しい場合があります。

たとえば、「ご注文」概要ページに過去 50 件の注文を表示するページがあるとします。ここでの 50 はマジック ナンバーです。これは標準や慣例によって設定されたものではなく、仕様に概説されている理由から作成した数字だからです。

さて、この 50 個をさまざまな場所に保存します。SQL スクリプト (SELECT TOP 50 * FROM 注文)、Web サイト (最後の 50 個の注文)、注文ログイン (for (i = 0; i ヒント 7: 深いネストを避ける

可読性を向上させるために、ループ、条件、または関数内のネストのレベルを制限します。

ヒント 8: パスのハードコーディングを避ける

ファイル パスや URL をハードコーディングしないでください。代わりに構成ファイルまたは環境変数を使用してください。

ヒント 9: クラスは少人数にする必要があります

そうだ！クラスはできるだけ少人数にする必要があります。関数と同じです。

唯一の違いは、関数ではサイズがその関数の行数によって決定されるのに対し、クラスではそのクラス内の責任の数によって決定されることです。

通常、クラス名はそのクラスが持つ可能性のある責任の種類を表しますが、名前が曖昧だったり一般的すぎる場合は、クラス名に過剰な責任を与えている可能性が高くなります。

これは、クラスが変更する理由は 1 つだけ、つまり責任は 1 つだけであるべきであるという SRP (単一責任原則) に戻ります。

ヒント 10: 複雑な 3 項式を避ける

過度に複雑な 3 項式の使用は避けてください。コードをより理解しやすくするために、簡潔さよりも読みやすさを重視します。