標籤:style blog http color 使用 os 資料 io
最近在為公司編寫c#編碼規範,以前對這方面研究不多,只是覺得代碼能夠出自己的意思就可以了。
我參考了以下資料
- C# Coding Conventions
- NET設計規範約定慣用法與模式(第2版)
- 編寫可讀性代碼的藝術
- 重構—改善既有代碼的設計
- 高效程式員的45個習慣
- 代碼整潔之道
發現其實真要寫好一個代碼規範是一件非常難的事情,這取決於規範制定者的經驗,團隊成員的水平,業務的具體需求,項目的複雜度,項目的進度,企業的文化氛圍等等。
而且每次提筆要寫的時候,總是有很多很多的想法想寫進去,可是作為一個規範又不可能太長,要精簡。
所以自己寫了兩天目前唯寫出來了命名規範這一部分,先和大家分享一下,裡面對於為什麼要選擇這個約定也有一定的解釋,希望大家可以一起探討下我選的這些規範是否合理,如果不合理的地方很高興能和大家一起修改。
後續幾天我會陸續的把
二、命名的選擇
三、注釋的編寫
寫好,同時也希望大家幫我想想編碼規範還有哪些方面需要覆蓋。
命名規範
我們在命名標識符時(包括參數,常量,變數),應使用單詞的首字母大小寫來區分一個標識符中的多個單詞,如UserName.
PascalCasing包含一到多個單詞,每一個單詞第一個字母大寫,其餘字母均小寫。例如:HelloWorld、SetName等。
除了參數、變數、常量外,所有命名空間名稱、類、函數、介面、屬性、事件、枚舉等名稱的命名,使用 Pascal 風格。
camelCasing包含一到多個單詞,第一個單詞首字母小寫,其餘單字首大寫。例如:name、productId等。
參數與變數的命名使用camelCasing.
SCREAMING_CAPS包含一到多個單詞,每個單詞的所有字母都大寫,單詞與單詞之間用"_"串連,該風格目前在c#中只用於const常量。
如:public const string DEFAULT_PAGE = "default.aspx";
Private 的私人變數使用底線"_"+camelCasing的大小寫規則,以便快速確認該變數的範圍。
如: private int _userId;
首字母縮寫詞是由一個短語的首字母組成的,如Xml(ExtensibleMarkuLaguage),IO(Input and Output)。它和單詞縮寫是有區別的,單詞縮寫僅僅是把一個單詞的長度變短。
- 把兩個字母的首字母縮寫詞全部大寫,除非它是camelCasing的第一個單詞。
using System.IO;
public void StartIO(Stream ioStream)
- 由三個或以上的字母組成的首字母縮寫詞,只有第一個字母大寫,如Xml,Html.除非首字母是camelCasing標識符的第一個單詞。
using System.Xml;
public void ProcessXmlNode(XmlNode xmlNode)
不要把複合詞中的首字母大寫。複合詞要當成一個單詞來處理。
如endpoint, callback,metadata,namespace等都是正確的寫法
- 在帶單位的值的變數後加上"_camelCasing單位"
將單位加入標識符命名中,可以使使用者快速準確的知道傳人資料的單位,減少錯誤的發生。
如public void CreateCache(int cacheSize)
傳入的資料是bytes, KB, MB 還是GB?
改成public void CreateCache(int cacheSize_mb)
一目瞭然,並且會減少調用者傳入錯誤資料的可能。
其他一些沒有單位的函數參數以及帶單位的版本。
匈牙利命名法是指用小寫形式的資料類型縮寫來作為變數名的首碼。如:strName,intCount。
這種命名法在C和C++時代很流行,可以協助程式員記住自己的類型。
但在C#中需要禁用,除非你有足夠的理由,因為:
- C#都是強型別的,現在的IDE(如Visual Studio)可以自動的檢測出當前變數的類型以及類型錯誤
- 開發初期經常需要修改變數的類型,使用匈牙利命名法維護很困難。
人在閱讀代碼時,能更快的理解符合其閱讀習慣的命名。
如VerticalAlignment比AlignmentVertical能讓人更快的知道該變數的含意。