代码精进之路

Author：我是付大善人

前言

本前言不是该课程自带的开篇词，而是我本人写这篇文章的前言。

8月份给自己定了一个小计划，要学习完极客时间《Spring》、《玩转Git三剑客》、《代码精进之路》三个课程。代码精进之路是本月学习的第一个课程。

今天主要看了第一部分，可能是因为之前读过《Clean Code》这本书，感觉这个课程并没有太多有用的干货。

第一，这个课程让我觉得废话太多。也可能是我功利主义的心，我觉得文章中很多文字都写得很虚，也就是给人一种读完没什么感受的心。让我这种平时喜欢记录笔记的人，从第8课开始往后连续看了几节课感觉都没有什么可以让我记录笔记的知识了。

而且这里面给的例子感觉也不是很好。那么短的例子，很多像Lambda表达式、代码留空白行的实战都没有，倒不如给一些项目中实战的例子。

总体而言，感觉这节课略失望，希望《玩转Git三剑客》不要太让人失望。

1.条件运算符

三元运算符只用于简单的判断

03. 优秀程序员的六个关键特质.

• 掌握一门编程语言
• 解决现实的问题
• 发现关键的问题
• 沉静的前行者
• 可以依赖的伙伴
• 时间管理者

04. 代码规范的价值：复盘苹果公司的GoToFail漏洞

阿里巴巴 java 开发规范，官方已提供了 idea、eclipse 插件，详情可以访问官方链接：https://github.com/alibaba/p3c/blob/master/README.md

此外还有FindBugs、PMDPlugin、CheckStyle
、JavaNCSS、sonarlint，可以多管齐下，为你保驾护航。

我现在个人用的是sonar Lint 和 阿里的代码规约检查插件

05. 经验总结：如何给你的代码起好名字？

常见命名方法

1.驼峰命名法
有时候，一个名字可能有不只一种合理形式，比如缩略语（IPv6）或者异常的结构（iOS)。 为了减少这种不确定性，Google定义了以下的转换规则：

从正常的表达形式开始，把短语转换成ASCII码，并且移除单引号。 例如，“Müller’s algorithm”转换为“Muellers algorithm”；

如果上述结果含有其他标点符号，比如连字符，在该符号处，把这个结果切分成单词形式。 如果某个单词已经是驼峰形式，也相应地切分开来。 例如，“AdWords”切分成“ad words”，“non-current assets”切分成“non current assets”；

将所有字母转换为小写字母，然后将每个单词的首字母大写，这样就得到了大驼峰式命名的形式； 如果第一个单词的首字母小写，就得到了小驼峰式命名的形式；

将所有的单词连在一起，就是最后的标识符命名。

下面的表格列出了不同例子的正确转换形式，和容易出错的转换形式 （出自“Google Java Style Guide”）。

image
2.蛇形命名法（snake_case）

在蛇形命名法中，单词之间通过下划线“_”连接，比如“out_of_range”。

3.串式命名法（kebab-case）

在蛇形命名法中，单词之间通过连字符“-”连接，比如“background-color”。

4.匈牙利命名法（已过时）

Q&A
范老师，一直有个疑问，有时候为了方法名或类名更好的表意，会把名字起的比较长，但名字太长也感觉不太优雅，这方面有什么好的经验吗？

如果名字没有超过20个字符，长一点也没关系。如果是代码内部使用标识符，要是使用它的代码还能保持在80个字符以内，再长一点也可以。毕竟，容易理解是最重要的。

请教：iOS 这种写法算不算特殊情况的固定写法呢？比如 supportIOS 比 supportIos 看着更一目了然？

Google的规范，会使用Ios，supportIos，但是我不认为这个用法的可读性好，但是supportiOS的可读性更差。supportIOS的确看起来更好。

06. 代码整理的关键逻辑和最佳案例

一般的换行原则包括以下五点

• 在逗号后换行

String variable = anObject.getSomething(longExpressionOne,
        longExpressionTwo, longExpressionThree);

• 在操作符前换行

String varibale = longStringOne + longStringTwo
        + longStringThree;

• 高级别的换行优先
• 新的换行与上一行同级别表达式的开头对齐。
• 如果上述规则导致代码混乱或者代码太靠右，使用8个空格作为缩进（两个缩进单位）。

07. 写好注释，真的是小菜一碟吗？

7-1 注释是无奈的妥协

• 因为注释不需要运行，所以没有常规的办法来测试它
• 注释难以维护，这是使用注释带来的最大的麻烦
• 注释，被我们用成万能的狗皮膏药，有时会让代码更糟糕

7-2 几种常见注释类型

• 第一种类型，是记录源代码版权和授权的
• 第二种类型，是用来生成用户文档的，比如Java Doc。
• 第三种类型，是用来解释源代码的。

7-3 简化注释的风格

针对第三种注释类型，也就是代码解释注释，只使用行注释符（//）。 每行长度限制，和代码块的每行长度限制保持一致。

如果一段代码不再需要，我会清理掉代码，而不会保留这个注释掉的代码块。不要在源代码里记录代码历史，那是代码版本管理系统该干的事情。

7-4 注释用英文还是汉字呢？

你会注意到，上面的代码案例中，我基本使用的是英文注释，在这里我也建议你使用英文注释。

为什么呢？

因为使用中文注释，不是一个所有人都能接受的风格。一部分人，一部分公司，并不接受中文注释。特别是国际化的项目，比如说贡献给Apache的项目，就没有办法使用中文注释了。而且，如果是去面试，我也会尽最大的努力不使用中文注释，以免踩到坑。

08. 写好声明的“八项纪律”

• 取一个好名字
• 一行一个声明
• 局部变量需要时再声明
• 类属性要集中声明
• 声明时就初始化
• 尾随的花括号
• 靠紧的小括号
• 搜索优化的换行
  • 语义相关的词语，常见的搜索模式，要尽量放在用一行

09 怎么用好Java注解

无