リンターに関するホリバーニーの物語

私たちは皆コードを書きます。 たくさんのコード。 もちろん、エラーがあります。 時には曲がったコードであり、エラーの代償は宇宙船の爆発です。 もちろん、意図的な妨害をする人はいません。誰もができる限り品質を監視しようとしますが、静的解析ツールがなければ、すべてが完璧であることを確認することはほとんど不可能です。



リンターは、コードを単一のスタイルにし、ミスを防ぐのに役立ちます。 確かに、苦しむ準備ができている場合にのみ、最後に「pylint：disable」を却下せずに、遅れを取ります。 リンターはどうあるべきか、なぜPylintができないのかは、リンターを理解し、愛しているニキータ・ソボレヴンを知っています。







以下に、 モスクワのPython Conf ++のリンターに関するレポートのテキスト版、それらを正しく行う方法、しない方法を示します。 プレゼンテーションには、多くの双方向性、オンライン、視聴者とのコミュニケーションがありました。 講演者は途中で投票を行い、聴衆を説得しようとしました。彼は傾向を見て、議論のように、比率を平準化し世論を変えようとしました。 投票の一部は復号化に陥りましたが、すべてではないため、画像を完成させるためにビデオが添付されています。

リンターが必要なのはなぜですか？

リンターの最も重要なタスクは、コードを均一にすることです。 Pythonで同じことを書くための多くのオプションがあります。ここにカンマを入れる、括弧を閉じるのを忘れる、忘れないでください。 人々が長い間コードを書くとき、それは異なる時間に縫い合わされた異種の断片のパッチワークキルトのようになります。 そのような毛布で作業することは不快であり、コードを読みたいという欲求を落胆させ、これは非常に悪いことです。



リンターはレビューで生活を楽にします 。 私はコードレビューに来て、考えます：「私はこれをしたくありません！ 余分なスペースや他のナンセンスがあります！」他の誰かに良いコードを準備してもらいたいと思います。その後、素晴らしい概念的なものに感謝します。



ときどきコードを見て、すべてがうまくいくと思うと、一部の関数で変数が多すぎたり、注意を払っていないエラーが表示されたりします。 オートメーションはこのエラーを見つけますが、私は見ました。 そのような状況に陥らないようにするために-私はリンターを使います-彼は隠されていて見つけにくいものをすべて見つけます。

リンターとは何ですか？

最も簡単なものは、スタイルのみをチェックします （例： Flake8） 。 ある程度、黒でも、むしろそれはオートフォーマー-リンターです。 リンターは、文体だけでなくセマンティクスをテストします。何をするのか、なぜするのか、エラーを書いた場合は手で打つ。 良い例はPylintで 、これは私たち全員が知っており、使用し、愛しています。 私はこれらのリンターをベストプラクティスと呼んでいます。 3番目のタイプはタイプチェックです 。これらのリンターは少しずれています。 Pythonの型チェックは新しく、 MypyとPyreという 2つの競合するプラットフォームで行われています。

リンターの使用方法

私はリンターが万能薬であり、すべての代替品であると主張していません。 そうではありません。 リンター-ピラミッドの最初のステップ。これにより、コードが実稼働に入ります。



ピラミッドには3つのステップがあります。

• linterを起動します。 非常に高速で、ソースコード以外は必要ありません。インフラストラクチャも設定も必要ありません。 チェック：最初の健全性チェックに合格-すべては問題ありません 。引き続き作業します。
• ステージテスト 。 このプロセスは、コード以外のエラーのためにより複雑で長くなります。 アプリケーション全体を正しく完全にセットアップする必要があります。
• ステージレビュー 。

これらは、コードが実稼働に入るために必要な手順です 。 ステップを1つも実行しなかった場合、何かを忘れた場合、またはレビュー担当者がそれが機能しないと言った場合、「失敗-不良コードは本番に入りません」という碑文が表示されます。

職場でリンターを使用していますか？

リンターを使用するかどうかにかかわらず、週7日間働く厳しい企業の開発者に尋ねると、少なくとも3分の1がリンターを非常に厳密に使用していることがわかります。CI が落ちると、チェックが厳しくなります。 残りは、 レポートシステムとしてではなく 、スタイルをチェックするためだけにほぼ同等にリンターを適用します。リンターを開始し、レポートを生成して、すべてがどれだけ悪いかを確認します。 リンターが使用されていますが、それは良いことです。 弊社では、ハードリンティング、多くのチェック、二重コードレビューなど、すべてが非常に厳しく構築されていました。

