比如认为下面的代码中，方式 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");
}
二、奇技淫巧的“度”在哪里？
[ol]
[/ol]
三、我认为的可读性
我认为，一份真正可读的代码，一定是代码中隐含的想法，而不是这段代码是用 if else 还是三目运算符。
我读过很多优秀开源项目的代码。其中某些项目甚至充满了大家对于“屎山”的评价标准：魔数乱飞、代码格式乱七八糟，还有各种奇技淫巧。但当你真的读懂了作者的奇妙想法，知道了这个项目的优秀的性能来自于优秀的设计，知道了写出这样的一个项目需要掌握多少高深的知识，你真的还会觉得这是“屎山”吗？
四、项目质量和个人成长息息相关
如果你想获得有效的工作经验，一定要远离业务代码！！对于代码的良好品味，是很难通过看书习得的，唯一的途径就是参与一些水平远在自己之上的人领导的项目。如果确实没办法找到这样的工作，可以考虑在业余时间参与感兴趣的开源项目。
