アッパーキャメルケース

アッパーキャメルケース: upper camel case)とは、ソフトウェア開発において広く利用される命名規則の一つであり、各単語の頭文字大文字で表記し、単語間にスペース やアンダースコア_を用いずに連結する形式を指す(例:UpperCamelCase)。この命名規則は、可読性と一貫性を向上させる目的で用いられることが多い[1][2]パスカルケース: Pascal case[注釈 1])と呼ばれることも多い。.NETのガイドライン[3]では、先頭の語も含めて各単語の頭文字を大文字にするスタイルをパスカルケース、先頭の語のみ頭文字を小文字にするスタイルをキャメルケースローワーキャメルケース[注釈 2])としており、プログラミングの文脈でキャメルケースといえば後者のスタイルを指すことが多いが、場合によってはどちらもキャメルケースと呼ばれることがある。これらを厳密に区別するために「アッパーキャメルケース」という語が用いられる[注釈 3]。先述のように「パスカルケース」は厳密には.NETの文脈で使用されるものであるため、より広範な文脈では、同じスタイルでも「アッパーキャメルケース」を使用する。

ただし、プログラミングにおける命名規則の形式に対する名前は、国際的に標準化されているわけではない[19][20]

アッパーキャメルケースは、特にオブジェクト指向プログラミング言語においてクラス名や型名などに用いられることが一般的である。例えば、「CustomerAccount」や「EmployeeRecord」のように、各単語の先頭文字を大文字で始めることで、識別子の構造を直感的に理解しやすくなる[21][22]

この命名規則の利用は、コードの可読性やメンテナンス性を高めるための重要な手法の一つであり、特に大規模なシステム開発において、その効果が顕著である。さらに、アッパーキャメルケースは、他の命名規則(例:スネークケースケバブケース)と組み合わせて使用されることもあるが、その際には一貫性を保つことが重要である[23][24]

アッパーキャメルケースは、英語圏を中心に広く普及しているが、非英語圏においても、その利便性から多くのプログラマーに支持されている[25][26][27]。本ページでは、アッパーキャメルケースの歴史、利点、適用例について詳細に解説する。

歴史

以下にアッパーキャメルケースの歴史を示すが、ここで示すのは「アッパーキャメルケースのスタイル」についての歴史であり、「アッパーキャメルケース」という呼称が用いられ始めた時期については情報がない。

1970年代:コンピュータ科学の黎明期

1970年代は、コンピュータ科学が急速に発展し始めた時期であり、初期のプログラミング言語が数多く開発された。アッパーキャメルケースの起源は、この時期に遡ることができる[28][29]。当時のプログラマーたちは、より読みやすく、理解しやすいコードを書くための方法を模索していた。特に、言語処理系やコンパイラの開発において、識別子の命名規則が重要な課題となっていた[30][31][32]

1980年代:オブジェクト指向プログラミングの台頭

1980年代に入ると、オブジェクト指向プログラミング(OOP)が注目を集め始めた。SmalltalkC++といったOOP言語の普及に伴い、クラス名やメソッド名にアッパーキャメルケースが用いられるようになった[33][34][35]。これにより、コードの可読性が向上し、ソフトウェアの開発や保守が容易になった。特に、クラス名や型名の一貫した表記は、大規模プロジェクトにおけるチーム開発において重要な役割を果たした。

1990年代:言語規範の確立

1990年代は、JavaC#など、アッパーキャメルケースを標準的な命名規則として採用するプログラミング言語が登場した時期である[1][36][37]。これらの言語は、公式なスタイルガイドコーディング規約においてアッパーキャメルケースの使用を推奨しており、プログラマーにとってのデファクトスタンダードとなった[38][39]。また、この時期には、アッパーキャメルケースを含む命名規則に関する研究や文献も増加し、理論的な基盤が確立された[40][41]

2000年代:Web開発の普及と標準化

