エンジニア

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

スネークケース キャメルケース swift

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

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

Swiftの変数名ってスネークケースでつけるんじゃなくて、普通はキャメルケースでつけるんだよ
クウルス
クウルス
スネークケース?キャメルケース?

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

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

  • どの場面でどのケースを使えば良いのか
  • なぜ命名規則を守る必要があるのか

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

クウルス
クウルス

エンジニアの間では常識なので、初心者は今のうちにしっかり押さえておきましょう!

〇〇ケースのまとめ

キャメルケース(camel case)

camelCase

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

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

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

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

クウルス
クウルス
そしてキャメルケースには2種類に分けられます。

アッパーキャメルケース(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)名、構造体(struct)名、列挙体(enum)名、プロトコル(protocol)名をアッパーキャメルケース
  • 変数名、関数(メソッド)名をロウワーキャメルケース

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

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

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

“The Swift Programming Language (Swift 5.1)”

LANGUAGE GUIDE – Structures and Classes

https://docs.swift.org/swift-book/LanguageGuide/ClassesAndStructures.html

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

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

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

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

基本的に命名規則は

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

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

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

クウルス
クウルス
別にスネークケースでも読みやすいだからいいじゃん

と思ったんですよね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

命名規則について
  1. キャメルケースは大文字で単語を分ける
  2. スネークケースはアンダーバーで単語を分ける
  3. ケバブケースはハイフンで単語を分ける
  4. 命名規則の使い分けは公式ガイドラインにしたがうこと

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

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

Web制作会社 取締役
クウルス
EarthCampus株式会社 取締役。 Webサイトの受注制作・運営をしています。 TwitterではITビジネスにつながる技術的な学びを発信。 趣味はエレクトーンと格闘ゲーム。
\ Follow me /