コードレビュー

この段階で問題が発生します。 これは、ピラミッドの最上位で最も困難なステップです。コードレビューを自動化することはできません。可能であれば、コード記述の自動化につながります。 そうすれば、プログラマーは必要なくなります。



デフォルトでは、プロセスは次のようになります。レビューのためにコードが入力され、エラーが検出されたため、これ以上エラーを作成する必要はありません。 たとえば、開発者がBaseExceptionをキャッチしたことがわかりました。「これをしないでください。 キャッチしないでください！」 10日後、同じこと。 もう一度思い出します：



-BaseExceptionをキャッチしません。

「 いいですね、わかりました。」



1年が経ちます-同じ間違い。 新しい男が来る-同じ間違い。 どうすればすべてを自動化して、状況が二度と起こらず、頭に浮かぶのだろうか。 »オープンパッケージを作成し、作業で使用するすべてのルールをそこに配置し、毎回手作業で記述しないようにルールチェックを自動化します。 すべてをすぐに自動化します！



当然、「 既製のリンターはすでに存在し、動作し、誰もが使用します-なぜ独自のものを使用しますか？」と言うことができます。そして、リンターが本当にいるので、あなたは絶対に正しいでしょう。 どれが何をするのか見てみましょう。

ピリント

「 なぜPylintではないのか？」という見出しについて 「この質問を何度も聞いたことがあります。 彼にもっと柔らかく答えます。 PylintはPythonコードの優れたロックスターツールですが、リンターには見たくない機能があります。



文体チェック、ベストプラクティス、タイプチェックなど、すべてを組み合わせます 。 Pylint Typeチェックは、型情報がないため未発達です。何らかの方法で表示しようとしますが、うまく機能しません。 したがって、Djangoでmodel_name.some_property



を記述すると、「申し訳ありませんが、そのようなプロパティはありません-使用できません！」というエラーが表示されることがよくあります。プラグインがあることを覚えています。トラブル、Celeryのプラグインを配置し、他の魔法のライブラリを使用し、最終的にどこにでも書きます：「pylint：disable」...これはリンターから得たいものではありません。



ユーザーから隠されたもう1つの機能は、PylintがPythonの抽象構文ツリーの独自の実装を持っていることです 。 これは、コードを解析し、コードを構成するノードのツリーに関する情報を取得したときのコードの外観です。 私は自分の実装が本当に間違っているので、自分の実装を本当に信用していません。



Pylintに加えて、他のリンターも仕事をしています。

ソナークベ

プロジェクトの近くのどこかに存在する、すばらしいが別個のツール。

• SonarQubeは頻繁に実行できません 。どこかにデプロイし、監視、監視、構成する必要があります。
• Javaで書かれています 。 Python用にリンターを修正する場合は、Javaでコードを記述します。 概念的にこれは間違っていると思います-Pythonで書くことができる開発者は、Pythonをテストするためのコードを書くことができるはずです。

SonarQubeを開発する会社は、製品開発の概念に特に注目しています。 これは問題になる可能性があります。



SonarQubeの利点は、複雑さ、潜在的な隠れたエラー、バグを示す非常にクールなチェックがあることです。 私はチェックが好きです、私はそれらを残して、プラットフォームを変更します。

フレーク8

すばらしいリンターは非常に単純ですが、1つの問題があります 。コードがどれだけうまく書かれているかをチェックするルールがほとんどありません 。 同時に、Flake8には多くの非常にシンプルなプラグインがあります。最小プラグインは実装する必要がある2つのメソッドです。 Flake8をベースにしてプラグインを作成しましたが、会社にとってのメリットを理解した上で考えました。 そして、そうしました。

世界で最も厳しいリンター

Pythonにふさわしいと思われるすべてのものを集めたツールを作成し、 wemake-python-styleguideと呼びました 。 デフォルトでオープンソースが良い習慣であると信じているので、プラグインは公開されました 。 私は、多くのツールがオープンソースにアップロードされれば有益になると確信しています。 私たちの楽器のために、 「世界で最も厳しいリンター」というスローガンを思いつきました。