2000年代には、Webアプリケーションの開発が急速に普及し、JavaScriptTypeScriptといった新しい言語が登場した[42][43][44]。これらの言語でも、アッパーキャメルケースが広く用いられるようになり、クライアントサイドサーバサイドの両方で一貫した命名規則が適用されるようになった[45]。また、オープンソースプロジェクトやライブラリにおいても、アッパーキャメルケースが標準として採用されることが一般的となった[46][47]

2010年代以降:多言語対応とグローバル化

2010年代以降、プログラミングのグローバル化が進み、非英語圏のプログラマーにもアッパーキャメルケースの使用が広がった[48][49][50]。多くのプログラミング言語が国際化対応を進める中で、アッパーキャメルケースは言語を問わず広く受け入れられる命名規則として定着した[51][52][53][54][55]。また、コードレビューや自動フォーマットツールの進化により、命名規則の一貫性を保つことが一層容易になり、ソフトウェア開発の品質向上に寄与している[56][57]

利点

可読性の向上

アッパーキャメルケースの最も顕著な利点は、コードの可読性を大幅に向上させる点にある。各単語の頭文字を大文字にすることで、識別子の構成要素が直感的に認識しやすくなり、プログラマーは容易にコードの意味を理解できる。例えば、「CustomerAccount」という識別子は、「customeraccount」と比べて視覚的に分かりやすく、誤読のリスクを低減する[1][58][59][60][61]

一貫性の維持

アッパーキャメルケースは、命名規則に一貫性をもたせる手段として優れている[1][62][63]。特に、大規模なソフトウェアプロジェクトにおいて、複数のプログラマーが協力してコードを開発する場合、命名規則の一貫性は極めて重要である。一貫した命名規則は、コードレビューや保守作業を効率化し、コードの品質向上に寄与する。アッパーキャメルケースは、そのシンプルさと明瞭さから、プロジェクト全体で容易に適用できる。

自動ツールとの親和性

現代のソフトウェア開発においては、コードフォーマッターや静的解析ツールなど、自動化ツールが広く利用されている。アッパーキャメルケースは、これらのツールと高い親和性をもつ。Qodana[64]、SonarQube[65]Checkstyle[66]ESLint[67]、Codacy[68]などの多くのツールは、識別子の命名規則を検査し、アッパーキャメルケースの使用を推奨する。これにより、コードの一貫性が保たれ、バグの発生を未然に防ぐことができる。

言語間の互換性

アッパーキャメルケースは、複数のプログラミング言語で広く採用されている[69][70][71][72]ため、異なる言語間でのコードの移植性が向上する。例えば、Java、C#、JavaScriptなど、様々な言語でアッパーキャメルケースが標準的に用いられているが、具体的には、C#ではクラス名や型名にアッパーキャメルケースが多用される一方、Javaではクラス名に主に使用されている。異なる言語での開発プロジェクト間でも命名規則の違いによる混乱を避けることができる。特に、マルチプラットフォーム開発やマイクロサービスアーキテクチャにおいて、その利点は顕著である。

メンテナンス性の向上

アッパーキャメルケースは、コードのメンテナンス性を向上させる命名規則の一つである[73][74]。明確で一貫した命名規則は、コードの理解を容易にし、新たな機能追加やバグ修正の際に役立つ。プログラマーが識別子の意味を迅速に把握できるため、変更や修正作業がスムーズに行える。これにより、メンテナンスコストの削減と共に、コードの品質を維持することが可能となる。

欠点

可読性の問題

アッパーキャメルケースを使用すると、「I」と「l」(大文字のアイと小文字のエル)や「O」と「0」(大文字のオーと数字のゼロ)のような文字の視覚的な見分けが困難になることがある。このため、特定の単語を組み合わせた場合、一つの単語の区切りが分かりにくくなることで理解が難しくなる場合がある[75][76]

言語やツールとの互換性

一部のプログラミング言語やツールでは、アッパーキャメルケースが推奨されていない場合がある。例えば、JavaScriptでは、変数名は基本的にキャメルケースが推奨されているため、アッパーキャメルケースを使用するとコードのスタイルが一貫しないことがある[77][78]

文化や言語による影響

