在開發過程中，我們不僅要去看別人的代碼，也要讓別人看我們的代碼。那么，有一個良好的編碼習慣將會非常重要。下面將會羅列使用-C來開發iOS的編碼建議。
【1】任意函數長度不得超過50行。（其實很容易就超過50行，這就要考慮代碼抽取了。）
【2】任意行代碼不能超過80字符。（其實也很容易超過80字符，可以考慮多行顯示，比如有多個參數時，可以每個參數放一行。）可以在Xcode中設置超過80個字符的提醒，選中“Page guide at ”.設置完之后就會在代碼80個字符處有一條豎線。
【3】在每個方法的定義前留白一行，也就是在方法和方法之間留空一行。
【4】功能相近的方法要放在一起，并推薦使用# mark - ***來導航代碼，切分代碼塊。這樣可以方便函數的查找。并且可以使用快捷鍵+6 來快速查找方法的位置。
【5】二元運算符和參數之間要有一個空格，如賦值號=左右各留一個空格。
self.=@"";
【6】一元運算符和參數之間不放置空格，比如！非運算符，&按位與，|按位或。
=true;
=!;
【7】強制類型轉換和參數之間不放置空格。
*str3=(*)self.;
【8】長的變量值應該拆分為多行。尤其體現在使用數組或者字典。以下也分別是快速聲明數組@[]和字典@{}的方法。
*array=@[@"111",
@"",
@"",
@""
];
@"age":@"20",
@"":@"",
@"":@"false"
};
【9】盡量使用有意義的名字命名ios 判斷字符串是否為空，拒絕使用i,j等無意義字符命名。類的命名首字母大寫，其他變量的命名首字符小寫，并使用駝峰式分割單詞。
【10】盡量減少在代碼中直接使用數字常量，而使用宏定義等方式。如：替代8等等。這樣我們搜索也比較方便。
【11】盡量減少代碼中的重復計算，比如代碼中多處要使用屏幕寬度ios 判斷字符串是否為空，然后計算：[[] ].size.width ,很多次，閑得很繁瑣，代碼也冗長。不如直接宏定義：
#([[]].size.width)
【12】合理使用約定俗成的縮略詞：
【13】宏定義全部字母大寫。
【14】函數長度不要超過50行，小函數比大函數可讀性更強。函數的參數不宜過多，零元函數最好，一元函數也不錯，高于三元的函數虛重構。
【15】合理范圍內使用鏈式編程:
*=[[]init];
但是嵌套不宜超過3層，超過3層需進行重構。
【16】函數調用時所有參數在同一行。如果參數過多，則可以每行一個參數，每個參數以冒號對齊。
【17】對傳入參數的保護或者說是否為空的判斷，盡量不要使用if(!obj),而使用斷言來處理。是系統定義的宏。
(!=nil,@"參數為空");
【18】方法參數名前一般使用"an","the","new"來進行修飾。如：
-(void):(*):(*):(*)
【19】if-else超過四層的時候，就要考慮重構，多層的if-else結構很難維護。
【20】當需要一定條件才執行某項操作時，最左邊的應該是最重要的代碼，不要將最重要的代碼內嵌到if中。如良好的風格是：
-(void){
if(![]){
;
}
//最重要的代碼寫在這里；
}
反面教材:
-(void){
if([]){
//重要代碼；
}
}
【21】所有的邏輯塊都使用{}花括號包圍，就算只是一行代碼。
【22】明確指定構造函數，并有適當的注釋。
【23】不要在init方法中把變量或者說屬性初始化為0或者nil，因為沒有必要。
【24】的子類初始化的時候，不要進行任何的布局操作。布局操作應該在里面做；需要重新布局的時候調用，而不要直接調用。
【25】保持公共API簡單，也就是保持.h文件簡單。放在.h中聲明的函數都是會被公開的，如果根本就沒必要對其他類公開，再不要在.h中聲明。OC中的方法都是公有方法，沒有私有方法一說。
【26】一個文件只實現一個類。同一個文件中不要有多個類。
【27】單獨用一個文件來創建，盡量不要與相關類混在一個文件中。
【28】在類定義中使用到自己定義類的時候，盡量不要在頭文件中引入自己定義類的頭文件，使用@class替代。而在實現文件中引入頭文件。
【29】布局時盡量使用相對布局，比如使用子View在父View中的相對位置。
【30】代碼折疊，這個可能是關于開發效率的，我也寫在編碼規范中，因為這個很有用。默認沒有開啟代碼折疊，如果你的方法體行數很長，看起來會很不方便，此時你就可以把方法“收起來”，一個類中的結構就會很清晰。開啟方法如下：Xcode菜單-->-->Text -->勾選Code .如圖：
【31】推薦方法的第一個花括號直接跟在方法體后，而不是另起一行，這樣可以減少代碼行。
【32】推薦方法體中的第一行留空，最后一行不留空，這樣一個方法就會比較清晰。如圖：
但是如果該花括號里面又是一個if，for之類的帶花括號的語句塊，那么上述的第一行可以不留空。
同樣，如果花括號內第一行是注釋的話，第一行也可以不留空。注釋也起到了分隔代碼的作用，看起來比較清晰。
再者，如果花括號內只有一行代碼，第一行可以不留空。
【33】block中第一行也要留空，同方法體中的第一行留空，使代碼清晰。
【34】代表類方法和實例方法的"+"加號,"-"減號后需要一個空格。這是一個非常小的細節，系統默認的方法都是這樣的，我們自己聲明或者實現一個方法的時候也需要這樣：
【35】這一條有點像編程經驗了，就是為解決某個問題估算時間。比如要開發某個功能、調試某個bug、給自己一個時間限制，如果在這期間不能解決問題，那么就去尋求幫助。這既是給自己一個壓力，也為了不浪費時間。雖然，這一條其實很難做到，我往往由于不甘心而無限拖延時間去解決問題。
【36】由于提到編程經驗，就不得不提到版本控制。務必去學會SVN或者Git，就算你是獨立開發，也要學會控制自己的代碼，當然，你要經常備份你的代碼。
上面都是我的一家之言，如果大家的開發團隊或者公司有自己的編碼規范，當然按照團隊的來。