代码可读性是第一生产力

简书好久没更新了, 说到这次的更新我更觉的像是一次检讨.

此时此刻,就让我来做一次深刻的检讨. 事情的起因是这样的: 前段时间,由于项目需要,我必须从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

愿大家都有个好的编码习惯.

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 转至元数据结尾创建: 董潇伟,最新修改于: 十二月 23, 2016 转至元数据起始第一章:isa和Class一....
    40c0490e5268阅读 5,842评论 0 9
  • 发现 关注 消息 iOS 第三方库、插件、知名博客总结 作者大灰狼的小绵羊哥哥关注 2017.06.26 09:4...
    肇东周阅读 14,222评论 4 61
  • 《与神对话》的作者尼尔·唐纳德·沃尔什出生于1943年,一生可谓是相当凄惨:大火毁去全部财产,婚姻四次失败,车祸几...
    唐公子1阅读 5,209评论 0 1
  • 本文是看了公众号的文章,非常感谢,链接如下 https://mp.weixin.qq.com/s?__biz=Mz...
    正阳Android阅读 3,790评论 0 4
  • DAY12 阅读写作100天 特别喜欢蒋勋老师的作品,不管是细说红楼,还是孤独六讲,作品本身喜欢,老师的声...
    岂有此女丫阅读 4,241评论 0 1