我的github：codetoys，所有代码都将会位于ctfc库中。已经放入库中我会指出在库中的位置。
这些代码大部分以Linux为目标但部分代码是纯C++的，可以在任何平台上使用。
之前有一个功能感觉有点复杂，属于优化性质，提高速度的，一直拖着没写。近日终于决定动手，谁知道竟然很快写出来并且一次性运行成功，心里像喝了冰雪碧一样爽啊。
有些事情并不像想象的那般困难，当然也不是很简单。我们需要遵循很多的原则——以及不能遵守很多原则。
优雅不是一个原则
如果你喜欢优雅，你可以去跳芭蕾。
简洁不是一个原则
有时候我们理解的“简洁”=“偷懒”，以及“详尽”=“冗长”。
没人有资格谈论完美
但总有些人比你有资格。而大部分人，根本不知道完美是什么。
尽可能函数化
把尽可能多的细节隐藏在函数里，主干代码只调用含义清晰的函数。
比如文件操作的各种参数，即使是各种包装类也避免不了函数调用中使用各种常数和枚举。作为一个共享库当然没有办法，但是作为一个具体应用程序，通常我们只使用非常有限的几种方式，包装成几个函数就可以避免因为一个参数用错导致的BUG。
函数化相似代码
有些代码段很相似，但功能没什么关联，很多人就觉得不应该写成一个函数。其实函数没什么定数，必须要怎么怎么才能做函数，写一个叫做“doSomeIfThenAndCheckSome”并且有十个参数的函数也没什么不可以的。
其实，如果两段代码很相似，它们必定有什么共同的东西在里面，只不过你还没有理解到啊。无论如何，大段代码复制然后稍作修改都是BUG之源。
多级变量参数化
如果一段代码频繁使用一个多级变量（比如a.b.c->x[y]），定义一个独立参数。这好像是印度人的教条，你知道印度人在硅谷是什么地位吧？
把一个相对独立的代码段用到的变量都参数化，可以在下一次用到类似代码的时候——这时候应该把这段代码函数化——简化函数化过程，只需要把这几个参数挪到函数声明就可以了。
尽量使用包装类型
任何具有业务含义的东西，都要定义成类（或者结构，在C++类和结构是一个回事），即使这个类里面只包含一个整数。
看起来这增大了工作量，但是，在调整代码的时候，类的严格约束将极大地确保不会遗漏修改点，并且很容易对功能做修改（这其实是函数化的好处）。而基本类型因为存在大量的自动转换而没什么约束性。
尽量使用长函数名
我知道很多人会对此表示反对，但是你可以换一个更大的显示器。
重点不是函数名的长度，而是函数名尽量全局唯一，这将极大地方便代码搜索（C#表示轻蔑，“这也算个事？”）。为了实现函数名唯一，不可避免地要加上类名前缀，这样长度就变长了。
如果一个函数的功能很奇怪，那名字最好长一点，把话说清楚，别藏着掖着。
使用明确长度的整数类型
如果需要在不同环境下使用，兼容性是一开始就要考虑的。一个典型的兼容性问题是int的长度，如果业务的数据对长度有约束，应该使用int32_t之类的确定长度的类型。
用typedef增加类型灵活性
如果不是很确定需要的长度，可以用typedef来给未来留个方便，不过typedef的约束远没有类强。
通过改名来确保全部修改
所有措施的最终目标都是希望能通过编译器发现改动涉及到的点，这样在无需审查全部代码的情况下对局部做修改就很容易。
反过来说，不能通过改名来发现全部修改点的代码就不是好代码。
很明显，编程语言的很多高级特性都是违背这一条的：
- 局部变量覆盖全局变量，删除局部变量程序编译不会出错，然而运行出错
- 函数重载，删除其中之一编译器可以通过自动类型转换成功编译，然而运行出错
- 覆盖基类属性和方法，修改或删除子类属性和方法不影响编译，然而运行出错
- 默认参数，不参与函数识别（不是函数签名的一部分），可能诱发错误匹配（人为误解），修改默认值不影响编译，然而运行出错
- 多级定义的虚函数，基本无法理解，建议严格按照接口规范来使用虚函数，单层实现，绝不覆盖基类已经实现的虚函数，坚决使用override
（这里是结束）
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
