从我大三下学期开始工作开始, 几乎都是孤独的开发 因为身边开发ios 不多 ,除了学习开源的代码优秀风格技巧 剩下的 就是自己造, 所以 养成了 好多不好的习惯. 本知道面向对象的好处 ,但是实际开发起来总会有堆砌代码的坏习惯 ,只顾解决当前问题,于是UIViewController里面写了一堆堆有的没的,功能点是实现了,但是没给自己留后路,往往改起来牵一发动全身,当产品准备高保真调试UI时候头疼的对我说,"你的动态高度是算出来的吗, 我都不知道怎么改 都写在一起了 为什么不一个子View 一个模型呢"
于是在2015年第一次CodeReview 我总结了如下的几条开发编程意见
我觉得这是我从事开发以来最大的进步,一直都是自己在"造" ,没人告诉你自己哪里错了, 其实被提出了这么多条意见 ,我其实内心是拒绝的 ,因为也算是一种批评吧 . 但是 当我再开始开发豁然开朗一片光明,逼格也瞬间提升,写出高质量代码的程序媛 才是高级IT工程师 才区别于搬砖工 . 向上吧 少女 这是历史的进步 以后会更加光明
- 有运用到逻辑运算符的时候 一定两边要加空格或者回车
- 方法名尽量说明白 方法作用
- 方法名开头一定要小写
- 遇到写tableVIewCell 时候 尽量分割成最简单的元素 修改起来也好改 计算高度也不容易混淆， 尤其是有动态高度的时候 一定要单独成为一个模块cell或者一个cell中 独立的一个模型uiview
- 初始化一个tableViewcell 尽量使用 复用机制 t提高效率 这个适用于统一模式的 如果是有变化的 话 不适用会出现被覆盖的情况
- UI加载数据的时候 数据准备尽量提前做好
- UI界面复杂时候 要拆分成几个分支UI界面写成视图模型 避免修改过程中牵一发动全身
- 动态修改UI 位置和大小 .frame 要尽量少使用 这个特别耗时 低效,修改意见是 换成CGRectGetMaxX CGRectGetMaxX CGRectGetWidth CGRectGetHeight
- 方法要从整体观念上修改 修改局部是意义不大的 比如症状方法排序 从根本上就应该排序不应该在实例运用的时候再排序