私たちのリンターのキーワードは厳格であり、痛みと苦しみを意味します。

リンターを使用し、それが苦痛にならないように頭をつかんでいる場合、「なぜあなたはまだそれを気に入らないのか、気にします」、これは悪いリンターです。 エラーをスキップし、コードの品質を十分に監視していないため、必要ありません。 世界で最も厳しいものが必要です。 現在、スタイルとベストプラクティスの両方のカテゴリに約250の異なるテストがありますが、タイプチェックはありません。 Mypyはそれを扱いますが、それとは何の関係もありません。



私たちのリンターには妥協はありません 。 「これはしたくないが、本当にやりたいのならできる」というカテゴリのルールはありません。 いいえ、私たちは常に厳しく話します-悪いので、それをしません。 それから人々は来て、「これが原則として可能なユースケースが2.5あります！」と言います。 そのような場合は、この行はリンターがそれを無視することを許可していることを明確に書きますが、その理由を説明してください。 なぜ奇妙な練習を許可したのか、なぜそれをしているのかについてのコメントでなければなりません。 このアプローチは、コードの文書化にも役立ちます。



最も厳しいリンターは設定（WIP）を必要としません 。 まだ設定はありますが、それを取り除きたいと思います：自由があれば、ユーザーは確実にリンターが正しく動作しないように設定します。

適切なツールは設定を必要としません-適切なデフォルト値があります。

このアプローチにより、コードは一貫性があり、少なくとも理論上はすべてのユーザーに対して同じように機能します。 私たちはまだこれに取り組んでおり、設定がありますが、ツールを使用して自分用にカスタマイズすることができます。

私たちは誰に依存していますか？

多数のツールから。

• フレーク8 。
• Eradicateは、コード内のコメントアウトされたフラグメントを見つけて削除するクールなプラグインです。プロジェクトにデッドコードを保存するのは悪いためです。 許可されていません。
• Isortは、インポートを正しくソートするように強制するツールです：順番、インデント、美しい引用。
• Banditは、コードセキュリティを静的にチェックするための優れたツールです。 有線パスワード、コード内でのassert
  
  
  
  不器用な使用、 Popen
  
  
  
  、 sys.exit
  
  
  
  呼び出しをsys.exit
  
  
  
  、これらはすべて使用できないと言いますが、必要に応じて、理由を書くように求めます。
• そして、括弧、引用符、カンマをチェックする20以上のプラグイン 。

何をチェックしていますか？

私たちが使用および実施するルールのグループは4つあります。



複雑さが最大の問題です。 複雑さはわかりませんし、コードには表示されません。 私たちは毎日作業するコードを見て、それは複雑ではないようです-それを取り、読んで、すべてが動作します。 そうではありません。 単純なコードはおなじみのコードです。 複雑さには、テストする明確な基準があります。 基準自体について-後で。 コードが基準に違反している場合、「コードは複雑です。書き直してください！」



変数の名前は未解決のプログラミング問題です。 誰がいつどのような文脈で読むのかは不明です。 名前をできる限り一貫性のあるわかりやすいものにするよう努めていますが、試していますが、問題はまだ完全には解決されていません。



一貫性を保つために、単純なルールがあります-どこでも同じことを書きます。 検証済みのアプローチがある場合は、あらゆる場所で使用してください。 好むと好まざるとにかかわらず、一貫性がより重要です。



ベストプラクティスのみを使用するようにします。 一部のプラクティスがあまり良くないことがわかっている場合、その使用を禁止します。 開発者が禁止されている慣行を使用したい場合、私たちは彼からの議論を期待します。 おそらく、説明の過程で、なぜそれが悪いのかが理解されるでしょう。

複雑さとは何ですか？

複雑さには特定の指標があり、それを見て、それが難しいかどうかを判断できます。 たくさんあります。



循環的複雑性 -誰もが好む循環的複雑性。 これは、コード内で多数のネストされたif



、 for



、その他の構造を検出し、コードの分岐が多すぎることと読み取りが困難であることを示します。 埋め込まれたコードでは、すべてが悪いです。あなたは読んで、読んで、読んで-戻って、読んで、読んで、読んで-ジャンプして、別のサイクルに入ります。 このようなコードを上から下に安全に渡すことは不可能です。



