// |json_file_path_| is the path of a file that will be source of the
// deserialization. |options| is a bitmask of JSONParserOptions.
explicit JSONFileValueDeserializer(
const base::FilePath& json_file_path,
int options = base::JSON_PARSE_CHROMIUM_EXTENSIONS);
上面代码是chromium base 库中关于json 解析工具的注释，它解释了两个参数的作用。
一个不好的写法如下，对参数的注释是这个函数在做什么，而不是参数本身的说明：
// We parse the file with the |json_file_path| path, passing in the
// bitmask of JSONParserOptionstype |options| in the process
explicit JSONFileValueDeserializer(
const base::FilePath& json_file_path,
int options = base::JSON_PARSE_CHROMIUM_EXTENSIONS);
💻 代码思考 存在多个指针类型 out 函数参数，特别小心的是当其中一个out参数取值错误，其他out参数的赋值情况。
比如
当返回值为false的时候，理论上out1 和 out1 仍然是nullptr，外部不需要释放任何资源。
因此在 Getxxx 函数内部实现的时候，可能会出现ptr 赋值成功，ptr2 赋值失败，此时返回值为false，导致外部没有意识到需要释放out1 的空间导致内存泄露。因此在内部实现的时候，应该等ptr 和ptr2 的内容都获取到后，再给两个指针赋值。
请问时光机要怎样支持代码高亮？
和文章中插入代码块方式一样，使用markdown语法即可
已开启评论的 Markdown 支持，在评论中使用 反引号 包裹代码没成功……
可以看下主题使用文档——常见问题里面的评论相关里面有的
💻 代码思考 好的注释应该是解释性语言，而不是动作性语言。具体例子：
上面代码是chromium base 库中关于json 解析工具的注释，它解释了两个参数的作用。
一个不好的写法如下，对参数的注释是这个函数在做什么，而不是参数本身的说明：
💻 代码思考 以往工作中常用的设计模式只有代理模式、观察者两种，似乎不太需要太复杂的设计模式。这一周工作主要是重构了之前写的一部分代码来支持更通用化的需求。因为这个需求中设计到很多状态的转换，每个状态都会有几个分支，尝试了状态设计模式，设计状态，设计每个状态会执行的动作，设计每个状态执行相应动作应该转移到的下一个状态以及副作用行为。Xstate 项目的可视化非常方便提前先构建好整个状态机的模型。
写完之后，能很明显的感觉代码思路清晰很多。之前是在很多基础模块中去判断状态，然后进行对应的行为，这次所有的状态管理全部收敛到一个controller中，状态的转移过程对外是不可见的，外部基础模块只要调用controller的对应动作方法，controller会将工作委托给对应的状态处理。不再需要像之前那样，先获取当前状态，再判断当前状态，最后执行某个行为转移到新的状态。
同时一个独立的功能需求的代码设计是不应该嵌入到一些基础类型的模块中的，而是应该写一个controller，将需要使用的基础模块作为该controller的成员指针来使用。
💼 工作记录 💻 代码思考在正式工作之前，我没有写过单测，主要是平时自己写的代码通常耦合度较高，没有单独抽象设计模块的概念。
最近开始写一些通用能力的基础库需要写单测。第一次单测的编写是在代码基本完成后开始写的，完成单测后会发现一些bug，于是修改bug。但这个过程中会发现代码设计的一些不合理之处，比如多个接口的返回值是否更统一，对于接口可能出现错误时的返回值，应该如何处理（这个可以多参考chromium base库中的代码实现）。如果一个模块的多个接口设计不统一、那么单测同样也会非常复杂。
其实上面的过程就有点TDD那味了，但是测试驱动开发，需要先写一个无法通过的测试，通过修改代码来使得测试通过，再重构代码。在这个过程中不断的开发代码，而不是先写完代码，再写单测试。
单测的重要性是毋庸置疑，因为代码复杂性总可能出现某个分支逻辑错误。因此TDD将单测与开发结合，减轻了写单测的难度和压力，同时也能通过单测进一步发现代码的设计问题。
参考文章：