PHPネーミングでキャメルケース/キャメルケースまたはアンダースコアを使用する必要があるのはいつですか？

Question

私はPHP=を学んでおり、人々が名前を付ける方法には多くのばらつきがあることを確認しています。少なくとも自分自身と一貫していることを望んでいます。

キャメルケースをどこで使用し、アンダースコアをどこで使用するべきですか？

考え：

変数/プロパティ：_$userid_または_$user_id_または_$userID_
クラス：MyCustomClassまたはmyCustomClass
関数/メソッド：my_custom_function()またはmy_Custom_Function()

どんな考えでも感謝します。

Accountant م · Accepted Answer

PSR基本コーディング標準から（ https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md ）

クラス名StudlyCapsで宣言する必要があります。

クラス定数すべてのアンダースコアセパレータ付き大文字で宣言する必要があります。

メソッド名はcamelCaseで宣言する必要があります。

このガイドは、意図的に$ StudlyCaps、$ camelCase、または$ under_score プロパティ名の使用に関する推奨を回避します。

<?php namespace Vendor\Model; class Foo { const VERSION = '1.0'; const DATE_APPROVED = '2012-06-01'; private $StudlyCapsProp = null; protected $camelCaseProp = null; public $under_score_prop = null; public function fooBar() { } }

jgmjgm · Answer

多くの人々は多くの異なる好みを持っています、そして大部分は彼らはしばしばそれだけ、好みです。人々が慣れ親しんでいることや人気があることを除けば、平均的な人が特定のスタイルを好む理由についての韻律はほとんどありません。残念ながら、それはwhyのアイデアをあなたに与えない傾向があり、より実用的な問題に関して特定の規則を使用します。

多くの人々がPSRに依存しているため、規約を確立する必要がなくなります。どの開発チームでも、一貫性を容易にするために規則を確立する必要があります。 PSRは、自分で行うよりも時間を節約できます。便利なスタートですが、PSRの提案が信頼できるとは思わないでください。 PHPの書き方は最終的にはあなた次第ですが、ゼロから始める場合は、まず他の人がどのように書いているかを調査する必要があります。これは、同じ方法で行う必要があるという意味ではありませんが、それは始まりです。

PSRには特定の制限があります。

特定の科学ではなく合意によって確立され、矛盾する傾向があることを意味します。
完全ではありません。最終的に、オプションが指定されていない状況が見つかります。
それはもともとフレームワーク間の互換性を改善することを目的としていましたが、現在は互換性ではなく好みの問題を含みます。多くの場合、どの規則を使用するかによって、靴下が足にフィットする色と同じくらいの互換性が得られます。
フレームワーク間の互換性は、ほとんどのプロジェクトではなくても、多くのプロジェクトにとってほとんどまたはそれほど重要ではありません。特にクローズドソースの商用プロジェクトの場合。
それらは純粋に非公式のサードパーティからの提案です。誰かがコーヒーを反時計回りにかき混ぜることを好むかもしれませんし、インターネットを介してそれをお勧めしますが、実際にはどちらの方向にかき混ぜるかは、あなたまたはあなたがいるチーム次第です。スターバックス、ネロ、コスタは、時計回りにかき混ぜることを推奨する共同声明を発表するかもしれませんが、望まない場合は聞く必要はありません。

それはさておき、ラクダのケース（ラクダ）とヘビのケース（ヘビ）の間には、いくつかの意味的および実用的な違いがあります。

直接の違いは、ラクダは単語を分離するために少ない文字を使用することです。よりコンパクトです。オブジェクトをJSONに変換し、それを圧縮してブラウザーに送信する場合、これは常にそうであるとは限りません。ほとんどの場合、違いはごくわずかですが、キャメルは多少効率的に圧縮する場合があります。これについて心配する必要はないでしょう。一般に、2つの間で全体的に非常に些細で重要でないパフォーマンスの違いがあります。

