Java究竟怎么玩？

       看到有網友留言，指出了我的命名規范錯誤，甚感欣慰。確實有部分代碼沒有按照統一的命名規范書寫，實在有礙觀瞻，一定注意改正。但是就[一看到上面的代碼，第一想法就是c++]這點，因為我似乎也當歸結為“嚴于律人，疏于律己”那類型人，還是要強辯幾句（高爾基他們家木匠說過：讓板磚來得更猛烈些吧）……

       首先，就現實情況來講，在通常狀況下命名規范其實應歸屬于[規范性建議]那類范疇，而非屬于強制范疇。只要不是你所在公司或組織的命名規范，那么命名規范便只是推薦你怎么做，而沒有要求要你必須怎么做。

       再者，即使是公司的編碼規范，也不盡相同，即有那種無所謂隨意一頁薄紙便打發的、也有那類從互聯網上檢索來隨便什么，而后稍加潤色的、也不乏自己洋洋灑灑數萬字編碼規范的公司存在。誰能強制IBM、微軟、SUN都使用一種命名規范呢？

       而且，就本質來說，命名規范的產生無外是歸結于令別人以約定俗成的方式閱讀和修改你開發的程序. 也就是說，是別人期望你如此來寫，而非你意愿中的寫法。如果別人的意愿發生了轉變，那么你的寫法也必然會隨之發生變化。

       進一步講，命名規范這種事，就從來不是一成不變的，輕易便會被人有意無意間創造出來。


 比如還在完善中的C#，它的命名方法，便是一種典型：

C#基本命名方法：

一。常量
      帶有訪問修飾符的常量以駱駝命名法[1]
      帶有公有訪問修飾符，受保護修飾符的常量以帕斯命名法[2]

二。數組
      以駱駝命名法[1]。

三。結構
      以帕斯卡命名法[2]，用名詞或短語作為名稱。

四。枚舉
      以帕斯卡命名法[2]，枚舉中的選項也一樣。

五，類
      以帕斯卡命名方法[2]，確保類的名稱是一個名詞。

六。成員變量命名。
      給公有成員變量，受保護的成員變量或內部成員變量命名應以帕斯卡命名方法，給私有成員變量應使用駱駝命名法[1]并以下劃線開頭。

七。變量
      內聯變量（在方法內聲明）應以駱駝命名法命名[1]。避免使用單個字符作為變量名稱，但循環除外。


常用命名方法：
1，駱駝命名法（camelCasing），第一個字母小寫，隨后的每個單詞的第一個字母大寫。混合使用大小寫字母來構成變量和函數的名字。
2，帕斯卡命名法（pascalCasing），與駱駝命名法類似。只不過駱駝命名法是首字母小寫，而帕斯卡命名法是首字母大寫。如：StudentName

下劃線命名法，顧名思義就是在命名中加入了下劃線的命名規則，用于標示類的私有成員。比如在Java編碼中，能有效避免如：
class User
{
String name;
public setName(String name) //沖突
{
this.name = name;
}
}

匈牙利命名法（Charles Simonyi提出，因其出生地得名），變量名＝屬性＋類型＋對象描述

這么看的話，本身C#的命名規范，就是一個雜燴。

但我們卻也都知道，早期的M$君（^^），事實上是力挺匈牙利命名法的。但是后期，由于匈牙利表示法的復雜性及IDE的廣泛使用影響下，除了在控件命名上尚有優勢外，就很少再被使用。微軟轉而以駱駝命名法和帕斯卡命名法外代下劃線命名法為主體。

可見，命名規范的最主要意義，還是在于——如何能為最大多數人接受，而不是其他什么。

又比如，雖然同屬Java體系，Eclipse的SWT包中同樣存在著“反Java規范”的地方。

如在org.eclipse.swt.awt包下，SWT_AWT類就是全文大寫，而且還用了下劃線，這在以前其他的開源包中是不多見的。但是，卻清晰體現了類的作用，應該說，是一種很好的寫法，目前正開始流行中……

個人認為，既然命名規范是會不斷改變的，那么也就是說，但凡不是為公司寫程序或團隊開發，完全可以按照自己的方式實現命名規范。（實際上，如果這一過程中你是主導者的話，也可以定義自己的命名規范。）這于人于己都沒有太大壞處（注意，是沒有“太大”，不是沒有。我曾遇到某高人，就因他不希望改變自己加下劃線的命名習慣而辭職不干的……結果受他影響，我自己也開始愛加下劃線……），說不定，你一不小心創造出一種公認的命名表示法，反而成為X氏命名規范創始人也未可知呢。