寫代碼也寫了快兩年了，總結下代碼編寫規範；
Ios項目代碼編寫規範
一個好的項目的代碼編寫主要依據四個原則：
1）、代碼的可讀性；保持代碼的簡單化是軟件工程化的基本要求。不過分追求技巧，否則會降低程序的可讀性。儘量多增加代碼的註釋；
2）、代碼的可維護性、可移植性；編程首先要考慮是否滿足正確性、可維護性、可移植性，然後纔可以考慮代碼的執行效率和資源佔用率；
3）、代碼的可測試性；不能測試的代碼是無法保證質量的，在編寫代碼實現設計功能的同時，要提供測試和驗證的方法；
4）、代碼的執行效率；項目中同樣的代碼不要出現多次，內存空間的分配和釋放，遵從在哪分配就在哪釋放；
具體的項目代碼編寫規範：
1） 項目整體佈局；程序佈局的目的是顯示出程序良好的邏輯結構，提高程序的準確性、連續性、可讀性、可維護性。更重要的是，統一的程序佈局和編程風 格，有助於提高整個項目的開發質量，提高開發效率，降低開發成本；同時也會增加項目代碼整體美感；對引用頭文件、宏定義文件、全局變量文件、各種資源 文件、類模塊文件等分別進行獨立封裝，以文件夾的形式集中管理；
2） 代碼的對齊和斷行；
1）、可使用Tab鍵或空格鍵對代碼行進行縮進，縮進爲四個空格；
2）、程序的分界符‘{’和‘}’應獨佔一行並且位於同一列，同時與引用它們的語句左對齊。{ }之內的代碼塊使用縮進規則對齊。
3）、結構型的數組、多維的數組如果在定義時初始化，按照數組的矩陣結構分行書寫。
4）、相關的賦值語句等號對齊。
5）、在switch語句中，每一個case分支和default要用{ }括起來，{ }中的內容需要縮進。
6）、函數(方法)塊之間使用兩個空行分隔。
7）、一元操作符如“!”、“~”、“++”、“--”、“*”、“&”（地址運算符）等前後不加空格。“［］”、“.”、“->”這類操作符前後不加空格。
8）、多元運算符和它們的操作數之間至少需要一個空格。
9）、關鍵字之後要留空格，函數名之後不要留空格。
10）、方法名與形參不能留空格，返回類型與方法標識符有一個空格。
11）、註釋符與註釋內容之間要用一個空格進行分隔。
12）、長表達式（超過80列）要在低優先級操作符處拆分成新行，操作符放在新行之首（以便突出操作符）。拆分出的新行要進行適當的縮進，使排版整齊。
3） 項目中類變量、資源文件的命名規則；
1）、標識符要採用英文單詞或其組合，便於記憶和閱讀，切忌使用漢語拼音來命名。
2）、嚴格禁止使用連續的下劃線，下劃線也不能出現在標識符頭或結尾（預編譯開關除外）。
3）、程序中不要出現僅靠大小寫區分的相似的標識符。
4）、宏、常量名都要使用大寫字母, 用下劃線 ‘_’ 分割單詞。預編譯開關的定義使用下劃線‘_’ 開始。
5）、程序中局部變量不要與全局變量重名。
6）、使用一致的前綴來區分變量的作用域。
7）、類中的屬性以小寫字母帶下劃線開頭。（如：m_username）
8）、資源類文件可以以大寫字母帶下劃線開頭。（如圖片：IDB_SOURCEIMG）
4） 方法、接口及表達式語句書寫規則；
1）、一條語句只完成一個功能。
2）、在表達式中使用括號，使表達式的運算順序更清晰。
3）、不可將布爾變量和邏輯表達式直接與YES、NO或者1、0進行比較。
4）、在條件判斷語句中，當整型變量與0 比較時，不可模仿布爾變量的風格，應當將整型變量用“==”或“!=”直接與0比較。
5）、不可將浮點變量用“==”或“!=”與任何數字比較。
6）、應當將指針變量用“==”或“!=”與nil比較。
7）、在switch語句中，每一個case分支必須使用break結尾，最後一個分支必須是default分支。
8）、不可在for 循環體內修改循環變量，防止for循環失去控制。
9）、避免函數有太多的參數，參數個數儘量控制在5個以內。
10）、對於有返回值的函數(方法)，每一個分支都必須有返回值。
11）、對輸入參數的正確性和有效性進行檢查。
12）、在組件接口中應該儘量少使用外部定義的類型（重用，減少耦合）。
13）、函數(方法)體的規模不能太大，儘量控制在200行代碼。（建議）
5） 頭文件的引用問題；
1）、如果不是確實需要，應該儘量避免頭文件包含其它的頭文件。一次頭文件包含就相當於一次代碼拷貝。
2）、申明成員類，應該引用該類申明，而不是包含該類的頭文件。
6） 內存引用與管理；
1）、防止內存操作越界。內存操作主要是指對數組、指針、內存地址等的操作，內存操作越界是主要錯誤之一。
2）、必須對動態申請的內存做有效性檢查，並進行初始化；動態內存的釋放必須和分配成對以防止內存泄漏，釋放後內存指針置爲nil。
3）、變量在使用前應初始化，防止未經初始化的變量被引用。
4）、減少指針和數據類型的強制類型轉化。
5）、非初始化方法中的alloc操作之前必須要nil判斷。
6）、全局指針釋放後置爲nil值。
7）、內存的申請和分配遵從在哪申請分配就在哪釋放。
7） 註釋及斷言錯誤的使用和管理；
1）、多行註釋採用“/* …*/”，單行註釋採用“// …”。
2）、註釋使用中文，一般情況下，源程序有效註釋量必須在30%以上。
3）、文件頭部必須進行註釋，包括：.h文件、.c文件、.m文件、.inc文件、.def文件、編譯說明文件.cfg等。
4）、方法頭部應進行註釋，列出：函數的目的/功能、輸入參數、輸出參數、返回值、訪問和修改的表、修改信息等，除了函數(方法)名稱和功能描述必須描述 外，其它部分建議寫描述。
5）、註釋應與其描述的代碼相近，對代碼的註釋應放在其上方或右方（對單條語句的註釋）相鄰位置，不可放在下面，如放於上方則需與其上面的代碼用空行 隔開。
6）、全局變量要有詳細的註釋，包括對其功能、取值範圍、訪問信息及訪問時注意事項等的說明。
7）、註釋與所描述內容進行同樣的縮排。
8）、使用斷言檢查函數輸入參數的有效性、合法性。（Assert(exp)）
9）、正式軟件產品中應把斷言及其它調測代碼去掉（即把有關的調測開關關掉）。
8） 其他注意事項或建議；
1）、建議枚舉第一個成員要賦初始值。
2）、addObject之前要非空判斷。
3）、release版本代碼去掉NSLog打印，除了保留異常分支的NSLog。