特定の文化や言語に依存したケーススタイルの影響も無視できない。英語以外の言語を母国語とするプログラマーにとって、単語の区切り方が直感的でない場合があり、結果として誤解や誤った使用が生じる可能性がある[76][79]

視覚的な目立ちすぎ

アッパーキャメルケースは、全ての単語の頭文字を大文字にするため、視覚的に目立ちすぎることがある。特に、クラス名やメソッド名が多用される場面では、コード全体として大文字が頻出することになり、読みにくく感じる場合がある[75][76]

適用例

オブジェクト指向プログラミングにおけるクラス名

アッパーキャメルケースは、オブジェクト指向プログラミング(OOP)においてクラス名の命名に広く利用されている。

例えば、JavaやC#といった言語では、クラス名をアッパーキャメルケースで命名することが標準となっている。

以下に具体的な例(Java)を示す。

public class CustomerAccount {
    private String accountNumber;
    private double balance;
    
    public CustomerAccount(String accountNumber) {
        this.accountNumber = accountNumber;
        this.balance = 0.0;
    }
    
    public void deposit(double amount) {
        this.balance += amount;
    }
    
    public double getBalance() {
        return this.balance;
    }
}

この例では、「CustomerAccount」というクラス名がアッパーキャメルケースで命名されており、各単語の頭文字が大文字で表記されている。これにより、クラスの名前が一目で理解しやすくなり、他のクラスやメソッドとの区別が明確になる。

メソッド名やプロパティ名

アッパーキャメルケースは、メソッド名やプロパティ名にも適用されることが多い。

特に、C#やTypeScriptなどの言語では、プロパティ名をアッパーキャメルケースで命名することが推奨されている。

