01 | 从条件运算符说起，反思什么是好代码

范学雷



该思维导图由 AI 生成，仅供参考

写出优秀的代码是我们每一个程序员的毕生追求，毕竟写代码本身就是个技术活，代码的好坏，其实也就是我们工艺的好坏。作为一个技术类的工种，我们没有理由不去思考如何写出优秀、让人惊叹的代码。
那什么样的代码才是优秀的代码呢？对于这个问题，我想每个人心中都会有自己的答案。今天我就来和你聊聊我的思考。
对于条件运算符（?:）的使用，我估摸着你看到过相关的争论，或者自己写代码的时候也不知道到底该不该使用条件运算符，或者什么情况下使用？这些微不足道的小话题随时都可以挑起激烈的争论。
C 语言之父丹尼斯·里奇就属于支持者。在《C 程序设计语言》这本书里，他使用了大量简短、直观的条件运算符。
然而还有一些人，对条件运算符完全丧失了好感，甚至把“永远不要使用条件运算符”作为一条 C 语言高效编程的重要技巧。
比如说吧，下面的这个例子，第一段代码使用条件语句，第二段代码使用条件运算符。 你觉得哪一段代码更“优秀”呢？
if (variable != null) {
   return variable.getSomething();
}
return null;
return variable != null ? variable.getSomething() : null;
同样使用条件运算符，你会喜欢下面代码吗？
return x >= 90 ? "A" : x >= 80 ? "B" : x >= 70 ? "C" : x >= 60 ? "D" : "E";
十多年前，作为一名 C 语言程序员，我非常喜欢使用条件运算符。因为条件运算符的这种压缩方式，使代码看起来简短、整洁、干净。 而且，如果能把代码以最少的行数、最简短的方式表达出来，心里也颇有成就感。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

这篇文章从“经济”的角度探讨了优秀代码的特点。作者认为优秀的代码应该在整个软件生命周期中投入少、收益大，具备经济、规范、安全三个特征。文章强调了好的代码应该容易理解、没有明显的安全问题、能够满足最关键的需求、有充分的注释、使用规范的命名、经过充分的测试等特点。同时，文章也指出现实环境的变化影响着对代码“好”与“坏”的判断标准。总的来说，优秀的代码应该在投入少、收益大的前提下，具备规范和安全的特点。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《代码精进之路》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(77)

最新
精选

郭解
置顶
多些实例
编辑回复: 您好，第一篇只是引子，后续内容会有很多正反面案例，请期待。😊
2019-01-04

18
Imperfect
有一句很经典的名言：当我写这行代码的时候，只有我和上帝知道这行代码的意思。一年之后....现在，就只有上帝知道了。
作者回复: 上帝很孤独……
2019-01-05
4
57
W.J.Huang
个人认为，条件运算符适合简单的结果取舍，带有复杂的表达式或嵌套运算符的应该用if语句。另外，代码规范和语句检查，可以使用SonarQube. SonarQube不仅带来代码评审的便利，还可以直接安装在IDE, 比如Eclipse, 会时刻提醒不规范或不安全的代码，以提高开发人员提交代码质量。
作者回复: 👍，小伙伴们快来试试这个工具。高手都在讨论区😊。
2019-01-05

26
月城冥
请教一个具体的问题：java lambda该用还是不该用？个人感觉这个东西的可读性还是有点差的。什么样的场景该用，什么样的场景不该用？
作者回复: lambda的可读性，主要是和我们通常的编码习惯不太一样。lambda在异步编程和函数编程方面，还是有可读性优势的。我不是lambda的铁杆粉丝，主要是因为我做的工作大部分是非常基础的接口。lambda方式会产生大量的内部类和实例，这个有损效率。这个效率损耗如果发生在应用层，影响不大，可以忽略不计。可是要发生在使用频繁的底层接口，就是个不小的问题了。
2019-03-08

18
秦凯
老师从软件生命周期来看代码好坏的角度让我对代码质量有了新的认识，好的代码应该是服务于整个软件生命周期的，或者说是服务于软件开发目标的，不能说代码中用了某个高深的技巧或技术就是好代码，应该跳出开发视角，从整个软件的目标思考，能服务于软件目标，适合软件目标的，对于整个软件生命周期都是经济的才是好的代码。
作者回复: 总结的特别棒、特别好👍。要有意识地从最基础的概念开始理解一些问题，这就是我想通过这个专栏让你收获的东西之一。
2019-01-06

9
Change
以前觉得看不懂的代码就是厉害的有种不明觉厉的意思，看完老师的文章才觉得化繁为简通俗易懂的代码才是我们追求的好代码，其编写的过程是由简单到复杂，再由复杂到简单的一个转变。自己对安全这块也比较重视，期待老师的后续内容。
作者回复: 我们第三篇聊安全。如果哪一天，你觉得复杂很简单，告诉我一下，我要恭喜你。
2019-01-04

7
陈大发
我觉得首先的是要职责单一，不要把过多的东西塞到一个类或者方法中，同一个功能的最好放到一起，或者有联系的地方。尽量把变化的抽离出来，不变的封装起来。
作者回复: 赞，能坚守职责单一，就成功了一半。我们后面的文章还有专门的讨论。
2019-01-07

5
Woj
好的代码是代码运行正常、bug很少、并且具有可读性和可维护性。一些企业自己有所有开发人员都必需遵守的编码规范，但是对于什么样的代码是最好的每个人的都有自己的标准、或者有太多的或太少的编码规则。这有多种原则和标准，例如，McCable 的复杂度度量。的确使用过多的编码标准和规则可能降低生产率和创造性。“同行评审”或“同事检查”代码分析工具等，都能用来检查问题或坚持标准。
作者回复: 标准多就像没标准。
2019-01-04

4
路过蜻蜓
我写代码时一般是先顺着写下来，然后再对需要重复使用的代码分离出去，写成一个方法，尽量将写在一个def里的代码简单点。
作者回复: 代码整理术！
2019-01-11

3
Sisyphus235
除去极少数天才（用01直接编码，独立完成经典项目），大多数情况编码都是一个工程，一个开发组可以看成是一个施工队。工程好坏取决于两大方面，施工团队的管理和工程技艺。前者是软技能，后者是硬实力，缺一不可。对于软件开发来说，也要同时兼顾团队的交流效率和实际的运行效率。之所以用“效率”而不是“质量”，是因为软件工程也是商业的一部分，盈利是核心，而不是要打造一个传世经典的高质量作品。
作者回复: 是的。工程师可以非常专注于一个点，但是必须了解流水线并且成为其中的一个高效的环节。这就需要软硬都有，都拿的出手。
2019-05-21

2

收起评论