22

あなたの解釈によって、これは修辞的な質問かもしれませんし、そうでないかもしれませんが、それは本当に私を困惑させます. この規則はどのような意味がありますか? 命名規則には必ずしも韻や理由が必要ではないことは理解していますが、すでに人気のあるキャメルケースから逸脱するのはなぜですか? 私がどういうわけか行方不明になっている背後にある韻と理由はありますか? lower_case_with_underscores(そして、はい、私は PEP 8 全体を読みました。はい、それが単なる提案、ガイドなどであることを理解しています。)

私の本当の質問はこれだと思います:私はPythonライブラリを書いています。実際、運が良ければ、私の他のプロジェクトに比べてかなり大きなライブラリになるかもしれません。私はすでに可能な限り PEP 8 に準拠しようとしています。これまでのところlower_case_with_underscores、PEP 8 が関数名とメソッド名を指示するように維持しています。しかし、Twisted には camelCase をlogging、 には camelCase を、その他のほとんどすべてにキャメルケースを使用することを覚えておかなければならないことに悩まされています。どの命名規則を使用する必要がありますか? その理由は?

私がネーミングについてこれほど気にかけていて、それについて長い質問を書くのに十分なほど、人々を驚かせるでしょう。これらのことになると、おそらく私は少しOCDを持っています. 私はそれについて「個人的な意見」をあまり持っていません。最もよく使用されるものは何でも、この場合はキャメルケースになる傾向がありますが、それを見つけるとさらにイライラします私はおそらく、明示的対暗黙的および石で書かれたpythonの禅などに関するいくつかの永遠の法則を破っています。

4

10 に答える 10

53

camelCaseおよび/または(それ自体が議論の余地があります;-)あなたCamelCaseが最もよく知っている種類の環境で圧倒的に最も人気があるかもしれませんが、それはそれらを普遍的にすることはほとんどありません-またはC++と呼ばれるあいまいな言語について聞いたことがありません、そのおよびアルゴリズムなどで?!std::find_first_ofstd::replace_copy_if

したがって、PEP 8には、あなたが述べているように、「逸脱」はありません。JavaやC#などでより一般的なものに対するC++標準の規則への選択にすぎません。

独自のコードに対して何をすべきかについては、規則を選んでそれを守るだけです。一貫性は、他の考慮事項よりも重要です。私の雇用主は、すべての内部ソースに対してすべての言語で規則を使用してCamelCaseます (公開 API を公開する場合は必ずしもそうとは限りませんが、これは別の問題です) 。 !-) ですが、一貫性重要であるため、私はそれに固執し、(コード レビューで) 実際に強制するのに役立ちます。

スクリーン リーダーに頼ってコードを読み上げなければならない場合にのみ、大文字と小文字の区別に依存することが恐ろしい考えである理由を理解できると思います。ほとんどのスクリーン リーダーは、大文字と小文字の問題を特定するのにひどい仕事をします。本当に良い方法です。大文字と小文字の違いを簡単な聴覚的手がかりに変換するための強力で簡単な規則はありません(構成可能な優れたスクリーンリーダーでアンダースコアを「クリック」に変換すると、簡単になります)。視覚障害がまったくない人の場合は、疑いなく 90% 以上ですが、気にする必要はありません (包括的になり、完璧な視力というあなたの才能を共有していない人を助けたい場合を除きます... いや、誰があの人たちのことを気にかけているよね!?)。

しかし、一貫性は依然として重要であり、_every_body に役立ちます。

于 2009-11-16T05:02:20.953 に答える
18

アンダースコアのある小文字は優れているため、テキストは通常​​、本やニュースで読むことができます。.

于 2009-11-16T20:45:45.713 に答える
16

英語を母国語としない読者にとっては、wordByCamelCase よりも words_with_underscores の方が分離しやすいと他の文脈で述べられていると聞いたことがあります。視覚的には、別個の外国語を解析するための労力が少なくて済みます。

于 2009-11-16T04:55:10.803 に答える
7

歴史的に考えられる理由の1つは、多くのコンピューターに大文字と小文字が混在する機能がなかったことです。COBOLの時代には、プログラムはすべて大文字でした。80年代初頭、多くの「パーソナルコンピュータ」には大文字のフォントしか付属していませんでした。たとえば、AppleII+用の小文字のエクステンダーカードを入手できます。プログラムが混合ケースを許可し始めたとき、キャメルケースは人気がありませんでした。多くのプログラムは、以前はすべて大文字でしたものを使用し、小文字に変換しました。80年代を通じて、さまざまな言語が意味を大文字小文字に帰し、90年代にJavaはキャメルケース構文を普及させました。古い歴史を持つ言語、またはUNIXシステムプログラミングとより密接に結びついている言語は、大文字と小文字が混在するセマンティックな使用を避ける傾向があります。

于 2009-11-16T05:18:54.843 に答える
5

アンダースコア付きの小文字の規則は、UNIX API にまでさかのぼります。それらのシステムコール全体がこの規則にあります。

于 2009-11-16T04:55:38.307 に答える
3

これは単なる慣例ですが、多くの略語を扱う場合に便利です。

どのように EmailConfig を書きましたか (または EMailConfig でしたか)? HTTPリクエスト? email_config と http_request は、はるかに明確な規則です。

于 2011-09-30T12:24:50.587 に答える
2

ショップが使用する命名規則を使用してください。

彼らが既存の慣習が役に立たない (または標準を持っていない) ことに同意し、すべてのコードを新しく改良された (より標準的な) 慣習にクリーンアップする少しの作業を気にしない場合は、それを行うことができます。 .

于 2009-11-16T04:54:07.757 に答える
2

何をするにしても、一貫性を保つことが重要だと思います。アンダースコアを使用するように指示するいくつかのスタイル ガイド (たとえばGoogle Python Style Guide ) を見てきました。

個人的には、アンダースコア付きの小文字を使用すると、コードが読みやすくなると思います。

あなたはキャメルケーシングを使用していますか?私は気にしない!常にメガネモードがあります。:)

于 2009-11-16T05:02:36.217 に答える
1

aLongAndTotallyUnreadableMethodeNameとan_even_longer_but_perfectly_readable_method_nameの比較を思いついたのはマイヤーズでしたか?

すでに慣れている場合は、お気に入りのコンベンションがより自然に見えます。しかし、新しいプログラマーはアンダースコアを好むかもしれません(2001年のサンプルサイズN =私)。

APIが本当にひどい可能性があるため、一部の言語ではキャメルケースを使用していると思います。コードを折り返すことなくIDEに収めるために、余分なスペースが必要です。

例えば:

poly = geometryLibrary.polygonGenerator.createFromPointSet(myList.listContentsToPointset())
于 2009-11-16T06:08:09.510 に答える
0

自分に最も適したものを自由に選んでください。ただし、一般的な規則の 1 つを使用することを検討してください。これにより、他の開発者があなたのコードを簡単に理解できるようになります。

プロジェクトの存続期間中、コードを書く時間よりもコードを読む時間の方が長いことに注意してください。

于 2009-11-16T05:08:36.620 に答える