读代码随笔

---

命名

• 在定义各种view和controller是没有统一使用前缀，可以和第三方库形成命名重复，同事在错误时不利于定位。如YHMainViewController,YHLessionPerformenceView等等
• 如在CtrlMain中，变量mNoWorkInfo，mWrkChartLblShow,mLesLblDataContMain根本不知道是什么。其实是UIView，可以写noWorkInfoView，至少知道是那一类，如果是UIButton，可以申明为UIButton *xxxButton，尾部带上类名。
• 各种缩写，不知道什么意思。（缩写了而且没有注释），如主页CtrlMain，至少应该是MainViewController
• 私有方法同样可以加前缀方便追踪，如p_doSomeThing,yh_doOtherThing.
• 在网络访问时方法名如：getTextFieldValue，getTokenWithMobile,一般可以改为textFieldValue,tokenWithMobile，等等。而且get很少使用，即使是表示动作累方法时。
  *mLesLblDataContMain,这个必须单独拿出啦，简直就是奇葩，各种缩写les，lbl，cont，没有类，神仙也猜不到什么东东啊。居然是一个label对象，那个地方的lable呢自己估计都不知道。
  可以参考《代码命名规范》相关文章

Define

• 大量的宏定义，宏定义也存在命名不规范。关键是现在不推荐宏定义来定义变量，而是通过关键字static 和 const来定义变量。

NS_ENUM

• 对于有限的选项可以使用enum来增强可读性，避免使用0，1等。如：

typedef NS_ENUM(NSInteger, UIBarButtonItemStyle) {
    UIBarButtonItemStylePlain,
    UIBarButtonItemStyleBordered,
    UIBarButtonItemStyleDone,
};

Switch

• 使用switch语句时，case下尽量不要写整个方法的实现，应把单独写一个方法。这样一眼就可以看着每个分支的功能。如：

case UIBarButtonItemStylePlain:
    [self doSomeThing];
    break;
case UIBarButtonItemStyleBordered:
    [self doOtherThing];
    break;

备注：case UIBarButtonItemStylePlain：参考NS_ENUM。

代码注释

• 论坛上很多人对于代码注释持不同态度，可能认为代码注释太多说明命名处理问题。但毕竟代码注释确实可以为以后维护提供了很大的方便，尤其是在命名方面不是特别好，设计很好的情况下建议加注释。也为以后生成文档提供了方便，如appledoc工具。

属性关键字copy，readonly

• 如果不希望外边修改开放的属性，可以使用扩展。如果必须对外开放的属性尽量使用readonly关键字修饰属性，设置为只读，格外写类似add，remove方法进行修改。
• 如果是NSString类型尽可能使用copy关键字修饰，防止对象被修改导致联动。

UIViewController

controller扮演的角色是数据管理，数据调配。不相关的事情最好不要放到里边，最好封装提供接口。

• 大量的view初始化代码都放到conroller中，导致controller代码臃肿。导致主要的逻辑被view模块给淹没，很不利用扩展维护。 可以对view进行封装，使用懒加载，在getter中统一初始化。这样只有主要逻辑（强业务）放到controller中。
• CtrlMain中成绩展示写死在controller中，每次修改都要修改contrller中代码不利于扩展。比如增加减少科目等。
• 网络访问也可以封装一个类似NetWork类，提供网络获取数据，只给controller提供一个借口访问获得数据，具体怎获得，使用的什么网络库，controller不应该知道。
• controller臃肿，之前有博客分享controller中只应该有这几个分层
  #pragam LifeCycle、#pragam Event Method、#pragam Delegate、#pragam Pravite Method、#pragam Setter and Getter。原则就是能不放到controller中的就不放，全部模块化有利于维护和扩展。

代码小习惯

• 苹果建议多使用类似CGRectGetWidth(CGRect)，少使用[[UIScreen mainScreen] bounds].size.heigh简单复用，更可读，如：

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单独拿出来

CGFloat height = CGRectGetHeight([UIScreen mainScreen].bounds);
CGFloat width  = CGRectGetWidth([UIScreen mainScreen].bounds);

使用height和width替换 [[UIScreen mainScreen] bounds].size.height，方法会简短很多，更易读。

可以参考文章：iOS应用架构谈 view层的组织和调用方案

关于代码设计

• 主页包含了三个CtrlMain，分别是老师端，家长端，学生端，分别实现了loadView 而且主界面非常相似，简单的办法可以使用一个Util抽出重复代码，好一点的办法把相关view抽出使用组合方式实现CtrlMain，从而实现代码复用，即便view样式变化也不用再去修改CtrlMain代码。

自己也在学习中，可以参考《大话设计模式》、《iOS设计模式》书籍。

关于代码强迫症

• 大量的警告，很多都是方法过期，以及常量转换问题，尽管对运行一般没有影响，但如我我们自己特意写的警告可能会被淹没，不好寻找。
• 使用Analyze分析大量的内存泄露，以及logic error，以及dead store *

只要稍微花一点时间检查就可以避免警告，很多人说写代码最低的要求就是，零警告并且可以通过Analyze测试。当然我们还可以使用instruments进行更多的优化