设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
19134 人已学习
课程目录
已更新 35 讲 / 共 100 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训,让你告别没有成长的烂代码!
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识?
02 | 从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?
03 | 面向对象、设计原则、设计模式、编程规范、重构,这五者有何关系?
设计原则与思想:面向对象 (11讲)
04 | 理论一:当谈论面向对象的时候,我们到底在谈论什么?
05 | 理论二:封装、抽象、继承、多态分别可以解决哪些编程问题?
06 | 理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗?
07 | 理论四:哪些代码设计看似是面向对象,实际是面向过程的?
08 | 理论五:接口vs抽象类的区别?如何用普通的类模拟抽象类和接口?
09 | 理论六:为什么基于接口而非实现编程?有必要为每个类都定义接口吗?
10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?
11 | 实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?
12 | 实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?
13 | 实战二(上):如何对接口鉴权这样一个功能开发做面向对象分析?
14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?
设计原则与思想:设计原则 (12讲)
15 | 理论一:对于单一职责原则,如何判定某个类的职责是否够“单一”?
16 | 理论二:如何做到“对扩展开放、修改关闭”?扩展和修改各指什么?
17 | 理论三:里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?
18 | 理论四:接口隔离原则有哪三种应用?原则中的“接口”该如何理解?
19 | 理论五:控制反转、依赖反转、依赖注入,这三者有何区别和联系?
20 | 理论六:我为何说KISS、YAGNI原则看似简单,却经常被用错?
21 | 理论七:重复的代码就一定违背DRY吗?如何提高代码的复用性?
22 | 理论八:如何用迪米特法则(LOD)实现“高内聚、松耦合”?
23 | 实战一(上):针对业务系统的开发,如何做需求分析和设计?
24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?
25 | 实战二(上):针对非业务的通用框架开发,如何做需求分析和设计?
26 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?
设计原则与思想:规范与重构 (6讲)
27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?
28 | 理论二:为了保证重构不出错,有哪些非常能落地的技术手段?
29 | 理论三:什么是代码的可测试性?如何写出可测试性好的代码?
30 | 理论四:如何通过封装、抽象、模块化、中间层等解耦代码?
31 | 理论五:让你最快速地改善代码质量的20条编程规范(上)
32 | 理论五:让你最快速地改善代码质量的20条编程规范(中)
不定期加餐 (2讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
设计模式之美
登录|注册

31 | 理论五:让你最快速地改善代码质量的20条编程规范(上)

王争 2020-01-13
前面我们讲了很多设计原则,后面还会讲到很多设计模式,利用好它们可以有效地改善代码质量。但是,这些知识的合理应用非常依赖个人经验,用不好有时候会适得其反。而我们接下来要讲的编码规范正好相反。编码规范大部分都简单明了,在代码细节方面,能立竿见影地改善质量。除此之外,我们前面也讲到,持续低层次、小规模重构依赖的基本上都是编码规范,这也是改善代码可读性的有效手段。
关于编码规范、如何编写可读代码,很多书籍已经讲得很好了,我在前面的加餐中也推荐过几本经典书籍。不过,这里我根据我自己的开发经验,总结罗列了 20 条我个人觉得最好用的编码规范。掌握这 20 条编码规范,能你最快速地改善代码质量。因为内容比较多,所以,我分为三节课来讲解,分别介绍编码规范的三个部分:命名与注释(Naming and Comments)、代码风格(Code Style)和编程技巧(Coding Tips)。

命名

大到项目名、模块名、包名、对外暴露的接口,小到类名、函数名、变量名、参数名,只要是做开发,我们就逃不过“起名字”这一关。命名的好坏,对于代码的可读性来说非常重要,甚至可以说是起决定性作用的。除此之外,命名能力也体现了一个程序员的基本编程素养。这也是我把“命名”放到第一个来讲解的原因。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(43)

  • zyl
    什么时候开始 进入正题呀,前奏太长了

    作者回复: 先从第一篇开始就是正题啊 😂 前面的比后面的更重要呢 建议你回过头去再看下前几篇文章

    2020-01-13
    1
    12
  • 牛顿的烈焰激光剑
    课堂讨论:

    1. 关于 isValidPassword() 可读性优化: 示例代码中的单行注释已经把验证规则清楚列明,但是必须打开源代码才能看见。我认为可以在函数声明处使用文档注释(即多行注释)对规则进行描述,这样函数的使用者借助 IDE 的代码提示功能就能看到具体的规则,同时也为用工具生成的项目文档提供注释。

    2. 关于注释用中文还是英文的问题:对于团队开发,如果有外国人当然要用英文;但是如果只有中国人,我认为最好用中文。首先是每个人的外语水平不一,外语水平好的看到别人的语法错误甚至连单词都拼错,真的很影响心情。对于外语水平不太好的,使用外语写注释不友好且心理压力大,甚至回过头再看都不知道自己当初想表达什么。团队中最重要的是相互合作和最后上线的产品,而不是相互折磨,如果要求使用英文注释会推高沟通成本,那就得不偿失。对于个人项目,选择中英注释均可,但应统一风格。我认为注释只是一个工具,用于降低沟通成本和提醒自己写代码时的思维逻辑和一些关键步骤,但是切不要对这个工具有过高的期望,譬如提高个人甚至团队的外语水平。
    2020-01-13
    4
  • 李小四
    设计模式_31
    # 作业
    1. 可能是为了举例吧,我认为这里的4个注释都是多余的。这些注释并没有比代码更简洁,阅读注释与阅读代码的理解成本是一样的。
    2. 注释用中文还是英文,工作中一定要看团队成员的情况。个人推荐全部使用英文,从成长的角度来看,这有助于加强程序员的英文读写能力,而这个能力是非常有价值的。

    # 感想
    写代码的时候,我常常问自己一个问题。如果后面有一个人要接收我的项目,他会不会骂我。。。我就暗自骂过很多人。。。
    所以在某些与常规逻辑明显不同的地方,我的注释量甚至多于代码量。当然注释也不是越多越好。
    2020-01-13
    4
  • 阿卡牛
    编程的两大难题:并发和起名
    2020-01-13
    3
    3
  • Frank
    所谓无规矩不成方圆。同样我们在做一些事情的时候是有套路可寻的。在写代码的时候我们也需要遵循一些前人总结好的规范,使得自己写代码更具有可读性,可维护性。
           今天从这篇文章中学到了关于命名和注释的一些见解。关于命名,以前自己会犯的一个错是将拼音和英文会混在一起用,现在想想估计太年轻,命名搞得不伦不类。现在已经改了,一直督促自己用英文。命名的原则是准确达意,在平时的开发中都我都是尽量使用完整的单词,即使这样命名会很长,但是能够清楚的表达。文章中说的借助上下文来简化属性、函数的命名自己没有实践过。
           关于注释,在自己的开发习惯中对于类和方法都是要写注释的,但是自己对注释的理解比较浅,只是写了做什么。并没有从文中提到的“做什么、为什么、怎么做”这三个维度去考虑。对于一些非常简单的方法,如只有几行,一眼就能读懂其要表达的逻辑的,我一般不写注释。对于注释的维护的确是有一定的成本。某些时刻一个逻辑复杂的方法有变动,可能会忘记同步修改其对应的注释,就会导致之后的阅读理解有误导倾向。个人觉得类、方法的注释很重要,以前遇到自己不懂的,我都会到某度上去查,发现往往很多搜索结果解释的不够准确,常常会误导我。后面我几乎都是通过阅读官方文档来学习,如通过阅读JDK中JavaDoc的文档就能准确的理解某个函数能做什么,该怎么用。
           关于注释该用英文还是中文这个问题,个人觉得用中文可能比较好,因为大家母语都是中文,你不能按照自己的标准来想别人也能读懂你写的英文。除非是做国际化项目以及所在团队能接受注释全用英文那自然更好。
    2020-01-13
    2
  • 辣么大
    There are only two hard things in Computer Science: cache invalidation and naming things.-- Phil Karlton

    命名达意、准确:
    不知道如何命名,推荐:Codelf(变量命名神器) https://unbug.github.io/codelf/
    Search over projects from Github, Bitbucket, Google Code, Codeplex, Sourceforge, Fedora Project, GitLab to find real-world usage variable names.

    关于注释语言:
    公司的项目看项目要求(中英文都可以)
    自己的个人项目一定要用英文,因为一开始我就考虑到要做国际化的项目(目标是全球用户)。
    如何写注释可以多看看JDK源码中的注释,能够学到很多东西。
    2020-01-13
    2
  • 逍遥思
    在 User 类这样一个上下文中,我们没有在成员变量的命名中重复添加“user”这样一个前缀单词,而是直接命名为 name、password、avatarUrl。

    但示例代码好像都带了 user 前缀?
    2020-01-13
    2
  • 龙疯疯
    不够看啊,每天很快就看完了。
    2020-01-13
    1
  • 失火的夏天
    我司接口类前面有个I,实现类后面也有imlp。。。

    思考题1 比如判空那个注释就没必要了。我感觉是个人就应该知道是啥意思吧。

    思考题2 个人认为,如果英语水平过关的,可以写英文注释,但是英语三脚猫那种,你还是老老实实写中文吧。真人真事,我刚工作那会,做个手机维修得项目,有个后台服务叫做上门服务。然后我那睿智同事就写了个ondoorService,我看到了之后。。。Are you kidding me?
    2020-01-13
    3
    1
  • 密码123456
    注释肯定中文啊。毕竟母语。
    2020-01-13
    1
  • 乘坐Tornado的线程魔法师
    1. 可以考虑合并一部分简单的条件表达式,并且分拆过于复杂的条件表达式。
    2.注释的语言可以考虑这段代码的维护者的情况,如果中国人外国人都有那么可以考虑使用双语:)
    2020-01-13
    1
  • JM

    1. isValidPasword函数里面代码有重复逻辑check if password contains only lowercase characters可以被 check if password contains only a~z,0~9,dot包含, 所以可以去掉check lowcase char这个判断
    2. 关于英文和中文注释哪个好,取决于你的代码将来要给谁看。国内的开源framework要走向世界,就需要程序员添加英文注释。
    2020-01-15
  • 平风造雨
    注释推荐使用英文,只有一个要求,英文水平要过硬。如果英文水平不够,写英文注释没什么收益。
    2020-01-14
  • Farewell丶
    `boolean isValidPasword(String password)` 可以简化为 `boolean isValid(String password)`,
    甚至简化为`boolean valid(String password)`
    2020-01-14
  • 刘大明
    思考题1.
    我觉得很多注释没有意义,再就是一些判断条件可以合并没有必要拆分那么细。
    思考题2.如果项目中没有国外的同事参与的话,联系注释还是用中文,这样大家理解起来都方便。
    2020-01-14
  • 荀麒睿
    问题一:个人认为里面的每个判断可以抽出来形成函数,然后通过函数的命名来高知做了什么,同时在主要的函数上面加一些注释大致说明下做了哪几种判断。
    问题二:我觉得用英文注释比较好,一方面可以提升自己的英文水平,另一方面还可以提升同事的英文水平,一举两得,哈哈。😜
    2020-01-13
  • 斐波那契
    以前写c#的时候见过接口前+i 原来java也有啊

    对于注释 个人还是倾向写英文 这是对自己一个要求 为了写好注释就必须把英文学好 要想象自己写的代码有一天会让全世界人看到 写中文会存在编码问题 有时候就头疼
    2020-01-13
  • 木木
    如果命名或者注释不好写,可能说明这个方法写的不够好,可以优化。
    2020-01-13
  • qinsi
    很多现代程序设计语言都是支持Unicode标识符的,不仅是注释,变量命名用中文也是可能的
    2020-01-13
  • 编程界的小学生
    首先个人推荐阅读《代码整洁之道》,这个作者开篇也提到了。其次回答问题:
    1.缺少关键性的方法注释吧,因为这个函数有很多关键的验证,不仅仅是判空和长度
    2.能用英文就用英文,多用英文会无形中提升你阅读英文文章的能力以及英文看着就是比中文高大上、视觉舒服
    2020-01-13
收起评论
43
返回
顶部