引数、ステートメント、および戻り値。 これらは定量的な指標です。関数またはメソッドに含まれる引数の数、この関数の本体またはステートメントと戻り値のメソッドに含まれる引数の数。



結合と結合は、OOPの世界で人気のある指標です。 凝集度は、内部のクラスのつながりを示しています。 たとえば、クラスがあり、内部ですべてのメソッドとプロパティ（宣言したすべて）を使用します。 これは、内部で高い接続性を持つ優れたクラスです。 カップリングとは、システムのさまざまな部分（モジュールとクラス）がどれだけ接続されているかです。 クラス内で最大の接続性を実現し、外部で最小の接続性を実現したいと考えています。 その後、システムは簡単に維持され、うまく機能します。



ジョーンズの複雑さ -私はこのメトリックを借りましたが、それは爆弾だからです！ ジョーンズの複雑さは、線の複雑さを決定します。線が複雑になるほど、人間の短期記憶は一度に5〜9個以上のオブジェクトを処理できないため、理解が難しくなります。 これはいわゆるミラー財布です。



これらの重要なメトリクスと他のいくつかのはるかに大きいメトリクスを見て、コードが適切かどうかを判断します。 私たちの理解では、 複雑さは滝です。

滝の難易度

難しさは、私たちがラインを書いたという事実から始まりますが、それはまだ良いです。 しかし、ビジネスがやって来て、価格が2倍になったと言い、2を掛けます。この時点で、ジョーンズコンプレキシティはおかしくなり、ラインが複雑すぎて、ロジックが多すぎると言います。



さて、新しい変数を開始すると、関数複雑度アナライザーは次のように言います。



- いいえ、不可能です-関数内の変数が多すぎます。



新しいメソッドを作成し、引数を渡します。 ここで、関数の引数の数、またはクラス内のメソッドの数を確認すると、これも不可能であることがわかります-クラスは複雑すぎて、2つの部分に分割する必要があります。 別のクラスを強調表示してクラッシュしました。 これでクラスが増えてすべてが正常になりましたが、 モジュールの複雑さをチェックすると、モジュールが複雑すぎてリファクタリングが必要であると報告されます。 なぜ？！



これは苦しみと呼ばれます。 だから私はリンターがあなたを苦しめるべきだと言っています。 1行に2を掛けることから始め、 システム全体をリファクタリングしました 。 複雑さは滝のように広がり、可能なすべてをカバーするため、小さなコードを追加するとモジュール全体がリファクタリングされます。



「リファクタリングが必要」 -これにより、コードをリファクタリングできます。 ただ座ってすることはできません：「私はこのコードに触れないで、うまくいくようです。」 いいえ、いつか他の場所でコードを変更し、複雑さの滝が触れなかったモジュールをあふれさせ、リファクタリングする必要があります。 リファクタリングは優れていると思います。それが多ければ多いほど、システムの動作は安定し、向上します。 そして、他のすべては主観的です！



それでは味について話しましょう。 これは全体的かつインタラクティブな部分です！

ホリバー

サポートしましょう、コメントは公開されています。 まず、名前は複雑で未解決の問題であることを思い出させてください。 変数の名前の付け方をめぐって争うことはできますが、少なくとも明らかな間違いをしないようにするいくつかのアプローチがあります。

名前

どのように好きですか： var、value、item、obj、data、result データとは？ 一部のデータ。 結果とは何ですか？ 何らかの結果。 多くの場合、 結果変数と理解できないクラスのいくつかの地味なメソッドの呼び出しを見ます-そして、私は思う：「この結果は何ですか？ なぜ彼はここにいるのですか？」



私に反対し、 値は完全に普通の変数名であると言う開発者がたくさんいます：



- 私は常にキーと値を使用します！

- なぜキーと値を使用しないが、キーは名前であり、値は姓であると言う？ なぜfirst_nameとlast_nameに名前を付けることができないのか-今、コンテキストがあります。



通常、人々は同意しますが、とにかく議論します。 これは非常に全体的なことです。少なくとも3人が私と一緒にこれについて議論するために1時間の人生を過ごしました。

変数に1文字で名前を付けても大丈夫ですか？

たとえば、 q ？ 私たちは皆、古典的なケースを知っています： for i in some_iterable:



