风格

谈谈如何选择合适的代码风格。

代码的可维护性是最重要的

一代又一代的软件开发工程师们，在踩过无数坑后，发现软件开发和其他任何产品的都不一样。一个软件的开发始终不会停止，除非被放弃。这意味着，软件的代码会被不断的修改，直到这个软件不再被用户使用，走到了生命的尽头。

“永恒”虽然不可能，但还是有无数人在追求，软件工程师也是其中之一。

代码需要不断的被修改，而如何提高修改效率始终是软件工程师最头疼的问题之一。而优秀的编码风格就是能够提高代码可维护性的一种方法。

下面列出了一些比较糟糕的代码风格，某些甚至可以说是极端，在修改代码时如果遇到这些代码，估计谁都会忍不住曝粗口。

• 变量名太短，完全 get 不到意义。
• 明明是 C++，还是用了太多宏，好像还是 C 语言。
• 函数实现非常长，是千行千行的那种。如果你定位到了这个函数内有个关键 bug……
• 函数参数个数太多，十几个，二十几个。现在有个选择摆在你面前，加参数还是……
• 缩进混乱不统一，导致看到的代码层级不清晰。
• 缩进层级太多，天梯一样的代码。

很多人都认为代码风格和个人喜好差不多，每个人都不一样, 没有理由要求大家都一样。但其实“喜好”只是在某些具体细节方面，比如用 tab 还是空格。

我认为设计代码风格最重要的原则就是提高代码的可维护性，而“喜好”其实只是习惯不习惯而已。

漂亮是最次要的

审美是主观因素，不要追求代码的“漂亮”。这里很多人有个误区：漂亮意味着可读性强。代码是给未来的自己和别人读、改的，不要强加主观“偏见”。

比如，有些人喜欢对代码进行格式对齐，这种常见于结构体，类，枚举里面数据的定义：将所有的类型，名字，或初始值进行对齐。最终像一个表格一样。格式化后，看着如此工整的代码，心里洋洋自得，实不知是在给未来挖坑。

考虑下面的一个示例：

// 注意结构体里的成员变量名字都进行了对齐：使用了一个制表符
struct A
{
        int     i1;
        bool    b1;
        float   f1;
}

后来，需要增加一个数据，但是发现类型名称有点长：

struct A
{
        int     i1;
        bool    b1;
        float   f1;
        std::shared_ptr<A> next; // 很别扭对不对
}

既然要对齐，自然“一条道走到黑”：

struct A
{
        int                             i1;
        bool                            b1;
        float                           f1;
        std::shared_ptr<A>              next;
}

这次，留了个心眼：留够间距。

你可能会觉得没什么问题，但真的吗？

• 如果之前 A 里面已经有 20 个成员了，你得打多少空格！不过你觉得没什么，因为编辑器有插件，可以自动对齐代码。不管有多方便，敲多敲少键盘都不是问题的关键：给代码的维护引入了额外负担。
• 如果是别人改这段代码，他会做对齐吗？你有信心他会这么做吗？

其实对齐是没有必要的，名字和类型之间间隔一个空格才最统一，没有任何负担，而且代码也更紧凑：

struct A
{
        int i1;
        bool b1;
        float f1;
        std::shared_ptr<A> next;
}