(jp) =
私はこれまで何度も議論してきました: プログラマーはコードの読みやすさの価値を過小評価すべきではありません。 今日は、私たち全員が当然のように考えている一般的な慣行、つまりケーシングに反対することをもう一度主張します。
些細なことのように思えますよね？ ラクダやヘビ、ケバブを使って言葉をつなぎ合わせることなど、誰が気にしますか? この質問にはまだ続きがあります。
コードの可読性を無視してはなりません。 ナビゲートのしやすさに影響します。 理解する あなたのコード。 私たちが使用する大文字と小文字の規則について話し合う必要があります。
# ちょっとした歴史
初期のプログラミング言語には、今日と同じ規則はありませんでした。 Lisp や COBOL などの言語は、ASCII が広くサポートされる前に誕生したため、その違いが説明されています。 大文字と小文字、およびアンダースコアなどの特殊文字は、50 年代から 60 年代前半のコンパイラではサポートされていませんでした。
Lisp と COBOL の両方で、ハイフンで単語を分割することができました。 Lisp のパーサーは、ハイフンが 2 つの単語の間にあるかどうか、またはそれを減算演算子として使用する必要があるかどうかを検出するのに十分スマートでした。 COBOL では、演算子として完全な単語しか持たないため、問題が完全に解消されます。 COBOL での減算は次のとおりです。
SUBTRACT data-item-1 FROM data-item-2ハイフンは予約済みのキーワードではないため、単語の分割に使用できます。
80 年代と 90 年代にプログラミング言語が成熟したとき、ハイフンは数学演算用に予約する必要があることが明らかになりました。 Lisp のスマートなアプローチのもう 1 つの問題は、現代の言語に対応できず、トークン化が大幅に遅くなることでした。
ほとんどすべてのプログラミング言語がトークン間の境界としてスペースを使用するため、スペースは明らかに使用できません。 それで、何が残っていますか？ これらの単語を読みやすく保ちながら、どうすれば複数の単語を 1 つにまとめることができるでしょうか?
# 今日のコンベンション
これが、今日 2 つの主要な規則が残っている理由です。 そしてスネークケース。 ちなみにアッパーキャメルケースはパスカルケースとも呼ばれます。
ほとんどの場合、言語は 2 つの大文字小文字のいずれかを好む傾向があります。 私達 できる コミュニティのガイドラインの問題だと言って、それで終わりです。
それ以上のものがあるというのが私の意見です。 単語を書くための、より優れた読みやすい方法がもう 1 つあります。 このブログ投稿の冒頭に基づいて、おそらくどれを推測できるでしょうか。 キャメル ケースは、スネーク ケースに比べてテキストを読みにくくします。
言葉を考えると user id、2 つの書き方を比較します。
userId
user_idそれは本当です: キャメルケースはよりコンパクトです: あなたはそれほど多くを書く必要はありません. しかし、人間の脳が実際にテキストを読む方法に最も近いのはどのスタイルですか?
これは、この議論で私にとって重要な唯一の議論です:
脳がコードを読んで理解するのをできるだけ簡単にするにはどうすればよいでしょうか?
コードが読みやすく、認知負荷が軽減されます。 認知負荷が少ないということは、人間がビジネス ロジックを書くなど、他のことを考えるためのメモリ スペースが増えることを意味します。
「アンダースコアを使用するだけで、すべてのことを？」 いいえ、アンダースコアだけではありません。 命名規則以外にも、読みやすいコードを作成するために必要なことはたくさんあります。 しかし、小さなことはすべて、より大きな解決策を得るのに役立ちます。