Wut I am

《代码之丑（六）——分家的声明和使用》

变量声明的就近原则，除了该文中提到的几点好处之外，还有一点就是能够提高发现声明了却未使用的变量的概率。别小看这个问题，以为编译器会给优化掉，我就碰到过一坨很烂的代码，这个函数里做了大量的计算，比如先经过复杂计算得到 a，然后 a 经过计算得到 b，b 再经过计算得到 c，c 再计算后得到 d，在一团乱麻的代码里，谁也没发现，其实 d 根本没被用到，函数最后直接拿 e 返回了……

《代码之丑（七）——你的语言》

这篇有点各抒己见的意思，不过我觉得有一点是明确的，学一门语言，主要是学习它的思维方式，而不仅仅学会语法就算完了。至于具体怎么用，这是每个 team 自己定编码规范的事了。

CONTINUE READING »

《代码之丑（三）——switch陷阱》

可能是因为篇幅关系，这篇文章里的例子不够有代表性，而且还有越改越没有可读性和可维护性之嫌。曾经我在公司的一个比较有历史的程序里看到过一段伟岸的 switch/case 代码，每个 case 下的代码各不相同且长短不一也就算了，可能你无法想象的是，它里面竟然有几千个 case，总共 10000+ 行的代码！你没看错，一个函数一万多行！这就是从一开始放任 switch 陷阱，经过漫长地演化得到的后果。

其实我并不认为该把 switch/case 当作唯恐避之不及的恶魔，它只是一把双刃剑，就像没必要一味地反对使用 if 一样。在正确的环境下正确使用它的话，只会提高可读性，但如果滥用它（就像 C++ 很多其他特性那样），那的确是一场噩梦。

对于本身结构很简单的逻辑，使用 switch/case 能很好地保持其可读性（显然比一堆的 if/else 好，更不用说多态了），而且也正因为其逻辑简单，条件不多，也不会对系统性能产生明显影响（代码并非越短越快就越好，它首先是给人看的，顺便附带了能让机器执行的功能）。而对于我上面提到的超大的逻辑结构，倒是可以用多态或者状态机来解决，定位问题显然会方便不少（假如这个逻辑架构本身没法改变的话）。

CONTINUE READING »

我是一个很在意代码质量的人，因为我相信软件开发，细节决定成败（追求细节和拥有宏观视野本身并不矛盾，而且这是另一个话题了）。虽然我并不赞成将团队甚至公司中的每个人的编码风格都硬性规范到某种统一格式，那样不仅会扼杀程序员们的创造力，而且从成本收益来看太不划算了。但是，这并不意味着代码就可以随心所欲地写，所谓“规范”不该是“法律”上的，但一定是“道德”上的：你现在写的代码，要对半年后的你负责，更要对团队里其他同事们负责，甚至可能还有你的客户。而这种责任，不仅仅是代码的功能完整度，更包括可读、健壮和效率。

这几个月有幸参与了我们游戏提升稳定性和优化性能的工作，review了很多代码，这期间时长被各种“富有创造性的”代码雷得外焦里嫩的。碰巧正好看到了《代码之丑》系列文章，感触颇深，有些观点也有些自己的看法，记录下来，与大家探讨。

CONTINUE READING »

译自 zeuxcg 的《#include 》（墙外），有删改。请勿转载。
若不听劝告非要转载，请注明出处，谢谢。

我们没法摆脱 C++，至少短期内不太可能。我真希望 C++ 里没有那么多恶心的特性，但目前也没有真正能取代 C++ 的玩意。现代编程语言往往采用大宗编译（bulk compilation）和/或智能链接器，但 C++ 仍然受困于头文件分离的设计思想（当然从另一方面说，C++ 的这种设计也使得其构建过程可以是增量的、高度并行的），使得鱼与熊掌不可兼得。 这种分离头文件并保持代码清晰的策略很显而易见，但我却很纳闷为啥还有那么多人没搞明白到底该怎么使用头文件，希望这篇文章能够进一步理清这团乱麻。本文也适用于 C，但有幸使用其他语言的同学们请绕行。

包含头文件的问题在于预编译器很笨：你的代码告诉它要包含某个文件，那么它就会“递归地”包含整个文件内容；如果你不想包含那个文件却又想用该文件中定义的一个符号呢，那你只有面对编译错误的份了；但你如果把所有头文件都包含进来，哼哼，编译的时候你就去数星星吧。

CONTINUE READING »

最近在重构 C++ 代码时突然想起，如果一个基类的虚成员函数被设为 private，有没有意义？又是否合理？

当然，有其一定的意义，那就是不希望子类在其他地方调用父类的这个函数，包括在子类的实现中；如果需要这个功能，应该使用其 public 的接口去使用该功能。而子类可以提供自己的实现，以提供多态。但是，如果子类觉得需要，还可以把这个 private 的虚成员函数重定义成 protected（虽然这会让人迷惑），从而使子类的子类们调用它。

有同学可能会问，如果是一个 private 的纯虚成员函数（语法上当然合理），那语义合理么？嗯，我觉得这的确是个问题——也许是为了告诉写子类的其他同学，这个虚函数，我不希望你们在除了基类已有的接口里调用之外还来用——仅仅是一个道德约束？！

嗯，C++ 就是灵活得过头了，什么都让程序员自己去把控，可是别忘了，“太多的选择比没有选择糟糕得多”。所以，我决定，为了自己也为了别人不犯迷糊，避免使用 private 的虚函数，private 的成员函数仅包含当前类自己使用的函数。

BTW，类的成员变量正好相反，能设为 private 的尽量不要 protected 更不要public，否则后期维护，嗯嗯，就太痛苦了。

在 C++ 中，有三种类型的循环语句：for、while 和 do...while，但是在一般应用中作循环时，我们可能用 for 和 while 要多一些，do...while 相对不受重视。
但是，最近在读我们项目的代码时，却发现了 do...while 的一些十分聪明的用法，不是用来做循环，而是用作其他来提高代码的健壮性。

CONTINUE READING »

C 中如果创建一个对象失败，就会返回空指针。但是对于 C++ 就不一样了，new 是不应返回空指针的，书上的推荐做法是在构造函数里抛异常。
当不想引入异常机制的时候，一般的做法是在构造器里啥都不做（最多做个变量初始化），加一个 Init() 函数来完成真正的初始化工作。
然而这样就使得每次创建一个对象，都要执行两步（new+init），总不是太方便，其实 C++ 的 new 操作符是带参的，可以通过“new(std::nothrow) CXxx”的方式让 new 失败时返回 null 指针，来标记失败（而不是抛出异常）。