【读书笔记与思考】《clean code》一到三章

写在前面：

阅读本书有两种原因：第一，你是个程序猿；第二，你想成为更好的程序猿

虽然大一大二写了一些东西，但是很多东西是不符合代码规范的。所以这本书我的计划是迅速推进，然后一点点运用。。。将里面感觉有歧义的点总结和讨论一下。大三这一年多写一些东西，但是还是要把重心放到读书上面

第一章：整洁代码：

我们永远跑不掉代码，因为代码呈现了需求的细节。在某些层面上，这些细节无法被忽略或抽象，必须明确之。将需求明确到机器可以执行的细节程度，就是编程要做的事。而这种规约正是代码

反思：自己大一大二动手做东西确实少了，看书也没有形成一个完善的体系。所以永远要改变。不能停止改善自己的体系。

1.3 混乱的代价：

修改无小事，随着混乱的增加，团队生产力也持续下降。
制造混乱无助于赶上期限。赶上期限的唯一方法——做得快的唯一方法——就是始终尽可能保持代码整洁。

反思：看sicp之类的六星神书等等，总在说我们是艺术家，我们艺术到哪了？艺术就艺术到这了。我们不应该忍受混乱代码

1.3.4 整洁代码的艺术

有无代码感的区别：

缺乏“缺乏代码感”的程序猿，看混乱是混乱。有“代码感”的程序猿能从混乱中看出其他的可能与变化。
“代码感”帮助程序员选出最好的方案，并指导程序猿制定修改行动计划，按图索骥。

反思：看不出来看不出来看不出来。。。

编写整洁代码的程序猿就像是艺术家，它能用一系列变换把一块白板变作由优雅代码构成的系统

反思：白板还是可以变成优雅系统的，但是黑板并不能。。。太混乱的系统只能被抛弃

1.3.5整洁代码的特性：

• 能通过所有测试
• 没有重复代码
• 体现系统中全部设计理念
• 包括尽量少的实体，比如类、方法、函数等

第二章：有意义的命名

2.2 名副其实：

变量、函数或类名的名称应该已经答复了所有的大问题。他该告诉你，他为什么会存在，他做什么事，应该怎么用。如果名称需要注解来补充，那就不算是名副其实。

掩盖魔术数：

将数字尽可能的替代成大写的变量名称。
反思：这样会好很多。——这样很容易就能知道干了点啥事啊。。。

第三章：函数

3.1 规则：短小

3.2只做一件事：

函数应该只做一件事。做好这件事，只能做这一件事
反思：重要的事情说三遍啊。。。

方法：

要判断函数是否不止一件事，还有一个方法，就是看是否能再拆出一个函数，该函数不仅是单纯地重新诠释其实现

3.3每个函数一个抽象层级

反思：我实际上有点儿不理解这一块。很奇怪。我要请教一下。。。完了再写
//TODO

3.4 switch 语句

这里在讲你要是把switch语句扔进你的函数逻辑里，你就违反了巴拉巴拉一堆规则。所以呢，你的一大堆判断语句，应该扔进一个独立的函数里面。

反思：emmm一大堆面向对象规则我也会补充进博客的。。。

//TODO
switch 和抽象工厂的结合的博文

3.5 使用描述性的名称

函数越短小、功能越集中、就越便于取个好名字
长而具有描述性的名称，要比短而令人费解的名称好
别害怕花时间去取名字

3.6函数的参数问题：

最理想的参数数量是零，其次是一，再次是二，应尽量避免三。
有足够特殊的理由才能使用三个以上参数。

参数与函数名处在不同的抽象层级，他要求你了解目前并不特别重要的细节。

反思：你要是有很多个参数，说明你没有很好使用了类这个东西，去捏合彼此。你的数据是散乱的。所以这个地方就会出现代码的不整洁

3.7-3.8 看不懂。。。

3.9 使用异常代替返回错误码