我们经常谈论架构和设计，但很少关注实现和代码本身。架构和设计很重要，但我不认同，罗伯特·C·马丁大叔也不认同，他认为“源代码就是设计”。 在讨论具体实现细节之前，我们不妨先讨论一下什么是好代码？根据萝卜C.Martin的说法，衡量代码质量的唯一标准是WTF/min，即你在评审代码时每分钟说“抱草”的次数。 这个定义虽然有贬低的意味，但在粗暴中有奔放，在恶作剧中有哲理。 好的代码就像温柔的散文，行云流水，赏心悦目。阅读时，它就像一个春风，给人带来愉悦和启迪。 好的代码就像一部构思巧妙的小说。它可能不够直白，但足够引人入胜。当你读到最后，你会豁然开朗。我去。原来是这样的。那一刻，你会觉得过程中的曲折和探索都是值得的。 好的代码，通过一个个函数，可以窥视作者有趣的灵魂；透过一行行代码，你仿佛在和一个充满智慧的朋友聊天。她总是很有条理，逻辑性强，有条不紊，能言善辩。 而不良代码就像病毒一样，不仅让你的程序瘫痪，而且有很强的传播作用。蔓延之时，神仙难治。 糟糕的代码，就像一个泥球，阅读的时候，你好像被困在一个黑暗的迷宫里，你好像在和一个漫无边际的人说话。她的大脑回路经常短路，说话模棱两可，主次不分，时间久了，你还是搞不清她的中心思想。你经常会觉得自己的智商受到了极大的侮辱。你一脸苦相，心里全是马奔腾。 区分代码好坏的规则有很多，我也看过几个。对于文中提到的几个标准做法，我就不赘述舌根了。我想结合我的工作经历，谈谈我的个人体会。 说了半天，言归正传。要写出有品位的代码，应该遵循哪些约束和准则？一致性始终遵守一致性规则。代码风格方面，预计经过三天三夜的争论，无法确定好坏，但好的风格肯定是一致性强的。在这点上达成一致不是更容易吗？其实风格的好坏更多的是受习惯的影响。头发少的程序员应该都有自己风格转变的经历。很多年前他们信奉的好作风也可能是他们目前厌恶的坏作风，所以我主张在作风上搁置嘴炮。一个项目要有一个编码规则，好的规则要以理服人。一个好的规则应该是拒绝随意携带私人物品。规则定好了，就照着做。也许某种风格不适合你，但没关系。你知道，这并不意味着你输掉了风格之战，也不意味着它说服了你。你遵守规则和纪律本身。 命名变量(包括文件、类/结构、函数)，比如ohmygod，你可能不知道哪些字母在同一个组里，所以需要定义单词。 一个单词的定义是首字母大写，另一种常见的做法是用下划线拼接单词。 驼峰的缺点是丑。下划线拼接的缺点是增加了标识符长度(相对于首字母大写)。优点是与std c/c++和linux centos内核的做法一致。喜欢kernel的码农在家里很容易找到归属感。 ++C有名字空间来避免冲突。c经常使用前缀来防止命名污染全局空间，但我认为保持命名简洁和切题很重要，所以我支持短前缀而不是长前缀。 代码密度实现了相同的功能。你喜欢100行代码，还是20行代码？如果你的领导不以代码行数来评价业绩，我建议你简化代码编写，而如果你的领导以代码行数来评价业绩，我建议你转行，开滴滴，送餐或者摆摊。因为在这样的领导下度过青春，基本上不会有什么发展前景。 简单的事情很容易复杂化。你只需要找到一个能力平平的人，就可以实现化繁为简的愿望，而化繁为简，可以称之为化腐朽为神奇。 也许你想说我缺乏简化的能力。这并不奇怪。坦率地说，这不是一件容易的事。做不到不要紧，更重要的是你有正确的想法。它会帮助你知道自己前进的方向，而不是在错误的道路上越走越远。 有些项目充斥着各种无效代码。其实你只要稍微想一想就能识别出来。 例如，大量带注释的代码就像发臭的尸体一样遍布其中。 比如很多功能重复的代码像垃圾一样堆在那里。 例如，不需要返回值的函数总是返回true。 或者，函数一进来就检查参数，不管不顾，完全忘记自己写的是私有实现函数。你在调用之前已经检查过了，私有函数是受控的安全上下文，不仅不优雅而且绿色(低效耗电)，不安全(到崩溃的时候，雷就埋在更隐蔽的地方)。换句话说，看看标准库函数strcpy/strcat，vector。增加代码密度，或者说是密度，有利于理清思路，突出重点，提高可维护性。而充斥着各种无效语句的代码，只会把关键语句淹没在海洋中，让审核代码的人无法得到关键点，看不清主次。 听一个漫无边际的人作报告，满口胡言，像看一部情节拖沓的连续剧，昏昏欲睡，像喝一瓶二锅头加十斤白开水，嘴里能淡出一只鸟。 重构是程序员的口头禅。重构就是在保持程序功能不变的情况下，对架构和实现进行调整。我觉得提高代码密度应该是重构的一个追求。 Linux内核、lua、nginx、天网等优秀开源库代码集中度较高，建议读者朋友们尝一尝。 我们在封装中最常做的一件事就是把重复写的代码封装到一个函数中，用多次调用替换重复写的代码。这很容易理解，但即使不在多个地方调用，也有必要将一段相关的代码封装到一个实现函数中。因为代码平铺，细节暴露，很容易掩盖重要的东西，也就是框架和脉络会变得不清晰。 一个众所周知的函数调用比堆在那里的一段代码让我感觉更好。如果我关心它是如何完成的，我可以跳到定义并看到实现。 封装的核心标准之一是单一责任，符合单一责任的功能更容易被重用。 避免特例linus已经参考了他心目中的好代码，并且说是针对链表的操作。相对于特例解决方案，他更喜欢统一解决方案。我觉得这个例子很有代表性，它实际上代表了一种思想，那就是自始至终，我们都要优先考虑头脑中的规范化解。当然，这其实是更高层次的要求。菜鸟啄可以先跳过这个级别的要求。 小心使用缩写。比起缩写带来的歧义，我宁愿敲几下键盘。如果要缩写，请遵循约定，比如AI，App，cfg，但是你把threshold缩写为threshold，Item缩写为Iem。真不知道这是拼错了还是歪曲了。解耦来构建一个松散耦合的系统一直是软件工程的目标，模块化的一个方向就是解耦。但是，我们总声称，心与心的解耦，多少在实现层面有所表现。比如我经常做的一件事，就是把类似的配置文件，或者是浙宏定义的东西，放到一个头文件里，看起来非常统一和正规。至少我之前是这么认为的，但是突然有一天，我发现我这么做并不聪明。为什么？因为要把所有和模块配置相关的东西都塞到配置公共文件里，真的合适吗？是不是把公共接口拉出来，把配置相关的数据下沉到各个模块里比较好？另外，所有的宏都是一起定义的，这就意味着，如果你随意修改某个东西，你就需要修改头文件，这个文件就会成为程序世界的中心。修改公共宏文件几乎会导致整个系统的所有源文件被重新构建，这简直就是AOE湮灭。 所以更好的办法是分而治之，集权。 我们知道c/c++的编译单元是源文件(。c/。cpp)，而编译的第一步就是预解，所有包含的文件都会被替换，所以要避免引入任何不必要的头文件，把这个编译单元用到的头文件都包含进去，这叫头文件自给自足。 这很重要，但是很多人不这么认为。有些人甚至认为自己聪明到做了一个allincluded.h，包含了少量常用的头文件，然后就认为自己可以完美的一劳永逸的解决问题。包含不必要的头文件会增加编译时间和依赖性。既要避免错误的包含，又要精心设计和划分文件，使每个文件的功能足够衔接和单一。 为了符合标准，我遇到了每个模块独立定义自己的各种内置数据类型，但我建议不要这样做。 如果你只需要处理不同架构下long等整数类型的长度差异，我想告诉你，C库头文件stdint.h已经从标准层面处理了这个问题，包括int8_t/16_t/32_t/64_t，uint8_t等等。 宏是C的有效武器，在某些情况下是有效的。至于宏，我是一个骑墙派。我反对禁止宏和滥用宏。inline可以部分替代宏，但不能完全替代宏。 如果项目里全是全大写的宏，至少有1/3的代码是各种怪异的宏。当你审查代码的时候，你不停地跳来跳去，看一看，哦，就是它，然后削减回来。频繁的上下文切换效率很低，而且会打断你的思考。其实很多时候完全没有必要。 命名有一些指导原则。例如，类/结构应该使用名词，函数应该使用动词或doSomething这样的动词-对象结构。这些规则很熟悉。 我主张命名要简洁，不要啰嗦，确切表达它想做什么。如果遇到命名困难，您可能需要考虑您的类定义或用户界面分区是否合适。 它是命名接口的一部分，非常重要。好的命名是不言自明的。 我反对匈牙利命名法。原因是各种类型无法得到一致的解释，将类型编码成变量是不合适的。变量名本身可以表达它的类型，不能套用模板的情况。发起者ms放弃了它。 如果你没有概念，那么我建议你参考STD C/C++ API。毕竟这些界面几十年来变化不大，经受住了历史的考验。比如malloc/free/atoi，stl容器的成员函数也很有意思:size()、capacity()、resize()、reserve()、push()、pop()、。 所以，如果你写的是某某管理器，比如ItemManager，我建议你直接命名为add()和remove()，而不是AddItem()和RemoveItem()。因为你是物料的管理者，所以工序必须是物料，也可以从参数中显示出来。少即是多，多即是少。 扩展性的开闭规则就是处理扩展性的规则。没有远见的人一定有近忧。它说我们不能局限于当下，但请不要过度设计，也不要盲目相信扩展性。戏太多也是病。 知乎上有个神帖，讲的是如何把helloworld做成一个大项目。当你想挑剔别人的项目时，你可以用扩展性来说事，但我建议你远离那些对扩展性守口如瓶的人。据我观察，这些人大多虚伪水。 有许多高效且健壮的方法来避免低效的操作，例如哈希、减少副本、提高局部性、缓冲区/缓存、时空替换、内联、分支预测、预判断、计算延迟和无锁编程。 提高健壮性的关键是保持简单，任何引入复杂性的动作都需要足够警惕。 无信任/零信任设计，面向失败的编程，假设依赖上下文，上下游都不可靠，去中心化去除关键路径，熔断，降级，避免休克组效应，方法很多，不一一列举。 最后喷了这么多，也给大家一个喷我的机会。我贴了自己的代码，ZhuanJia/mynet。这是我13年刚进厂的周末摆弄的一个玩具。它可能有一些问题。如果你觉得不错，请给我点个赞。如果你觉得水，我可以扔锅给时间。毕竟是七年前写的。 水桥CEO说，如果一年前你还不觉得自己是沙雕，说明这一年你毫无进步。 另外，那是七年前的事了。 搬砖不容易。如果你累了，把你的笔放在一边，休息一下。改天再讨论吧！来源|华为云社区作者|人民副总码点击关注，第一时间了解华为云的新鲜科技~