感觉再不把这本书看完都可能要再版了。
前言
即便两个人实现同一个功能，最终效果看上去也一模一样，但代码质量却可能有着云泥之别。
第一章: 变量与注释
编程是一个通过代码来表达思想的过程。 p001
非常认同。
好的变量和注释并非为计算机而写，而是为每个阅读代码的人而写（当然也包括你自己）。变量与注释是作者表达思想的基础，是读者理解代码的第一道门，它们对代码质量的贡献毋庸置疑。 p002
代码是写给人看的。
为变量命名要结合代码情境和上下文。
尽量不要超过 4 个单词。
注释作为代码之外的说明性文字，应该尽量提供那些读者无法从代码里读出来的信息。描述代码为什么要这么做，而不是简单复述代码本身。
有时候喜欢为某一区块的代码写一个注释，这种其实也不算上面的两类中。
无论代码写得多好，多么“自说明”，同读代码相比，读注释通常让人觉得更轻松。注释会让人们觉得亲切（尤其当注释是中文时），高质量的指引性注释确实会让代码更易读。
是的。README 虽然在代码之外，但同样也是类似的目的。
名字一致性是指在同一个项目（或者模块、函数）中，对一类事物的称呼不要变来变去。 类型一致性则是指不要把同一个变量重复指向不同类型的值。
现在都习惯在不同项目中，都尽量保持一致性。
在组织代码时，我们应该谨记: 总是从代码的职责出发，而不是其他东西。
变量定义尽量靠近使用，非必要的情况下，不要写在一起或者放到函数最前面。
直接翻译业务逻辑的代码，大多不是好代码。优秀的程序设计需要在理解原需求的基础上，恰到好处地抽象，只有这样才能同时满足可读性和可扩展性方面的需求。抽象有许多种方式，比如定义新函数、定义新类型，“定义一个临时变量”是诸多方式里不太起眼的一个，但用得恰当的话效果也很巧妙。
有道理。
不必为了那些未来可能出现的变动，牺牲代码此时此刻的可读性。如果以后需要定义变量，那就以后再做！
是的，很多时候也没必要为了 return 返回单独定义一个变量。
在写代码时，可以适当地在代码中插入空行，把代码按不同的逻辑块分隔开。
已经是理所当然的一件事了。
先写注释，后写代码
习惯上会在写函数名前，写 todo，也算是吧吧吧