命名規則 (程式設計)

程式設計的中命名規則而規定的一系列規則。通常是為了提高原始碼的易讀性、易認性、程式效率以及可維護性。命名規則根據各個程式語言的規格、記憶體大小等硬體制約、編輯器以及整合開發環境的功能等等會有各種制約。挑戰.命名規則的選擇通常是一個有爭議的問題，不同派系的人會覺得自己的觀點最好而其他人則是次等的。 而且，即使採用了已知且定義明確的命名規則，某些組織也可能無法始終如一地遵守這些規則，從而導致不一致和混亂。 如果命名規則在內部不一致、任意、難記，或者以其他方式顯得負擔大於好處，則命名規則會遇到更多的挑戰。易讀性.精細挑選的識別符號可以讓開發者和分析器更容易理解系統在做什麼，或者如何修改或將原始碼擴充套件運用到新需求上。 比如這句宣告a = b * c;在語義上是正確的，但是其目的卻不明顯。而相比較之下，寫成weekly_pay = hours_worked * hourly_pay_rate;則提示了原始碼的意圖和含義，至少對了解上下文的人來說更清晰。典型要素.識別符號長度.最基本的規則中包括對識別碼長度的規定。在某些情況下，上限是透過提供數值來設定的，而另一些情況下則使用了啟發式的方法或準則。識別碼長度的規則是有爭議的，適當的長度應視具體情況而定。要考慮的要點包括：一些早期的連結器將變數名限制為6個字元或更少，以減少記憶體使用，這也是早期的程式會限制識別碼長度的原因之一。大小寫和數字.一些命名規則對大小寫和數字的使用加以限制，比如只能用小寫字母，或者只能用大寫字母。有些場合雖然可以保留大小寫，但功能上並不賦予區別。多個單片語成的識別符號.通常推薦使用「有實際含義的識別符號」。如果單個單詞無法表述清晰則可以使用多個單詞，因此命名規則需要規定多個單詞如何連線。這樣還可以避免與各個程式語言使用的保留字衝突的問題。大多數語言的識別符號不允許空格，而不加空格又會導致難以閱讀，因此需要制定空格的替代方式。用符號區分.在字母數字的單詞裡使用制定的區分字元進行連線，常用有 連字元 ("-") 、下劃線 ("_")，比如兩個單詞的 "codice_1" 可寫成 "codice_2" 或者 "codice_3"。連字元非常常用，包括 COBOL (1959), Forth (1970)以及 Lisp (1958)，而在 Unix 命令和包裡也很常見。在 CSS 中也是如此。 這種做法沒有一個通稱，有人叫 "lisp-case" 或者 "COBOL-CASE" ，或者叫 "kebab-case"、"brochette-case"等等。 但至少是從 2012 年之後,  "kebab-case" 這個叫法越來越流行。與此相比，在 FORTRAN/ALGOL 語言的傳統中，特別是 C語言 和 Pascal語言 家族，曾使用連線號用於 中綴表示法 的減法運算子，而且也不希望前後加空格, 因此就無法用此方法來命名識別符號。而用下劃線連線小寫字母的方法則在 C 家族裡都很常見，比如 "The C Programming Language" (1978) 即可見到，通稱為 snake case. 而像 UPPER_CASE 這樣用下劃線連線大寫字母的做法則常見於 C預處理器 裡的宏，所以被稱為 MACRO_CASE；以及 Unix 中的 環境變數，比如 bash 裡的BASH_VERSION。有時會被幽默地稱作 SCREAMING_SNAKE_CASE。用大小寫區分.另一種做法就是在單詞組合成一個字串的中間使用大寫字母，被稱作駝峰式大小寫"。元資料與混合命名規則.有一些命名規則不僅是特定程式、某個特定專案和問題的規則和需求，還透過軟體架構稱為對其下層的程式語言和跨專案的一個方法論框架。匈牙利命名法.最著名的命名規則包括匈牙利命名法，具體包括“系統匈牙利命名法”和“匈牙利應用命名法”。比如變數 szName 中的字首 "sz" 代表其是一個零結束字串。各種語言的命名規則.C 和 C++.原則上使用小寫字母。在C標準庫裡，最常用的做法是使用縮寫名稱，如用於測試是字元是否為字母數字的函式寫成 codice_10 ，而C++的標準庫了則常用下劃線作為單詞分隔符。C#.C# 命名規則基本上遵循微軟的 .NET 語言的規範。 。一個不適用 PascalCase 的特例，是識別符號開頭的雙字母首字母縮寫詞，這時兩個字母都要大寫，如 codice_19，但這不適用於更長的首字母縮寫詞裡，如 codice_20。該規範還推薦 codice_21 的名字要用 codice_17 並在開頭加一個大寫字母 codice_23，如 codice_24。微軟規範對 filed 命名僅限於 codice_25, codice_26 和 codice_27，並明確指出如果非靜態、或者有其他可接入層級，這些例外使用 camelCase 並新增一個下劃線，如 codice_33。識別符號可以新增 @ 符號卻不改變含義。也就是說  codice_34 和 codice_35 均指同一個物件。在規則上，這一字首僅用於當該識別符號是預留關鍵詞。Java.Java的命名規則是由多個社群制定的，包括昇陽電腦、網景、AmbySoft 等等。下述採用昇陽電腦制定規則的例子，比如 "CamelCase"，不用空格直接連起來，每個單詞首字母大寫，比如 "CamelCase".縮寫詞長達三個字母及其以上時用 CamelCase 而不是全大寫，這個規則可以適用至兩個字母詞 (如 codice_44).JavaScript.JavaScript 的內建庫採用與 Java 同樣的命名規則。資料型別和建造函式使用 upper camel case (RegExp, TypeError, XMLHttpRequest, DOMObject) 而方法使用 lower camel case (getElementById, getElementsByTagNameNS, createCDATASection)。為了保持統一，大部分 JavaScript 開發者都遵循此命名規則。.NET.微軟公司 Microsoft .NET 推薦大部分識別符號都用 codice_45字首提示， 而是推薦在後面加上基礎類名，如寫成 codice_46 而不是 codice_47。Objective-C.Objective-C 使用源於 Smalltalk 的程式碼方式。通用的變數、函式的頂層條目，包括類、協議都用 UpperCamelCase 並用一個短的全大寫字首標示名稱空間，比如 codice_48, codice_49, codice_50 以及 codice_51。常量可以有小寫字母k打頭的字首如 codice_52。即時物件的變數使用帶下劃線的 lowerCamelCase，如 codice_53 and codice_54。Method 名使用多個 lowerCamelCase 並用冒號區分如 codice_55, codice_56 and codice_57.Perl.Perl 繼承了C中的一些規則。本地範圍內的變數和子程式名用小寫字母加下劃線。包變數採用 title case，宣告的常量全大寫。包的名字採用 camel case 但 pragmata 例外，比如 codice_58 和 codice_59用小寫。PHP.PHP 推薦方式寫在 PSR-1 (PHP Standard Recommendation 1) 和 PSR-12 中。 根據 PSR-1，類的名字要用 PascalCase, 類的常數要用 MACRO_CASE，而 method 名要用 camelCase。Python and Ruby.Python和Ruby都推薦類名使用 codice_45，常數名使用 codice_61，其他名字用 codice_62。Swift.Swift語言的命名規則根據不同釋出有所變化。但是隨著 Swift 3.0 的重大更新後，其命名規則規範更為清晰，希望能對所有第三方的 API 命名和宣告規則進行標準化。變數、函式宣告的命名規則還是以 codice_63 為基礎。常數通常使用 enum 型別定義。類和其他型別的宣告採用 codice_45。