我对于代码可读性的理解

[iamee]

总在这个论坛看到有人强调所谓的代码可读性，但后来我发现这些人在说的所谓可读性非常肤浅。

比如认为下面的代码中，方式 1 比方式 2 更可读。

// JavaScript

// 1
if (condition) {
    return true;
} else {
    return false;
}

// 2
return !!condition;

我的观点：

一、代码是否可读与程序员的实际水平强相关

有效工作经验 5 年的程序员和有效工作经验 1 年的程序员对于可读性的理解是非常不同的（请注意是有效工作经验）。

这里举个 C 语言的例子，一个 C 语言的初学者和对 C 语言比较熟悉的人，对于下面这段代码的可读性的评价一定是非常不同的：

#define MAGIC_HEADER "tox3"

if (*(uint32_t *)p != *(uint32_t *)MAGIC_HEADER) {
    report_error("Bad magic header");
}

二、奇技淫巧的“度”在哪里？

1. 凡事都有极端，过度使用一些不值得的技巧（比如对于可读性的损伤很大，但对性能并没有帮助）是没有意义的。
2. 取决于团队水平，最好不要在水平对于你来说过于低下而你又没有话语权的团队久留，会被同化。

三、我认为的可读性

我认为，一份真正可读的代码，一定是代码中隐含的想法，而不是这段代码是用 if else 还是三目运算符。

我读过很多优秀开源项目的代码。其中某些项目甚至充满了大家对于“屎山”的评价标准：魔数乱飞、代码格式乱七八糟，还有各种奇技淫巧。但当你真的读懂了作者的奇妙想法，知道了这个项目的优秀的性能来自于优秀的设计，知道了写出这样的一个项目需要掌握多少高深的知识，你真的还会觉得这是“屎山”吗？

四、项目质量和个人成长息息相关

如果你想获得有效的工作经验，一定要远离业务代码！！对于代码的良好品味，是很难通过看书习得的，唯一的途径就是参与一些水平远在自己之上的人领导的项目。如果确实没办法找到这样的工作，可以考虑在业余时间参与感兴趣的开源项目。

[Finnn]

1. 可读性本身也不是硬性要求， 业务代码需要维护，追求可读性，基础设施/开源封装追求性能与高效，比如用位运算，语法糖
2. 可读性的解读因人而异，每个人理解问题的心智负担并不一样， 太吃个人水平了
比如 我还更喜欢 [,男,女][key] 代替 三目运算呢

[darkengine]

可读性不好还能赖业务，头一次见。大家都不写业务代码，用爱发电吗。

[ruyu]

因为业务代码太 low 了，只是对需求的描述，没什么技术含量，所以对其价值的衡量就只有可读性。高级的代码即使可读性差（按照初级程序员的标准），也是很有价值的。强调代码的可读性本身没错，问题是可能有些人会把 “可读性” 当作代码唯一的价值衡量标准，这就很糟糕了。一份代码看不懂，他说，什么乱七八糟的，可读性真差！

[mogg]

你举的两个例子 感觉可读性都不好……

js
```js
return Boolean(condition);
```

c
```
uint32_t magic_header (const char* c) {
return *(uint32_t *)c;
}

magic_header(p) == magic_header(MAGIC_HEADER)
```

[mogg]

@mogg #24

[mogg]

所谓的可读性、代码规范 之类的约束，最大的意义在于保证团队内部的一致性，本身还是取决于团队水平 和 领导者个人喜好

[iamee]

@mogg !! 和 Boolean 没有可读性好坏之分，他们是等价的东西，任何写过 JavaScript 的人都知道 !! 是在做什么。

我并不觉得你对 C 语言的更改提升了任何可读性，不是把任何东西封装成一个函数就等于提升了可读性，而且 p 并不一定是 char * 类型。“reinterpret cast” 然后解引用对有 C 经验的人来说是一个非常常见且不需要思考的操作，你给这个操作起名叫 “magic_header” 只会让人摸不着头脑。

另外你的代码中指针类型星号的位置都不统一。