【エンジニアの常識】変数の命名規則である〇〇ケースについて

どうも、現役アプリエンジニアで、京都のプログラミングスクール「テクテック」を運営している、クウルス(@Qoo_Rus)と申します。

私がプログラミング勉強をし始めたときに、変数の名前の付け方について先輩に指摘をされました。

エンジニアの目指して勉強中の方や、駆け出しのエンジニアの方で、「〇〇ケース」という命名規則を聞いたことがないという方は多いです。

そこで今回は、「〇〇ケース」について、いくつか代表的なものを紹介し

について解説していきます。

〇〇ケースのまとめ

キャメルケース(camel case)

camelCase

のように、単語の切れ目を大文字にします。

私が普段の業務で一番使う言語のSwiftでは、キャメルケースの使用場面が多いです。

キャメルは英語でラクダ。

大文字の部分をラクダのコブに見立てて、キャメルケースと余分だそうです。

アッパーキャメルケース(upper camel case)

UpperCamelCase

先頭を大文字にしたキャメルケースです。

パスカルケースと呼ばれることもあるみたいですが、私は普段アッパーキャメルケースと呼んでいます。

ロウワーキャメルケース(lower camel case)

lowerCamelCase

先頭を小文字にしたキャメルケースです。

単にキャメルケースと呼ぶ場合は、アッパーではなくロウワーのことを指していることが多い気がします。

スネークケース(snake case)

snake_case

単語の切れ目をアンダーバー(_)にします。

昔の私がSwiftでコードを書いているときに、キャメルケースで書くべきところを間違って書いてしまったやつですね。

ケバブケース(kebab case)

kebab-case

単語の切れ目をハイフン(-)にします。

チェインケース(chain case)と呼ばれることもあるそうです。

そのほかいろんなケース

よく名前を見かけるものは、ここまで紹介した

• キャメルケース
• スネークケース
• ケバブケース

ですが、他にもあります。

CONSTANT_CASE

コンスタントケース（アッパースクリーミングケース、アッパーケース）と呼ばれるケースは、全て大文字かつ単語の切れ目でアンダーバーです。

Train_Case

トレインケースは単語先頭が全て大文字かつ単語の切れ目でアンダーバーです。

どの場面でどのケースを使うべき？

ここまで記事を読んでいただいた初心者の方は

と思うことでしょう。

結論から言うと、基本的には使っているプログラミング言語の公式ガイドラインを読むべきです。

プログラミング初心者向けの本に書いてある多くは、命名規則の使い分けを公式ガイドラインのルールにしたがっていますが、中には間違って書いていることもあるかもしれないので、公式ガイドラインに一度目を通すことをオススメします。

Swiftにおける変数の場合

では、私が普段よく使っているSwiftの場合だとどうなるのでしょうか。

Swiftの場合は

で書くことになっています。

// クラス、構造体、列挙体、プロトコルはアッパー

class SampleClass {}

struct SampleStruct {}

enum SampleEnum {
  case hoge
  case fuga
}

protocol SampleProtocol {}

// 変数名、関数名はロウワー

var sampleVariable: SampleClass

func sampleFunction() {}

Swift言語を開発したApple公式のガイドラインである

“The Swift Programming Language (Swift5.1)”

にキチンと記載されているルールです。

“Whenever you define a new structure or class, you define a new Swift type. Give types UpperCamelCase names (such as SomeStructure and SomeClass here) to match the capitalization of standard Swift types (such as String, Int, and Bool). Give properties and methods lowerCamelCase names (such as frameRate and incrementCount) to differentiate them from type names.”

抜粋:: Apple Inc. “The Swift Programming Language (Swift 5.1)”。 Apple Books https://books.apple.com/jp/book/the-swift-programming-language-swift-5-1/id881256329

公式ガイドラインは基本的に英語が多いので、英語がニガテな方はGoogle翻訳に助けてもらいつつ読んでみるのがオススメです！

たった1秒で和訳完了！エンジニアの英語勉強に役立ちまくる神ツール英語の文章をネットで読む時に使える便利なツール「Google翻訳Chrome拡張機能」「Chromeの検索エンジン追加」を紹介します。エンジニアがネット上の英語記事を読む時に役立つだけでなく、全ての英語学習者が効率的に学習することができます。...

なぜ言語ごとに命名規則があるの？

そもそも命名規則とは何のために存在するのでしょうか？

基本的に命名規則は

ソースコードを読みやすくしたいから

という理由で作られていることが多いです。

しかし、先輩にキャメルケースで書くべきところをスネークケースで書いてしまったときに、私は

と思ったんですよね。

ところが、実はキャメルケースでなくてはいけない理由がキチンとあったんです。

テキストエディタやIDEの機能に合わせる必要があるから

多くの場合でSwiftを書くときはiOSアプリを制作するための「Xcode」というIDE（統合開発環境）を使うのですが、Xcodeにはプログラミング作業をやりやすくするための工夫がたくさんあります。

プログラミングが楽になる工夫の中に

自動で変数名やクラス名を作っておいてくれる機能

が色々あるのですが、そこで生み出される変数名やクラス名は当然公式ガイドラインにしたがったルールになっています。

勝手に自分の判断でスネークケースを使ってしまったら、Xcodeが自動で書こうとしてくれるキャメルケースと自分の書いたスネークケースがごちゃ混ぜになってしまうハメに。

ほかの言語でも同じで、エディタやIDEの機能に合わせてルールが作られているんです。

言語の仕様上規則に従わないといけない時があるから

言語仕様上従う必要があるということも多いです。

Swiftも言語仕様や標準ライブラリの設計の時点で、アッパーキャメルケースとロウワーキャメルケースの使い分けは決まっています。

単に「見やすい・書きやすい」のではなく、ルールに従わないとキチンと動作しないことがあるので、必ずプログラミング言語ごとの公式ガイドラインのルールを守る意識を持っておくべきです。

命名規則の名前を知った上でキチンと使用場面を確認するクセを大切に

私が普段使用している言語であるSwiftが中心の紹介になりましたが、ほかの言語においても命名規則はプログラミングをやる上で非常に大切です。

それでは、再度おさらいをしておきましょう。

命名規則に限らず、ソースコードを読みやすく書くというのは非常に大切です。

全てのエンジニアが読むべき本として『リーダブルコード』がよく紹介されるので、ぜひ『リーダブルコード』を参考に読みやすいコードを意識しましょう。