我是如何收拾代碼的
注釋
雖說好的代碼不用注釋,但是那得是好的代碼..好記性不如爛筆頭，好好寫注釋可以給自己和自己的小伙伴省下很多時間.
注釋都是// 或是/* 注釋 */ ，這樣的通用注釋不做多說明，這里介紹一些稍帶技巧的注釋：
參數的注釋
UIButton *btnSend;/**< 發送按鈕 */
在調用時可以得到提示，在內容比較多時比較好用，我有時候腦子短路要想好一會才能記得當初定義的變量是做什么用的。
方法的注釋
如果你的方法是沒有參數的，只需要寫一句注釋，那只需要在方法前加注釋就行了
type 1
/** table 相關設置 */
-(void)configTable{} type 2（插件：VVDocument）使用此插件可以很便捷的為自己的代碼添加注釋
/*!
* @author joanfen, 15-05-14 12:05:22
*
* @brief 相關設置
*/
-(void)configTable{} 這樣的注釋 在你調用時會顯示你所添加注釋，如圖
有參數的注釋
/*! * @Author joanfen, 15-05-13 14:01:51 * @method POST * @see XRClass * @brief 鏈接解析 * * @param linkAddressStr 鏈接地址 */
大家使用VVDocument 的插件來寫注釋就對了。這樣的注釋自己寫起來太費事，沒有插件我真不愿意寫。
方法分區
#pragma mark - <注釋，也可不寫，沒有注釋時就只顯示一條分割線> #pragma mark 注釋
區別：帶 - 的會顯示一條分割線
便于簡單快速的查找方法
添加提示信息
#error <提示信息>
如果加上這樣的錯誤提示，在 Build 時 XCode 會提示編譯錯誤：
在某部分代碼沒有完成，而且如果提交會導致問題時可以加上這樣的提示信息來提醒自己。
如果你覺得只是想提醒自己來完成，并不需要加上紅色的 error 信息，你可以嘗試使用
#warning <提示信息>
這樣的話在編譯時提示信息是這樣的
使用場景
在替換某個類時，需要刪除原有的代碼，再進行替換，每次刪除一個我就加一行同樣的 warning，最后新的寫好之后，搜索這行 waring，將調用方法填充，大大提高效率；
UI 寫好了，數據部分還沒有好，將邏輯梳理好，方法寫好，加上 warning ，包含 deadline，需要完成的工作，在后臺數據可測時，再來完成，不寫的話有時候真的腦子短路，有時候半天都不記得當時是準備怎么弄的，尤其在開發量大的時候，原諒我是一個容易腦子短路的人，-_-。
使用常量
常見使用宏，const 常量，枚舉等來定義常量，避免將一個數字或者是字符串重復寫多次，而是定義成常量，便于統一管理，也減少出錯的幾率
推薦兩篇關于常量的博客： 宏定義的黑魔法， 如何正確定義常量
宏
#define
宏大家應該都不陌生，這里不展開贅述，請看上面的博文，我在去年看了宏定義的黑魔法這篇博文之后，曾經一度超級喜歡用宏，不管是字符串，方法，還是高度，動畫時長這一類常量，我都喜歡用宏來定義，直到我看見了后面的如何正確定義常量這篇博客，我才清醒一點。
const 常量
現在使用的多得是 const 常量
在方法體內使用
static const CGFloat KCellHight = 126.f;
在類文件中使用, 在.m 文件中
const CGFloat KXRBtnSendHeight = 44;
如果需要提供給外部使用，使用 extern 修飾：
只需要在.h 中使用 extern 外部聲明即可
extern const CGFloat KXRBtnSendHeight;/**< send按鈕高度 */
枚舉
在判斷 table 的 section，row，控件的 tag，或是點擊的 index，或是自己定義的 type 時，不要直接使用數字判斷，如果類型多，使用枚舉，少，可以使用上文中的宏或是const 常量
typedef enum : NSUInteger {
XRTypeRegular = 10,
XRTypeSimple = 20,
} XRType; 在判斷 type 時，使用這樣的語法，這是最基本的，看到直接 == 10這樣的代碼，沒有辦法忍
if(type == XRTypeRegular)
使用 Category 或是基類
這個部分不是很好給出代碼實例，要實例的話想想當初做各級員工結算工資的課程設計吧，只作簡要說明。
在邏輯比較繁雜，某個類代碼量非常龐大時，可以考慮使用基類，將公有的屬性和方法在基類中實現，自己在使用時只需要關注一些單獨的邏輯即可，可以大大提高代碼效率。
使用 category 是對某個類進行一些簡單的擴展，在 category 中定義的方法等同于類的方法，是一樣的，為了讓功能劃分更純粹一些，一言以蔽之，強迫癥。。
給出一個小場景：比如我定義了一個 UITableViewCell 的類，在 A，B，C 的視圖控制器中樣式都是一樣的，但是在D 的視圖控制器中需要對它進行一些改造，這樣的話就可以在 D 的類中加上一個 Category來進行操作，在 D 中直接調用這個方法即可
// DViewController.h
@interface DViewController{
}
@interface ModuleCell(diff)
-(void)diffTheCellByParam:(id)param;// DViewController.m
@implementation DViewController
@end
#pragma mark -
@implementation ModuleCell(diff)
-(void)diffTheCellByParam:(id)param{
// Do something
} 使用 MVC
MVC 模式是最常見的模式，而且在學習的第一時間就有接觸，可能有些人看到這兒覺得，你這不是廢話？這誰不知道。
但是我發現在 Objective-C 這個大家庭中，這個模式是遵守的最差的，相信你們一定見過在 ViewController 中寫完所有的數據處理，UI 渲染，視圖跳轉各類動畫的經典案例，因為我們就是這類型創造者，新手應該都是這樣過來的（只是說明是一個大概率事件，很多資深其他平臺開發者轉過來時這方面是做的非常好的）。
-
把數據的處理（獲取，篩選，排序等）工作放在 Modal 中，所謂 Modal，新建一個繼承自 NSObject（一般是 NSObject） 的類，用來處理數據，直接調用即可；
-
把視圖的渲染放在 View 中（簡單的視圖加載可直接在 Controller 中完成），在遇到比較繁雜，需要幾百行代碼來完成時，如果你是用 xib或是 storyboard 配合代碼，這部分無需這么嚴格，公用的視圖必然是放在 View 中了；
-
視圖控制器 Controller 中只用來調用數據，顯示數據，視圖的加載，跳轉等工作。
視圖內容在繁雜時可以考慮使用多個視圖控制器聯合控制一個頁面，如 Apple 的 TabBarController 的工作機理。
將視圖以 AddChildViewController 的方式添加到當前視圖。
在 A 控制器中添加 B 控制器的視圖，這樣 A 同時包含了 A 和 B 的視圖，B 視圖中得 UI 邏輯依然在 B 中進行處理
BViewController *secondVC = VCFromSB(storyboardPatient, @"XRPatientAllVC"); [self.view addSubview:secondVC.view]; [self addChildViewController:secondVC]; [secondVC didMoveToParentViewController:self];// 將B 視圖的 UI 響應事件移到 A 中，如果不這樣操作，只要點擊B 視圖中得按鈕或是滾動 table 就會崩潰
案例不是太好寫，要寫得好長一篇文章了，我還得想一項目，可以參考這部分文章：更輕量的 ViewControllers
代碼規范
代碼規范這事兒 各人有各人的習慣，不多說，但是你得有個規范，別想咋就咋，到時候害的是自己Over
噢，還有件事兒，OC 的代碼跟寫文章一樣這事兒我們都知道，每次都被后端工程師過來吐槽也是醉了，在寫參數超過2個的方法時，大家按照冒號對個齊，會好看很多，我也不是逼你這樣做，你就隨意感受下吧
最后，多復用，多重構，多寫注釋，祝大家都有一份整潔有條理的代碼。
來自：http://my.oschina.net/joanfen/blog/415058