多くのPythonライブラリのコード品質は比較的低いですか？

Question

編集：この質問が尋ねられてから、標準のPython科学ライブラリ（これは対象領域でした）で多くの改善が行われました。たとえば、numpyプロジェクトはdocstringを改善するために大きな努力をしました。これらの問題に最初から継続的に対処することが可能であったかどうかは、まだ議論の余地があります。

---

このいくぶん異端な質問があります。なぜ多くのPythonライブラリが厄介なコードを持ち、標準のベストプラクティスに従っていないのですか？または、この観察は絶対に真実ではないと思いますか？状況は他の言語と比較してどうですか？これについてのあなたの意見に興味があります。

品質が不足しているという印象がある理由：

• docstringは、パブリックAPIであっても、完全に欠落しているか不完全であることがよくあります。メソッドが * args と ** kwargs をとるのはつらいですが、どの値を与えることができるかを文書化していません。

• __ init __ の外部に新しい属性を追加するなど、Pythonのコーディングが悪い。このようなことが原因で、コードの読み取り（または保守）が困難になります。

• ほとんどのライブラリは、PEP8コーディング規約に従っています。場合によっては、単一のファイルで規則が一貫していないこともあります。

• 全体的な設計は複雑で、明確なAPIはありません。ほぼ十分なリファクタリングが行われていないようです。

• ユニットテストのカバレッジが悪い。

誤解しないでください、私はPythonとそのエコシステムが大好きです。そして、これらのライブラリに苦労していても、彼らは一般的に仕事を成し遂げてくれて、感謝しています。しかし、これらの問題が原因で、最終的に開発者の時間は膨大に浪費されると思います。たぶん、 Pythonは非常に自由度が高いため、悪いコードを書くのは非常に簡単だからです。

Answer 1

ドキュメントに関しては、Pythonだけではありません。 OSSの幅広い採用を妨げている要因が1つだけある場合、それはほとんどのOSSプロジェクトの本当に恐ろしいレベルのドキュメントです。これはコードレベルで始まり、ユーザードキュメントにまで及びます。 OSSに取り組んでいる人に言ってもいいですか：

a）コードにコメントしてください！自己文書化コードのようなものはありません！

b）エンドユーザーのドキュメントにプロジェクトの時間予算の少なくとも25％を費やします。

そして、私が何を言っているのか、漠然とわかっています-私は自分のOSSプロジェクトをいくつか持っており、他のいくつかのプロジェクトに貢献しました。そして昨日、私は4時間以上、主要なOSSプロジェクト（名前もパックドリルもなし）を構築しようとしました。

Answer 2

  

代わりに、著者はそれぞれ独自の輝かしい慣習に従っているようです。また、場合によっては、規則がライブラリの同じファイルと一致しないこともあります

実世界のすばらしいコードへようこそ！

私が会ったFWIW Pythonコードは、他のどの言語よりも良くも悪くもありません。

（まあ、平均的なPHPプロジェクトよりはましですが、明らかに公平ではありません。）

Answer 3

最初に気付く必要があるのは、Pythonがバージョン2.x前後でGuidoの頭から完全に形成されたわけではないということです。過去20年間で成長しています。

実際、いくつかの標準ライブラリ（たとえばunittest、PEP-8など）は、標準ライブラリの一部が最初に作成されたときには存在していませんでした。

おそらく、あなたが見ているライブラリが古いほど、それらが現在の「ベストプラクティス」とは異なる可能性が高いことに気付くでしょう。これは、これらのプラクティスが広く採用される前のことです。最近のライブラリは、現在の慣行に準拠する可能性が高くなります。

さらに、しばしば、それらを最新にしない 理由があります。現在のPythonライブラリに対して数万行のコードが記述されているとします。さて、これらのライブラリのいずれかのメンテナは、ライブラリを変更してクラス名と関数名をPEP-8に準拠させることにしました。現在、作業コードを持っているすべての人は、名前の変更が壊れないように、大量のコードを再検討する必要があります。

それは、Pythonライブラリで改善できるものがないと言っているわけではありません-あります！しかし、完璧さと物事を成し遂げることとの間には常にトレードオフがあります。それが彼らが「実用性は純粋さよりも優れている」と言う理由の1つです。

Answer 4

これは、PythonがJavaや.Netなどの企業の世界にバックアップされていないためです。

JavaライブラリをSunによって昇格させたい場合は、そのガイドラインに従います。これはPythonには当てはまりません。私は自分のコードを書いて、人々はそれをより良く見つけ、それはそれ自身で進化しなければなりません。

また、ほとんどのPython開発者はC ++、C、Java、.Netなどから来ています。そして、彼らは最初の日から本番コードを書き始めます。 Pythonの使いやすさに感謝します。そして、悪循環が続きます。

PEP8に来てコードをリファクタリングするのに1か月かかりました。

Answer 5

PEP 8は時間とともに変化しました。一部のモジュールは古い推奨事項に従います。これは、「イメージ」などのモジュールを使用するPILで確認できます。モジュールには、モジュール名に推奨される小文字の代わりに、単一のメインクラスが含まれ、C拡張では＆quot; c＆quot;を使用します。より現代的な＆quot; _＆quot;ではなく、プレフィックスプレフィックス。

一部のライブラリは、JavaやC ++などの他の分野の伝統に強く影響されている人々によって開発されています。これらの人々は、PEP 8推奨のlowercase_with_underscoresの代わりにCamelCaseをより頻繁に使用します。

ここでの答えは、スタージョンの法則を参照せずには完全ではありません。 ;すべての90％ががらくたです。＆quot;

