命名
- 在定義各種
view和controller是沒有統(tǒng)一使用前綴，可以和第三方庫形成命名重復(fù)，同事在錯誤時不利于定位。如YHMainViewController,YHLessionPerformenceView等等 - 如在
CtrlMain中，變量mNoWorkInfo，mWrkChartLblShow,mLesLblDataContMain根本不知道是什么。其實(shí)是UIView，可以寫noWorkInfoView，至少知道是那一類，如果是UIButton，可以申明為UIButton *xxxButton，尾部帶上類名。 - 各種縮寫，不知道什么意思。（縮寫了而且沒有注釋），如主頁CtrlMain，至少應(yīng)該是MainViewController
- 私有方法同樣可以加前綴方便追蹤，如
p_doSomeThing,yh_doOtherThing. - 在網(wǎng)絡(luò)訪問時方法名如：
getTextFieldValue，getTokenWithMobile,一般可以改為textFieldValue,tokenWithMobile，等等。而且get很少使用，即使是表示動作累方法時。
*mLesLblDataContMain,這個必須單獨(dú)拿出啦，簡直就是奇葩，各種縮寫les，lbl，cont，沒有類，神仙也猜不到什么東東啊。居然是一個label對象，那個地方的lable呢自己估計都不知道。
可以參考《代碼命名規(guī)范》相關(guān)文章
Define
- 大量的宏定義，宏定義也存在命名不規(guī)范。關(guān)鍵是現(xiàn)在不推薦宏定義來定義變量，而是通過關(guān)鍵字
static和const來定義變量。
NS_ENUM
- 對于有限的選項可以使用enum來增強(qiáng)可讀性，避免使用0，1等。如：
typedef NS_ENUM(NSInteger, UIBarButtonItemStyle) {
UIBarButtonItemStylePlain,
UIBarButtonItemStyleBordered,
UIBarButtonItemStyleDone,
};
Switch
- 使用switch語句時，case下盡量不要寫整個方法的實(shí)現(xiàn)，應(yīng)把單獨(dú)寫一個方法。這樣一眼就可以看著每個分支的功能。如：
case UIBarButtonItemStylePlain:
[self doSomeThing];
break;
case UIBarButtonItemStyleBordered:
[self doOtherThing];
break;
備注：case UIBarButtonItemStylePlain：參考NS_ENUM。
代碼注釋
- 論壇上很多人對于代碼注釋持不同態(tài)度，可能認(rèn)為代碼注釋太多說明命名處理問題。但畢竟代碼注釋確實(shí)可以為以后維護(hù)提供了很大的方便，尤其是在命名方面不是特別好，設(shè)計很好的情況下建議加注釋。也為以后生成文檔提供了方便，如
appledoc工具。
屬性關(guān)鍵字copy，readonly
- 如果不希望外邊修改開放的屬性，可以使用擴(kuò)展。如果必須對外開放的屬性盡量使用
readonly關(guān)鍵字修飾屬性，設(shè)置為只讀，格外寫類似add，remove方法進(jìn)行修改。 - 如果是NSString類型盡可能使用copy關(guān)鍵字修飾，防止對象被修改導(dǎo)致聯(lián)動。
UIViewController
controller扮演的角色是數(shù)據(jù)管理，數(shù)據(jù)調(diào)配。不相關(guān)的事情最好不要放到里邊，最好封裝提供接口。
- 大量的view初始化代碼都放到conroller中，導(dǎo)致controller代碼臃腫。導(dǎo)致主要的邏輯被view模塊給淹沒，很不利用擴(kuò)展維護(hù)。 可以對view進(jìn)行封裝，使用懶加載，在getter中統(tǒng)一初始化。這樣只有主要邏輯（強(qiáng)業(yè)務(wù)）放到controller中。
- CtrlMain中成績展示寫死在controller中，每次修改都要修改contrller中代碼不利于擴(kuò)展。比如增加減少科目等。
- 網(wǎng)絡(luò)訪問也可以封裝一個類似
NetWork類，提供網(wǎng)絡(luò)獲取數(shù)據(jù)，只給controller提供一個借口訪問獲得數(shù)據(jù)，具體怎獲得，使用的什么網(wǎng)絡(luò)庫，controller不應(yīng)該知道。 - controller臃腫，之前有博客分享controller中只應(yīng)該有這幾個分層
#pragam LifeCycle、#pragam Event Method、#pragam Delegate、#pragam Pravite Method、#pragam Setter and Getter。原則就是能不放到controller中的就不放，全部模塊化有利于維護(hù)和擴(kuò)展。
代碼小習(xí)慣
- 蘋果建議多使用類似
CGRectGetWidth(CGRect)，少使用[[UIScreen mainScreen] bounds].size.heigh簡單復(fù)用，更可讀，如：
WorkSubjectsView *wrkSubject = [[WorkSubjectsView alloc] initWithFrame:CGRectMake(Subject_DIV * [[UIScreen mainScreen] bounds].size.width + (i % 3) *(Subject_DIV + Subject_width) * [[UIScreen mainScreen] bounds].size.width,[self getViewBottom:seperateLine] +(Subject_Div_Vertical - Subject_Hight) *[[UIScreen mainScreen] bounds].size.height + (i / 3) * Subject_Div_Vertical *[[UIScreen mainScreen] bounds].size.height,Subject_width * [[UIScreen mainScreen] bounds].size.width, Subject_Hight * [[UIScreen mainScreen] bounds].size.height)];
可以把 [[UIScreen mainScreen] bounds].size.height單獨(dú)拿出來
CGFloat height = CGRectGetHeight([UIScreen mainScreen].bounds);
CGFloat width = CGRectGetWidth([UIScreen mainScreen].bounds);
使用height和width替換 [[UIScreen mainScreen] bounds].size.height，方法會簡短很多，更易讀。
可以參考文章：iOS應(yīng)用架構(gòu)談 view層的組織和調(diào)用方案
關(guān)于代碼設(shè)計
- 主頁包含了三個CtrlMain，分別是老師端，家長端，學(xué)生端，分別實(shí)現(xiàn)了loadView 而且主界面非常相似，簡單的辦法可以使用一個Util抽出重復(fù)代碼，好一點(diǎn)的辦法把相關(guān)view抽出使用組合方式實(shí)現(xiàn)CtrlMain，從而實(shí)現(xiàn)代碼復(fù)用，即便view樣式變化也不用再去修改CtrlMain代碼。
自己也在學(xué)習(xí)中，可以參考《大話設(shè)計模式》、《iOS設(shè)計模式》書籍。
關(guān)于代碼強(qiáng)迫癥
- 大量的警告，很多都是方法過期，以及常量轉(zhuǎn)換問題，盡管對運(yùn)行一般沒有影響，但如我我們自己特意寫的警告可能會被淹沒，不好尋找。
- 使用Analyze分析大量的內(nèi)存泄露，以及l(fā)ogic error，以及dead store *
只要稍微花一點(diǎn)時間檢查就可以避免警告，很多人說寫代碼最低的要求就是，零警告并且可以通過Analyze測試。當(dāng)然我們還可以使用instruments進(jìn)行更多的優(yōu)化