私は何ですか？ Cでは、これは標準的な慣行であり、すべてがそこから来ています。 しかし、Pythonでは、コレクションとイテレーター。 コレクションには名前のある要素が含まれています-何らかの方法でそれらを呼び出しましょう。

開発者の半数は、変数i、x、y、zの呼び出しは正常であると考えています。

名前を一文字で呼ぶことはできないと思います。 より多くのコンテキストが必要であり、開発者の後半が私に同意するのは良いことです。 Cでこれがまだ歴史的遺産のために何らかの形で許容される場合、Pythonではこれは非常に大きな問題であり、それを行う必要はありません。

一貫性

多くの方法の中から1つの方法を選択して、「やろう」と言いましょう。 それが良いか悪いかは、もはや問題ではありませんが、単に一貫しています。



Python 3についてのみ話しているので、レガシーはまったく考慮されていません。



私は引数を持っています：何かから継承するとき、何から知っているべきです-親の名前を見るといいでしょう。 面白いのは、これがオブジェクトである場合を除き、通常は親の名前が表示されることです。 したがって、私は自分のためにルールを策定しました。クラスを書くとき、私は何かから継承します-私は常に親の名前を書きます。 それが何になるかは関係ありません-モデル、オブジェクト、その他。



Class Some(object)



またはclass Some



を作成する選択肢がある場合は、最初のものを選択します。 一方では、常に継承元を明示的に記述していることを示しています。 一方、特定の冗長性はありません。いくつかの追加のキーストロークで何も失われません。



開発者の3分の2は2番目のオプションに精通しており、その理由さえ知っています。 私の仮説：すべては、Pythonの2番目のバージョンから3番目のバージョンに長い間移行してきたので、3番目のPythonで書いていることを示しています。 仮説がどのように正しいのかはわかりませんが、そうだと思います。

Fラインはひどいですか？

回答オプション：

• はい：コンテキストを失い、テンプレートにロジックを配置し、リントしません-（38％）。
• いや！ 彼らは奇跡です！ -（62％）。

fラインはひどいという仮説があります。 彼らは何でも入れます！ f-lineは.format



と同じではなく、違いは劇的です。 特定のテンプレートを宣言してからフォーマットする場合、2つのアクションを別々に実行します。最初にテンプレートを定義し、次にフォーマットします。 f-lineを宣言するとき、2つのアクションを同時に実行します。テンプレートをすぐに宣言し、同時にフォーマットします。



fラインには2つの問題があります。 f-lineのテンプレートを宣言しましたが、すべて機能します。 そして、テンプレートを2行上に移動するか、別の機能に移動することにします-そしてすべてが壊れます。 現在 、 文字列をフォーマットすることを許可するコンテキストはなく 、それらを正しく処理することはできません。 fラインの2番目の大きな問題：ひどいことをすることができます- ロジックをテンプレートに貼り付けます。 ユーザー名と「Hello」という単語を単純に挿入する行があるとします-これは正常です。 特にひどいものはありませんが、ユーザー名が大文字であることがわかりusername.title()



。タイトルケースに変換し、 username.title()



テンプレートに直接書き込むことにしusername.title()



。 次に、条件、サイクル、インポートがテンプレートに表示されます。 そして、phpの他のすべての部分。



これらすべての問題から、 f-lineは悪いトピックであると言わざるを得ません。 面白いのは、f-lineだけが私たちに適しているというケースがないことです。 通常、任意のフォーマットが適していますが、 .format



を選択しました-他のすべては不可能です- %



もf-linesもありません。 .format



の作業もリントされます。これは、中に引用符を入れて、変数の名前または順序を記述できるためです。

レポート中、f-lineの対戦相手の数は33％から38％に増加しました。これはわずかですが、勝利です。

数字

次のような数字が好きですか： final_score = 69 * previous result / 3.14



。 これは標準的なコード行のようですが、69とは何ですか？ このような質問は、私がしばらく前に書いたコードを見るとよく発生し、そのときのマネージャーは次のように述べています。



-147を掛けてください。

- なぜ147ですか？

- 私たちはそのような関税を持っています。



乗算して忘れてしまった、または長い間係数の値を選択してすべてが機能するようにした-そして、それをどのように拾い上げたのか、そしてその理由を忘れた。 重要な研究作業が無題の数の後ろに隠されたままであることが判明しました。 私はこの番号が何であるかさえ知りませんが、後でコミットすることによって、どういうわけかそれを見つけて、覚えて、復元することができます。