Answer 6

  

[pythonライブラリ]の90％がクラッドですが、すべての90％がクラッドです

-スタージョン法（言い換え）

Answer 7

コードの品質が、設定した期待を満たしていないことに気付いたようです。おそらく学校から、またはベストプラクティスの書籍や上級開発者から。

いくつかの会社で働いた後、私は定期的にユニットテスト、ドキュメントコード、バージョン/ソース管理の使用（私が取ったすべての良いアドバイス）をするようにアドバイスされました。 。

コードの品質が低い場合があるという正しい印象を持っていると思いますが、それはあなたの期待にのみ基づいています。確かにnumpyなどは、期待するように設定された標準にコーディングされていなくても、非常に便利なパッケージです。

標準は意見であり、標準が低いという意見がある場合は、貢献することで標準を改善するか、そのまま受け入れて、例として役立つコードを作成してください。 1日を担当するジュニアを見つけます。

Answer 8

matplotlibについては、「pythoness」の改善プロジェクトがあります。 - http://www.scipy.org/PyLab

科学図書館に関することは、それらが科学者によって書かれており、専門のソフトウェア開発者によって書かれていないことです。さらに、これらの科学者はFortranを書くために使用されます。問題は、作業コードまたは美しいコードのどちらを使用するかです。

Answer 9

PEP8は、スタイル要件ではなく、スタイルガイドです。 「いつ矛盾するかを知る」必要があるとさえ述べています。個人的には、その中のいくつかのガイドラインが好きではありません。 snake_case よりも camelCase のほうが好きです。

また、絶対に必要な場合（デバッグなど）を除き、使用しているライブラリのソースコードを見ることはあまりありません。私は、ソースを見る必要がないほど十分に適切なライブラリーのドキュメントを望んでいます。

真剣に、なぜ matplotlib のソースコードが本来の目的を果たす限り、どのように見えるかを本当に気にしますか？

欠落している docstrings については同意します（内部要素ではなく公開要素であると仮定します）が、ライブラリを文書化する唯一の方法ではありません。

Answer 10

Pythonは、「プログラミングを行う必要がある」という解決策として、プログラマーではない人に（学校や貿易で）熱心に巻き上げられることに苦しんでいると思います。ここでは、この簡単で成熟したツールをお試しください。」

PHPが非常に大きな成功を収めた方法と同様に、コード品質が極度に低い（多くの場合、Pythonの平均コード品質はPHPの場合よりも優れています）-平均的なPHPユーザーは、平均的なPythonユーザーと同じですプログラミングの経験やスキルはあまりなく、この点で自分自身を改善するインセンティブはほとんどありません-彼らは何かを達成するために着手し、おそらく図書館の形でコミュニティと共有するのに十分価値があると考えましたが、彼らはコードを改善したり、自分自身を改善することに興味はありません（プログラミングスキルという意味です）。

解決策は、Pythonライブラリリポジトリ（PyPIなど）が提供パッケージの受け入れに関してより厳しいルールを持つことです。これは、品質を確保することを目的とするレビュープロセスでこれを処理します。リポジトリにパッケージを追加します。

Answer 11

PEP8は単なる慣習であり、要件ではありません。すべてのpythonプログラマーが共通のルールセットを遵守しなければならなかった場合、非常に悲しいことになります。わずかな問題に対する熱意を失います。

docstringの欠落に関する限り-はい、インタラクティブヘルプを使用すると役立ちますが、一部のドキュメントがある限り、通常は気にしません。使用しているライブラリのソースコードを読み取らないようにします。変更（書き換え）を開始する傾向があります。

Answer 12

他の言語との比較に関しては、言語デザインがここで大きな役割を果たすと思います。たとえば、Javaのような強い型付けの言語では、ライブラリに適切なドキュメントがない場合でも、メソッドシグネチャから多くの機能を推測できます。競合する * args はありません。

Answer 13

優れたソフトウェアドキュメントの例集はどうですか？
良い例は、ランダムウォークよりも少し速く全体的な改善につながる可能性があります。
コレクションは次のようなカテゴリに分割できます。
インラインドキュメント/ヘルプページ/チュートリアル/リファレンスマニュアル、Webページ/紙、写真/なし。
各エントリには、レビュアーが良いと思うなぜの単語があるはずです。
（どこ：stackoverflowのコーナー？）

Answer 14

nikow：私は自分自身にしか答えられません。ほとんどのPython（およびPHPまたはRuby、すべての動的な「スクリプト」言語）の作業は私のためだけに行われますが、常にリリースしています他の誰かがそれを便利だと思った場合、私の個人的なサイトですが、私のために機能する限り、私は満足しているので、私はドキュメントやQAプロセスを実行しません。

Answer 15

まあ、彼らは オープンソースです。そのため、十分なものであれば、時間とともに進化します。

これは、オープンソースの多くの美しさの1つです。

多くのドキュメントと「良い」を書くことはほとんど意味がありません。プロジェクトが存続するかどうかわからない場合はコードを作成します。それは時間の無駄です。

編集：もちろん、良いコードを書いても最初は痛いことはありませんが...多くの場合に十分です。そうでなければ、OSSに関しては膨大なオプションを享受できないと思います。

十分な人が特定の方法で行動すれば、何らかの説明があるかもしれないと思います。彼らはあなたを怒らせるためにただランダムにそうしているのではありません。

Answer 16

コードの品質*コメントの数*時間=定数

2つ選択！

matplotlibを使用しても問題はありませんでした。私はコードをよく見たとは言えません-それは素晴らしいライブラリです。想定されることを行います（無料！）