命名和使用
类名首字母大写
变量、属性和方法名首字母小写驼峰
常量大写
命名使用英文含义单词或缩写
代码中使用了硬编码
API命名不清晰
代码风格
单行长度小于等于120个字符
缩进使用2个空格、4个空格或1个tab
代码行中保留适当的空格，不同功能代码之前保留适当的空行
代码循环或回调嵌套层次避免超过4层
类不要超过1000行，方法不要超过200行
函数参数小于等于4个，多于4个参数使用对象传递
未使用的代码，直接删除掉，避免多行代码的注释
对外提供的共有方法/属性、复杂逻辑部分，需要增加必要的注释
设计与开发
逻辑不清晰，或者冗余的
逻辑代码重复，相同功能代码应抽象为函数或类
入参合法性校验
功能API拆分清晰，简单易维护
提交代码时commit msg需要清晰明确
iOS API 不要以get/set开头，Android可以
只暴露必须的共有方法给外部使用，iOS在头文件中声明，Android用public关键字
成员变量Android以get/set方法提供，iOS以只读属性/方法在头文件中提供；
业务模块尽可能减少耦合, 耦合部分通过接口实现
API返回值设计不合理，例如db的update操作，都需要有返回值，同类型的不合理问题不重复计分
有逻辑bug，或者缺少临界值校验，可能导致异常crash的问题
日志与埋点
关键点需要使用UBT监控埋点
合理使用UserDefault/SharedPreference、Database、File等存储日志/数据
适当的使用日志API，生产环境应尽可能避免log直接输出到控制台
多线程
所有UI操作，必须在主线程
可变全局变量/成员变量的修改，必须要考虑到多线程同步
耗时操作必须放到非主线程操作
技术选型
尽可能使用公司标准，避免重复造轮子
如果该组件或方案公司已经提供，请采用公司方案
如果公司方案不能满足自己的需求，正确的做法是
提需求改进
提需求后仍然未改进，则升级处理
直接要求参与开发
如果公司没有现成方案，但是有开源方案，应该采用开源方案
其他 （ -5 ~ +5 ）
网友评论