简书好久没更新了, 说到这次的更新我更觉的像是一次检讨.
此时此刻,就让我来做一次深刻的检讨. 事情的起因是这样的: 前段时间,由于项目需要,我必须从OC转到Swift. 开始的时候各种不适应, 边学边写. 写出来的代码,很脏很脏. 基本上没有半点可读性可言. 这也不能全说是写Swift导致的, 根源是之前是一个人写, 写的脏乱差也什么关系. 反正自己看, 也没人做codereview. 项目也写完交给甲方也算完事了. 不需要考虑结构, 设计, 维护, 迭代, 所有一切都是一次性的, 也造成了各种野路子.
上个版本由于数据库迁移,要从原来的Coredata换成Realm, 我负责处理几个缓存也面. 新加分类的需求, 从Server端拿到排序规则, 再从本地查数据库重组数据. 开始的做的时候, 思路不清晰, 看文档不仔细, 漏掉一个重要的东西(没有转换成功的数据归结为一类). 做完之后才发现还有一块没考虑到, 这下就坑大了, 本来写好的东西里面要加新的情况:大量的 if else if else的嵌套把本来就没什么可读性的代码直接变成了一坨狗屎. 原来一直以为这样的代码比较牛逼 if 判断, 写成 a > b && do something. 其实盖不住自己内心深处还是个高中编程爱好者. 经过老大指点, 终于知道代码可读性才是第一次, 写的时候逻辑不能混乱, 比较复杂的时候可能做个思维导图.
接下来就是git提交规范, 之前由于没有好的习惯, 都是改了一大段之后直接提交. 通常一次提交里面可能做了7,8件事情. 有时候commit的header 还是内容对不上. 这为接下来的codereview 埋下了一颗定时炸弹.
过程就是这样的. 知道问题在哪之后对应的就要做出改变:
首先: 命名 Naming
好得变量命名
差得命名
不要全部要大写,不用简写. 是用驼峰
函数方法命名
如果只有一个参数写函数名的时候就把要做的事情,和参数写进去.
如果有多个参数, 需要在函数参数体里面写清楚每个参数.
Swift 有空间命名,所以不需要在类名前面加前缀, 他编译之后不会像OC把所有文件都编译到一个二进制文件下. 你只需要保证每个target下面的类名唯一就行.
定义Sel时候采用:
let sel = #selector(viewDidLoad)
不要这样:
let sel = #selector(ViewController.viewDidLoad)
是用泛型的时候,采用 T, U 或者 V, 不要采用 Things这样的命名
用extension 给 Class 分类, 保证每个extension 都对应有一个MARK
要像这样
不要做这样的
这样做好的好处就是当你control + 6的时候看到的是:
它能快速帮你定位代码
不用的注释都删除,不要的代码也不要保留. 这样做后期维护的时候能省不少事.
别把else的语句拆到下一行
不要嵌套if 的逻辑
是用编译器的类型推断,而不是你去声明
是用语法糖
是用函数代替方法
guard let 替换 if let
以上资料参考自: https://github.com/raywenderlich/swift-style-guide
愿大家都有个好的编码习惯.
网友评论