コンパクトさには、人間の視点とプログラムの視点の両方からの代償が伴います。用語を分離して処理することは、より困難になる可能性があります。ファイルを解凍してから再度圧縮する前に、ファイルを解凍するのには理由があります。ここでは同じ原理が適用されますが、よりコンパクトです。ある意味で、それはまた不可逆です。つまり、区切り文字が文字を変更します。常に最初のキャラクターに当てはまるとは限らないので不便です。単純に分割して結合することはできません。重要な理由の1つは、一連のトークンを組み立てることなどによってプロパティとメソッドが自動的に決定される動的アクセスまたはメタコーディングのためです。

データベース内のテーブルを表すためのオブジェクトを自動的に作成し、リポジトリーとして機能するジェネレーターを作成した場合、そのクラスでメソッドを生成して、各列でフェッチできるようにすることができます。 _get_by_username|get_by_email_または_getByUsername|getByEmail_のどちらかを見ていた可能性があります。

_(get_by|getBy)($field, $value)_があった場合、フィールドにユーザー名または電子メールを渡します。これらは元のフォームです。この場合、クラスを作成するときに各フィールドをucfirstする必要があります。これをさらに進めて、___call_を使用して動的にこれらを提供するとどうなりますか？その場合、少なくともlcfirstでラクダを変換する必要があるたびに、ヘビの場合と同様に、文字列の最後にボルトで固定するだけで、変換や心配をせずに1対1でマッピングされます。それが終わりか始めかであるならば、たくさん。クラスメンバーへの2つのフィールド（操作とフィールドなど）へのマッピングを検討してください。

追加または大文字の場合はlcfirst、大文字と小文字で分割、lcfirstを2番目以降にマップ
分割、ucfirstからallへのマッピング、それ以外の場合は休憩への追加、連結

対：

split
加わる

Snakeはデフォルトでトークンを元の形式で保持します。そうでない場合は、簡単に分離された単語を個別に変換する方が簡単です。

PHPでメタコーディングを使用してそれを最大限に活用することは非常に一般的です。これには、文字列ベースのランタイムポリモーフィズムがかなり含まれます。最終的には、動的にコーディングしたいラクダよりも、ヘビの方が多くのメリットがあります。

ifCamelCaseWereReallyThatGreatEveryoneWouldBeAnsweringProgrammingQuestionsOnStackOverFlowLike This。 asYouCanSeeForAnythingButTheShortestPhrasesShortFormQuicklyBecomesTiring。 YouCanUallyallyGetAwayWithItInProgrammingAsItsInSmallDosesAndInASeaOfWhiteSpace。 anotherAnnoyanceWithCamelCaseIsWhenYouHaveAbbreviationsOrSingleLetterWords。 itNotAllGood。

意味的には、名前空間にヘビを使用する傾向があり、フレーズでは使用しません。逆に、ラクダは、平易な英語で順次またはタイトルとして読む小さなフレーズや文章に使用される傾向があります。これは特にOOPでよく見られます。クラス名は最初に最も一般的に必要とされる分類の層を提供する傾向があり、今日はネストされた名前空間をますます許可する傾向があります（PHPで完全にサポートされています）。つまり、英語の単語を組み合わせてフレーズを作成するのではなく、異なるカテゴリのセットの単語を順番に組み合わせて、ヘビを使用するのが慣例です。その場合は、メタコーディングを実行する可能性が高くなります。

たとえば、database_statement_row_read_next()は、完全に有効な、または典型的な英語のフレーズではありません。末尾の_Database\Statement::readNextRow_は、有効で標準的な英語の表現になります。

英語はより快適で親しみやすいですが、いくつかの問題があります。物事は常に同じ順序であるとは限らず、同じであると言える場合もあります（一貫性がないため）メタコーディングが厄介になる可能性があります。メタコーディングは、単語のセットを処理し、時には必要とせずに組み合わせるのが自然です。 1つの単語ではなく2つの単語、順序または単語、句の順番など.