以下にその例(C#)を示す。

public class Employee {
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int EmployeeId { get; set; }
    
    public void DisplayEmployeeInfo() {
        Console.WriteLine("Employee: {0} {1}, ID: {2}", FirstName, LastName, EmployeeId);
    }
}

この例では、「FirstName」「LastName」「EmployeeId」というプロパティ名がアッパーキャメルケースで命名されており、視覚的に識別しやすくなっている。また、メソッド名「DisplayEmployeeInfo」も同様にアッパーキャメルケースで命名されており、メソッドの機能が直感的に理解できる。

デザインパターンの実装

デザインパターンの実装においても、アッパーキャメルケースが利用されることが一般的である。

例えば、シングルトンパターンやファクトリーパターンなどのクラス名やメソッド名にアッパーキャメルケースが適用される。

以下にシングルトンパターンの実装例(Java)を示す。

public class Singleton {
    private static Singleton instance;
    
    private Singleton() {}
    
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

この例では、「Singleton」というクラス名がアッパーキャメルケースで命名されており、クラスの役割が明確に示されている。

Web開発における命名規則

Web開発においても、アッパーキャメルケースが広く利用されている。

特に、JavaScriptやTypeScriptでは、クラス名にアッパーキャメルケースが適用されることが多い。

以下にJavaScriptのクラス定義の例を示す。

class UserProfile {
    constructor(userName, email) {
        this.userName = userName;
        this.email = email;
    }
    
    displayUserInfo() {
        console.log(`User: ${this.userName}, Email: ${this.email}`);
    }
}

let user = new UserProfile("JohnDoe", "[email protected]");
user.displayUserInfo();

この例では、「UserProfile」というクラス名がアッパーキャメルケースで命名されており、コードの可読性と一貫性が保たれている。

フレームワークやライブラリの命名規則

アッパーキャメルケースは、様々なフレームワークやライブラリの命名規則にも取り入れられている。

例えば、.NET FrameworkSpringフレームワークでは、クラス名にアッパーキャメルケースが使用される。

以下にSpringフレームワークを用いたJavaの例を示す。

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseBody;

@Controller
public class UserController {
    
    @RequestMapping(value = "/user", method = RequestMethod.GET)
    @ResponseBody
    public String getUser() {
        return "User data";
    }
}

この例では、「UserController」というクラス名がアッパーキャメルケースで命名されている。Springフレームワークの命名規則に従うことで、コードの一貫性と理解のしやすさが保たれる。

API設計における命名規則

API設計においても、アッパーキャメルケースは重要な役割を果たす。

RESTful APIのエンドポイントやGraphQLスキーマ定義において、アッパーキャメルケースを使用することで、エンドユーザーにとって理解しやすいインターフェースを提供することができる。

以下にGraphQLスキーマの例を示す。

type Query {
    getUser(userId: ID!): User
}

type User {
    userId: ID!
    userName: String!
    email: String!
}

この例では、「Query」「User」タイプ名がアッパーキャメルケースで命名されており、スキーマの構造が直感的に理解できる。

マイクロサービスアーキテクチャにおける命名規則

マイクロサービスアーキテクチャでは、複数の独立したサービスが連携してシステム全体を構成する。この際、各サービスのクラス名やメソッド名にアッパーキャメルケースを使用することで、一貫した命名規則を維持し、サービス間のインターフェースが分かりやすくなる。

以下にマイクロサービスの一例を示す。

package main

import (
    "fmt"
    "net/http"
)

type OrderService struct{}

func (o *OrderService) CreateOrder(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "Order created")
}

func main() {
    orderService := &OrderService{}
    http.HandleFunc("/createOrder", orderService.CreateOrder)
    http.ListenAndServe(":8080", nil)
}

この例では、「OrderService」というクラス名および「CreateOrder」というメソッド名がアッパーキャメルケースで命名されている。これにより、サービスの役割と機能が明確に示されている。

教育・学習資料における使用例

教育学習資料においても、アッパーキャメルケースの使用は推奨されている。

特に、プログラミング入門書やオンライン教材では、アッパーキャメルケースを使用することで、初心者に対して一貫した命名規則を教えることができる。

以下にPythonの入門書の例を示す。

class Student:
    def __init__(self, studentId, studentName):
        self.studentId = studentId
        self.studentName = studentName
    
    def displayStudentInfo(self):
        print("Student ID:", self.studentId)
        print("Student Name:", self.studentName)

student = Student(1, "Alice")
student.displayStudentInfo()

この例では、「Student」というクラス名がアッパーキャメルケースで命名されている。これにより、学習者は命名規則の重要性を理解しやすくなる。

商標など

商品名商標としてもアッパーキャメルケースが採用されることがある。

PlayStation[80]McDonald's[81]など。このように、アッパーキャメルケースは特別にプログラミングにおいてのみ使用されるというものでもないが、この用語を強いて使うのはプログラミングの分野であることが多い[82][83]

命名規則一覧

名称 英語表記 説明 表記例
スネークケース snake case 単語間をアンダースコア(_)で繋ぐ形式。 example_variable
スクリーミングスネークケース screaming snake case 単語間をアンダースコア(_)で繋ぎ、全て大文字にする形式。「アッパースネークケース(upper snake case)」や「コンスタントケース(constant case)」とも呼ばれる[84] EXAMPLE_VARIABLE
キャメルケース camel case 各単語の頭文字を大文字にし、単語を連結する形式(最初の単語のみ頭文字が小文字)。.NETの文脈で使用。 exampleVariable
ローワーキャメルケース lower camel case キャメルケースと同じ形式だが、フレームワークや言語に依存しない表現。 exampleVariable
パスカルケース Pascal case 各単語の頭文字を大文字にし、単語を連結する形式(キャメルケースと似ているが、最初の単語の頭文字も大文字)。.NETの文脈で使用。 ExampleVariable
アッパーキャメルケース upper camel case パスカルケースと同じ形式だが、フレームワークや言語に依存しない表現。 ExampleVariable
ケバブケース kebab case 単語間をハイフン(-)で繋ぎ、各単語の頭文字を小文字にする形式。

「チェインケース / チェーンケース(chain case)」とも呼ばれる[84]

example-variable
トレインケース train case 単語間をハイフン(-)で繋ぎ、各単語の頭文字を大文字にする形式。 Example-Variable
ドットケース dot case 単語間をドット(.)で繋ぐ形式。 example.variable

脚注

[脚注の使い方]

注釈

  1. ^ 「Pascal」は固有名詞であるため、先頭を小文字にしてはならない。
  2. ^ 「ローワー」という読み仮名表記は、「大辞林第四版[4]」「大辞泉[5]」「日本語シソーラス第2版[6]」「コトバンク[7]」「IT用語辞典[8]」「goo辞書[9]」「シマウマ用語集[10]」など、様々な辞書で採用されている表記である。
  3. ^ パスカルケースと同じ意味でも、他の言語では「アッパーキャメルケース」が用いられる。Java[11][12][13][14]、Python[15][16][17][18]など。

出典

  1. ^ a b c d “Programming Naming Conventions – Camel, Snake, Kebab, and Pascal Case Explained” (英語). freeCodeCamp.org (2022年8月22日). 2024年6月27日閲覧。
  2. ^ Sahlmann, Diedrich (1989), Sahlmann, Diedrich, ed. (ドイツ語), Beispiele und Übungen zur Strukturierten Programmierung, Springer, pp. 109–131, doi:10.1007/978-3-642-95582-2_7, ISBN 978-3-642-95582-2, https://doi.org/10.1007/978-3-642-95582-2_7 2024年6月27日閲覧。 
  3. ^ KrzysztofCwalina: “Naming Guidelines - Framework Design Guidelines” (英語). learn.microsoft.com (2022年10月4日). 2024年6月28日閲覧。
  4. ^ “大辞林第四版”. 三省堂. 2024年7月1日閲覧。
  5. ^ “大辞泉”. 大辞泉. 2024年7月1日閲覧。
  6. ^ “日本語シソーラス 第2版 類語検索辞典”. 大修館書店. 2024年7月1日閲覧。
  7. ^ “ローワーキャメルケース”. コトバンク. 2024年7月1日閲覧。
  8. ^ “キャメルケース”. IT用語辞典. 2024年7月1日閲覧。
  9. ^ “ローワーキャメルケース”. goo辞書. 2024年7月1日閲覧。
  10. ^ “キャメルケース”. シマウマ用語集. 2024年7月1日閲覧。
  11. ^ “NamingConventions.UpperCamelCase (DataStax Enterprise Java Driver - Binary distribution 1.9.0 API)”. docs.datastax.com. 2024年7月1日閲覧。
  12. ^ “XML Standards and Conventions”. docs.oracle.com. 2024年7月1日閲覧。
  13. ^ “Style Guide | SoftConst2x | edX”. courses.edx.org. 2024年7月1日閲覧。
  14. ^ “Google Java Style Guide”. google.github.io. 2024年7月1日閲覧。
  15. ^ “CS 1110: Notes on Style”. www.cs.cornell.edu. 2024年7月1日閲覧。
  16. ^ “BytePlus | Business growth through superior technology”. docs.byteplus.com. 2024年7月1日閲覧。
  17. ^ “Coding Style — PyLith 4.1.1 documentation”. pylith.readthedocs.io. 2024年7月1日閲覧。
  18. ^ “Conventions — MSOLVE 2024 documentation”. 2023.help.altair.com. 2024年7月1日閲覧。
  19. ^ Cwalina, Krzysztof; Abrams, Brad (2008-10-22) (英語). Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries. Pearson Education. ISBN 978-0-321-60500-9. https://www.google.co.jp/books/edition/Framework_Design_Guidelines/39d1wZ598ecC?hl=ja&gbpv=1&dq=Framework+Design+Guidelines:+Conventions,+Idioms,+and+Patterns+for+Reusable+.NET+Libraries&printsec=frontcover 
  20. ^ Skeet, Jon (2019-03-23) (英語). C# in Depth: Fourth Edition. Manning Publications. ISBN 978-1-61729-453-2. https://www.google.co.jp/books/edition/C_in_Depth/yEoZtAEACAAJ?hl=ja 
  21. ^ “OO Naming Conventions” (英語). atomicobject.com. 2024年6月27日閲覧。
  22. ^ “テレコミュニケーションマークアップ 言語 (tML)フレームワーク”. www.ttc.or.jp. 一般社団法人情報通信技術委員会 (2006年6月1日). 2024年6月28日閲覧。
  23. ^ “Camelcase” (英語). DevX. 2024年6月27日閲覧。
  24. ^ “Demystifying Camel Case vs. Snake Case – How to Choose the Best Naming Convention for Your Code” (英語). SonderSpot OÜ.. 2024年6月27日閲覧。
  25. ^ “세부(협약)과제 단계보고서 요약문”. ETRI Knowledge Sharing Platform. 2024年6月28日閲覧。
  26. ^ “Learn Python Programming: Easy, Readable Code for Efficiency” (英語). Course Sidekick (2023年6月14日). 2024年6月28日閲覧。
  27. ^ “English Linguistic Imperialism in Programming” (英語). PagerDuty. 2024年6月27日閲覧。
  28. ^ “C | Definition, History, & Facts | Britannica” (英語). www.britannica.com. 2024年6月27日閲覧。
  29. ^ Totaltek: “The Evolution of Computer Programming Languages – Part One” (英語). TotalTek (2022年1月25日). 2024年6月27日閲覧。
  30. ^ Horowitz, Ellis (1983), Horowitz, Ellis, ed. (英語), The Evolution of Programming Languages, Springer, pp. 1–31, doi:10.1007/978-3-642-96729-0_1, ISBN 978-3-642-96729-0, https://doi.org/10.1007/978-3-642-96729-0_1 2024年6月27日閲覧。 
  31. ^ Verzani, John (2014年5月14日). “Using R for Introductory Statistics Second Edition” (英語). students.aiu.edu. 2024年6月28日閲覧。
  32. ^ “Letter Case (Programming Conventions)” (英語). The Basics Guide (2023年10月11日). 2024年6月27日閲覧。
  33. ^ Brauer, Johannes (2015), Brauer, Johannes, ed. (英語), Basics of Object-Oriented Programming Using Smalltalk, Springer Fachmedien, pp. 31–58, doi:10.1007/978-3-658-06823-3_3, ISBN 978-3-658-06823-3, https://doi.org/10.1007/978-3-658-06823-3_3 2024年6月27日閲覧。 
  34. ^ “Camel Case” (英語). SCRIBD (2023年2月6日). 2024年6月28日閲覧。
  35. ^ “Object-Oriented Programming in Smalltalk”. www.cs.tufts.edu. 2024年6月27日閲覧。
  36. ^ Farooq, Muhammad Shoaib; Khan, Sher Afzal; Ahmad, Farooq; Islam, Saeed; Abid, Adnan (2014-02-24). “An Evaluation Framework and Comparative Analysis of the Widely Used First Programming Languages” (英語). PLOS ONE 9 (2): e88941. doi:10.1371/journal.pone.0088941. ISSN 1932-6203. PMC 3933420. PMID 24586449. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0088941. 
  37. ^ Ægidius Mogensen, Torben (2022), Ægidius Mogensen, Torben, ed. (英語), A Brief History of Programming Languages, Springer International Publishing, pp. 1–21, doi:10.1007/978-3-031-11806-7_1, ISBN 978-3-031-11806-7, https://doi.org/10.1007/978-3-031-11806-7_1 2024年6月27日閲覧。 
  38. ^ “Common C# code conventions”. learn.microsoft.com. 2024年6月27日閲覧。
  39. ^ “C# at Google Style Guide” (英語). styleguide. 2024年6月27日閲覧。
  40. ^ “Visual Csharp 2012 How to Program 5Edition”. kshakibaei.ir. 2024年6月28日閲覧。
  41. ^ “A UML Profile and Add-In for UN/CEFACT’s Modeling Methodology” (英語). publik.tuwien.ac.at. Publikationsdatenbank der Technischen Universität Wien. 2024年6月28日閲覧。
  42. ^ Linvelo (2024年1月16日). “Tracing the Evolution of Web Development: Key Changes & Future Projections” (英語). Linvelo. 2024年6月29日閲覧。
  43. ^ “The evolution of modern web applications and their monitoring | The Uptrends Blog” (英語). blog.uptrends.com (2020年7月22日). 2024年6月29日閲覧。
  44. ^ “The Evolution of Web Complexity: How Quality Has Adapted” (英語). www.functionize.com. 2024年6月29日閲覧。
  45. ^ “Google JavaScript Style Guide”. google.github.io. 2024年6月27日閲覧。
  46. ^ “Efficient Management and Compliance Check of HVAC Information in the Building Design Phase Using Semantic Web Technologies” (英語). Semantic Web journal. IOS Press. 2024年6月28日閲覧。
  47. ^ “JavaScript Style Guide” (英語). www.w3schools.com. 2024年6月27日閲覧。
  48. ^ KrzysztofCwalina: “大文字の使用規則 - Framework Design Guidelines”. learn.microsoft.com (2023年10月7日). 2024年6月29日閲覧。
  49. ^ KrzysztofCwalina: “Konventionen für die Groß-/Kleinschreibung - Framework Design Guidelines” (ドイツ語). learn.microsoft.com (2023年10月7日). 2024年6月29日閲覧。
  50. ^ “Principles of Programming & Coding” (英語). pdfcoffee.com. Ronald F. Clayton (2018−5−22). 2024年6月28日閲覧。
  51. ^ “PEP 8 – Style Guide for Python Code | peps.python.org” (英語). Python Enhancement Proposals (PEPs). 2024年6月27日閲覧。
  52. ^ “C#スタイルガイド”. Godot Engine documentation. 2024年6月29日閲覧。
  53. ^ “Java style guide”. www.cs.cornell.edu. 2024年6月29日閲覧。
  54. ^ “JavaScript のサンプルコードの作成ガイドライン - MDN Web Docs プロジェクト | MDN” (英語). developer.mozilla.org (2024年4月4日). 2024年6月29日閲覧。
  55. ^ “Swift Style Guide”. csci.williams.edu. 2024年6月29日閲覧。
  56. ^ “Strategies for Effective Documentation in Programming”. MoldStud.. 2024年6月29日閲覧。
  57. ^ “Learning Natural Coding Conventions”. Microsoft. 2024年6月29日閲覧。
  58. ^ “On the Importance and Shortcomings of Code Readability Metrics: A Case Study on Reactive Programming”. arxiv.org. 2024年6月27日閲覧。
  59. ^ “What is CamelCase? UpperCamelCase vs lowerCamelCase | TL Dev Tech” (英語). TL Dev Tech (2021年5月7日). 2024年6月27日閲覧。
  60. ^ “An Empirical Study on the Usage and Evolution of Identifier Styles in Practice”. IEEE Xplore. 2024年6月27日閲覧。
  61. ^ Salviulo, Felice; Scanniello, Giuseppe (2014-05-13). “Dealing with identifiers and comments in source code comprehension and maintenance: results from an ethnographically-informed study with students and professionals”. Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering (New York, NY, USA: Association for Computing Machinery): 1–10. doi:10.1145/2601248.2601251. ISBN 978-1-4503-2476-2. https://doi.org/10.1145/2601248.2601251. 
  62. ^ “Java Naming Conventions: PascalCase, camelCase, and more - CRS Info Solutions”. www.crsinfosolutions.com. 2024年6月28日閲覧。
  63. ^ “Programming Case Styles : Using The Conventions - ITU Online” (英語). ITU Online (2024年1月24日). 2024年6月28日閲覧。
  64. ^ “Qodana: Static Code Analysis Tool by JetBrains” (英語). JetBrains. 2024年6月27日閲覧。
  65. ^ “Code Quality Tool & Secure Analysis with SonarQube” (英語). www.sonarsource.com. 2024年6月27日閲覧。
  66. ^ “checkstyle – Checkstyle 10.17.0”. checkstyle.sourceforge.io. 2024年6月27日閲覧。
  67. ^ “Find and fix problems in your JavaScript code - ESLint - Pluggable JavaScript Linter” (英語). eslint.org (2024年6月14日). 2024年6月27日閲覧。
  68. ^ “Codacy - Code Quality and Security for Developers” (英語). www.codacy.com. 2024年6月27日閲覧。
  69. ^ “Naming Conventions — Camel Case, Pascal Case, Kebab Case, and More”. medium.com. 2024年6月28日閲覧。
  70. ^ “Most Common Programming Case Types” (英語). www.curiouslychase.com. 2024年6月28日閲覧。
  71. ^ “Snake Case VS Camel Case VS Pascal Case VS Kebab Case – What's the Difference Between Casings?” (英語). freeCodeCamp.org (2022年11月29日). 2024年6月28日閲覧。
  72. ^ DeGregorio, Amy (2020年10月25日). “Quick Guide to Programming Case Types” (英語). Amy's Programming Corner. 2024年6月28日閲覧。
  73. ^ “Naming Conventions”. Scala Documentation. 2024年6月29日閲覧。
  74. ^ “Naming Convention and Code Rules” (英語). docs.eccentex.com. 2024年6月29日閲覧。
  75. ^ a b McConnell, Steve (2004-06-09) (英語). Code Complete. Pearson Education. ISBN 978-0-7356-3697-2. https://www.google.co.jp/books/edition/Code_Complete/LpVCAwAAQBAJ?hl=ja&gbpv=1&dq=Code+Complete+Steve+McConnell&printsec=frontcover 
  76. ^ a b c Martin, Robert C. (2008-08-01) (英語). Clean Code: A Handbook of Agile Software Craftsmanship. Pearson Education. ISBN 978-0-13-608325-2. https://www.google.co.jp/books/edition/Clean_Code/_i6bDeoCQzsC?hl=ja&gbpv=1&dq=Clean+Code+Robert+Martin&printsec=frontcover 
  77. ^ Crockford, Douglas (2008-05-08) (英語). JavaScript: The Good Parts: The Good Parts. "O'Reilly Media, Inc.". ISBN 978-0-596-55487-3. https://www.google.co.jp/books/edition/JavaScript_The_Good_Parts/PXa2bby0oQ0C?hl=ja&gbpv=1&printsec=frontcover 
  78. ^ Herman, David (2016-03-08) (英語). Effective JavaScript: 68 Specific Ways to Harness the Power of JavaScript (Effective Software Development Series). CreateSpace Independent Publishing Platform. ISBN 978-1-5304-2722-2. https://www.google.co.jp/books/edition/Effective_JavaScript_68_Specific_Ways_to/wVDCjwEACAAJ?hl=ja 
  79. ^ Thomas, David; Hunt, Andrew (2019-07-30) (英語). The Pragmatic Programmer: Your journey to mastery, 20th Anniversary Edition. Addison-Wesley Professional. ISBN 978-0-13-595691-5. https://www.google.co.jp/books/edition/The_Pragmatic_Programmer/LhOlDwAAQBAJ?hl=ja&gbpv=1&dq=The+Pragmatic+Programmer:+Your+Journey+to+Mastery&printsec=frontcover 
  80. ^ “PlayStation 公式サイト | 本体・ゲームタイトル・周辺機器”. www.playstation.com. 2024年6月29日閲覧。
  81. ^ “マクドナルド公式サイト | マクドナルド公式”. www.mcdonalds.co.jp. 2024年6月29日閲覧。
  82. ^ “キャメルケースとは 意味/解説 - シマウマ用語集”. makitani.net (2022年3月4日). 2024年6月29日閲覧。
  83. ^ “キャメルケースとは? 意味や使い方”. コトバンク. 2024年6月29日閲覧。
  84. ^ a b “スネークケースとは - IT用語辞典”. IT用語辞典 e-Words. 2024年7月7日閲覧。

関連項目

印刷
組版
ページ
文字
書式
欧文書体
漢字仮名書体
五体
印刷
その他
フォント
約物
単位
DTP
カテゴリ カテゴリ