どうして違うことをしないのですか？名前とドキュメントを使用して、すべての複素数を独自の変数に入れてください。 たとえば、数値69の場合、これは市場の平均的な指標であり、定数には名前とコンテキストがあることを記述します。 私はそのような研究の現場で絶え間なくとったコメントを書きます。 研究が将来変更される場合は、データを更新します。



したがって、マジックナンバーがコードを通過して内部から複雑化しないことを保証します。 彼らは各行の複雑さをチェックし、「ここに番号4766があります。それは何なのかわかりません。自分で整理してください！」と言います。私にとってそれは素晴らしい発見でした。

その結果、これに従う必要があることに気付きました。コード内のマジックナンバーを見逃すことはありません。 私たちの同僚のほぼ100％が私たちに同意し、彼らもそのような番号を使わないのは良いことです。

ただし、例外があります。これらは、-10から10までの数字、100、1000などの数字です。単に見つかることが多く、それらがないと難しいからです。 私たちは厳しいですが、サディスティックではなく 、少し考えます。

「@staticmethod」を使用していますか？

staticmethodとは何かを考えてみましょう。 なぜPythonなのか疑問に思ったことはありませんか？ しません。 次のような美しいPylintがありました。



- 見て、 self



、 cls



を使用していない -staticmethodを実行してください！

- さて、ピリント、私はstaticmethodを行います。



それから私は初心者にPythonを教え、静的メソッドとは何か、なぜ必要なのかを尋ねました。 私は答えを知りませんでした、そしてそれがそのようなクラスであり、何かが起こっているという理由だけで、関数で同じものを書くことができるか、通常の関数でself



を使用することができるかどうか考えました。 なぜstaticmethodコンストラクトが必要なのですか？



私は質問をグーグルで検索しましたが、ウサギの穴のように深いことがわかりました。 staticmethodが好まれていないプログラミング言語は他にもたくさんあります。 そして、理性的-staticmethodはオブジェクトモデルを破壊します。 その結果、 staticmethodはここではないことに気付きました。 さて、staticmethodデコレータを使用すると、リンターは「いいえ、ごめんなさい、リファクタリング！」と言います。



ほとんどの開発者は私に反対しますが、約半数はまだstaticmethodの代わりに通常のメソッドまたは通常の関数を書く方が良いと考えています。

__initのロジック__。Ru-良いか悪いか？

これは私のお気に入りのトピックです。 確かに、新しいパッケージを作成して何らかの方法で呼び出すと、__ init __。Ruが作成され、何を入れるのか疑問に思うでしょうか？ __init __。Ruに何を入れるか、そして何を-ファイルを並べて？ 私にとって、これは些細な質問ではなく、私はいつも迷っていました。おそらく最も重要なことでしょうか？ それから私は考えた-いいえ、反対に、私は最も理解可能な文脈で最も重要なものを置くでしょう。 __init __。Ruに何かを入れて、それをすべてインポートすると、循環インポートも悪いことがわかります。



私はさまざまな人気のあるライブラリを見て、それらの__init __。Ruを登り、基本的にはガベージ互換性または後方互換性があることに気付きました。 私にとって、この質問は、多くのサブパッケージを含む大きなパッケージを作成し始めたときに急激に発生しました-あなたは迷子になります。 , . Python, , , __init__. , 90% .



— , API, , - , , ? , , . API . , __init__. - : , , .



, I_CONTROL_CODE



— . , . , , __init__. — . , , , - , .

hasattr ?

hasattr ? , , Python — . hasattr , ().



, , hasattr , , . , hasattr, , . - , Python -, hasattr . , . getattr « , ». hasattr — getattr, exception .



50 50 — , , .

, layer-linter . 彼は何をしていますか？ : , , , . , - . - . .



cohesion . , . Cohesion , . False Positive , — , , .



vulture Python . - , Python , . ohesion.



Radon , : Halstead , Maintainability Index , . , — .

Final type

Final- Python. Typing Extensions, , . , - , — , . , - - , ? 必要ありません。 . - — , , , .

Gratis

, .







, .



, . , . , Python- , .

, Moscow Python Conf++ , . , , Python-.

. . , , , .