経験則として、名前を普通の英語の断片として書き出す場合は、主にラクダを使用する必要があります。これは、慣例が圧倒的に多いためです。英語での順序と一致する単語の順序に厳密に注意を払わないが、分類と編成に注意を払う場合、明示的な区切り文字が標準になる傾向があります。

彼らがラクダについてあなたに言っていないことは、慣例により、あなたはほとんどいつもいつもそれを書くことが期待されていると同時に、時々うまくいかない英語の文法規則や時折のカテゴリーの命名にも従うことです。

より正しい用語は次のとおりです。

アンダースコア区切り= alpha_beta
大文字と小文字を区別= alphaBeta
大文字と小文字を区別= AlphaBeta

最後のケースでは、最初の大文字は区切られません。

プログラミングの世界では、一般に、大文字と小文字を区別する（大文字と小文字を区別しない）を使用してOOPの標準にする傾向があります。一般的に言えば、PHPの場合も同様ですが、特にOOPメソッドなどの関連する名前の場合は、.

逆に、手続き型、関数型、およびローカル変数の場合、人気のある言語の間では、ヘビを使用する傾向がかなり強くなります。

選択するものが何であれ、できる限り一貫性を保つようにしてください。違いがある場合は、その理由と慣例の両方が必要です。 2つを混合している場合は、1つをファサードの後ろに置くことができます。ラクダは人間の消費を目的としており、メタコーディングに必要な場合はヘビがファサードの後ろにネストできるような有効な英語として解釈される傾向があります。

特にあなたの提案のために：

変数/プロパティ：

useridは読みにくくなり、他の単語を作成することにもなります。また、別の標準形式に変換することもできません。
_user_id_で結構です。
userIdで結構です
userIDは不良です。 user_idではなくuser_i_dに変換されること。

クラス：

MyCustomClassは、クラス名がタイトルであり、大文字にする必要があるという点でも理にかなっている、普遍的で非常に一貫した標準です。
myCustomClassクラス名を付けるつもりだったときに、誰かがメソッドを置くように見えるかもしれません。

関数/メソッド：

_my_custom_function_これは、英語の文法に固執するのではなく、名前空間に使用する英語の単語の慣習からは、_function_custom_または_function_default_。
_my_Custom_Function_は、機能する最も単純なものではありません。大文字は冗長であり、専用の文字区切りの隠された利点を明らかにする目的には使用できません。大文字と小文字を保持できます。

一部の人々は、両方を使用して1つ以上のレベルのネストを提供することに夢中になるかもしれません。それのためにあなたが何をするにしても、それは醜くなります。これは、CSV内のCSVまたは2次元配列と同じ概念です。ラクダとヘビの両方が単一の単語の配列を表すために使用されます。 2つの単語の配列を表現する場合は、複数の文字の区切り文字を含む可能性のある2つ以上の区切り文字の組み合わせなど、特別なものが必要になります。あなたがそのような状況にいる場合、実際にはラクダやヘビだけでほとんどの場合十分なYAGNIのケースである可能性が非常に高いです。それらを混同する場合は、それは表面的なものではなく、文書化されているか明白な戦略の一部である必要があります。

これに関連する例は、_get_by_username|get_by_email_の場合です。常に_[$operation, $field]_を使用することにしたかもしれません。操作とフィールドの両方を、それぞれ複数のワードで記述する必要がある場合があります。これは、フィールドと操作の両方にラクダを使用することにつながる可能性がありますが、フィールドと操作を分離するためにヘビ。たとえば、_getBy_username_、_deleteBy_username_、または_getBy_firstName_になります。それは美しくありませんが、実用的な目的に役立つと主張されるかもしれません。名前空間を提供するためにスネークで開始し、次にOOP名前空間、クラス、およびメソッドを使用して取得するものである）キャメルで終了することもいくらか一般的です。理由はありますが、多くの場合、このようなスタイルの混合は、代わりに、洗い流されていないトイレに通じる悪いコード臭になりがちです。