1. 先搞清楚“该被禁”的C代码到底是什么看到“该被禁却强得离谱”这种标题很多人第一反应是某种危险的、能破坏系统的黑客代码。但结合“IOCCC”、“混淆代码”、“逆向工程师”这些关键词来看这里讨论的其实是国际C语言混乱代码大赛的参赛作品。这类代码的“强”不在于它能攻击系统而在于它以一种极其晦涩、违反直觉的方式实现了令人惊叹的功能甚至能“欺骗”编译器。IOCCC的代码从工程角度看确实“该被禁”。它们通常大量使用未定义行为、复杂的宏展开、晦涩的运算符优先级、甚至利用编译器的特性或Bug把代码写得像天书一样。任何正规的团队协作项目里如果有人提交这样的代码肯定会被立刻打回并要求重写。它的“离谱”之处在于在如此混乱的表象下代码逻辑竟然能正确运行并且往往实现了一个精巧的算法或图形效果让阅读者尤其是试图逆向理解的工程师感到既崩溃又佩服。所以这篇文章不是教你写危险代码而是带你看看C语言的边界能被玩出什么花样以及从这些“混乱艺术”中我们能反向学到哪些关于编译器、语言标准和代码可读性的严肃教训。如果你对C语言底层、编译器原理或者单纯对“代码谜题”感兴趣那这类内容值得一看。2. 从IOCCC经典案例看“混乱”的几种套路IOCCC的获奖作品有很多经典套路理解这些套路是读懂它们的第一步。这些套路本质上是在“合法”与“清晰”的边界上疯狂试探。2.1 滥用预处理宏和令牌粘贴这是制造混乱最直接的手段。通过多层宏定义和##令牌粘贴操作符可以让一段看起来完全不像C代码的文本在经过预处理后变成合法的C代码。#define DIT ( #define DAH ) #define __DAH #define DITDAH * #define DAHDIT for #define DIT_DAH malloc #define DAH_DIT gets #define _DAHDIT char _DAHDIT _DAH_[]ETIANMSURWDKGOHVFaLaPJBXCYZQb54a3d2f16g7c8a90l?eb.s;i,d: ;main DIT DAH{_DAHDIT DITDAH _DIT,DITDAH DAH_,DITDAH DIT_, DITDAH _DIT_,DITDAH DIT_DAH DIT DAH,DITDAH DAH_DIT DIT DAH;DAHDIT DIT _DITDIT_DAH DIT 81 DAH,DIT__DIT __DAH;_DITDAH_DIT DIT _DIT DAH;__DIT DIT\nDAH DAH DAHDIT DIT DAH__DIT;DITDAH DAH_;__DIT DIT DITDAH _DIT_?_DAH DIT DITDAH DIT_ DAH:?DAH,__DIT DIT DAH,DAH_ __DAH DAH DAHDIT DIT DITDAH DIT_2,_DIT__DAH_; DITDAH _DIT_DIT DITDAH _DIT_!DIT DITDAH DAH_a? DITDAH DAH_223:DITDAH DAH_ DAH DAH; DIT DITDAH DIT_ DAH __DAH,_DIT_ __DAH DAH DITDAH DIT_ DIT DITDAH _DIT_a? DITDAH _DIT_-a:0 DAH;}_DAH DIT DIT_ DAH{ __DIT DIT DIT_3?_DAH DIT DIT_1 DAH:\0DAH;return DIT_1?-:.;}__DIT DIT DIT_ DAH _DAHDIT DIT_;{DIT void DAH write DIT 1,DIT_,1 DAH;}上面这段代码一个经典的摩斯电码编码器看起来充满了DIT、DAH这样的“单词”完全不像C语言。但经过预处理器的替换例如DIT变成(DAH变成)它就会变回一个结构复杂但语法正确的程序。这种写法极大地挑战了阅读者的模式识别能力。2.2 巧妙或诡异地利用运算符优先级和结合性C语言的运算符优先级表格是许多初学者的噩梦而IOCCC作者则是这张表格的“艺术家”。他们写出看似不可能成立的表达式却因为优先级而能正确计算。int i5; printf(“%d %d”, i, i);这个简单的例子已经能让人争论不休它涉及序列点和未定义行为。IOCCC的作品会把这种特性用到极致比如在一个表达式里混合、--、数组索引[]、函数调用()和多重指针解引用*让人类几乎无法推断出执行顺序但编译器按照标准却有一个确定的或未定义的解释。2.3 将代码“画”成ASCII艺术这是IOCCC最著名的流派之一。代码的布局本身构成一幅画比如一个圆形、一个迷宫或者一张人脸而这幅“画”同时又是一段可以编译运行的C程序。main (_){puts( “Hello, World!” );return 0;}更复杂的作品会利用字符的排列让代码在视觉上隐藏它的逻辑结构。你看到的是一幅图你需要“逆向工程”这幅图找出哪里是变量定义哪里是循环体。这对逆向工程师的耐心和空间想象力是极大的考验。2.4 深入未定义行为的灰色地带这是最“危险”也最体现功力的地方。C标准中定义了大量“未定义行为”意思是编译器可以采取任何行动包括产生看似正确的结果、崩溃、或者更糟——产生安全漏洞。IOCCC的一些作品会故意触发未定义行为并依赖于某个特定编译器如gcc或clang在某个特定版本下的特定实现细节来让程序工作。例如通过数组越界访问来修改函数的返回地址或者利用有符号整数溢出来实现循环。在正式项目中这绝对是致命的缺陷必须被禁止。但在IOCCC的语境下它变成了一种对编译器内部机制的探索和挑战。3. 为什么说逆向分析这类代码是绝佳的学习虽然我们绝不鼓励在项目里写这种代码但主动去阅读、分析和逆向这些“混乱代码”对于一个想深入理解C语言和编译系统的人来说是价值连城的练习。3.1 强迫你理解编译器的“视角”我们平时写代码是从“人类逻辑”到“C语法”的映射。而阅读混淆代码要求你从“混乱的C语法”反推“编译器看到的逻辑”最后再试图理解“人类意图”。这个过程能极大地加深你对以下概念的理解词法分析编译器是如何把一连串字符切割成一个个“令牌”的注释和宏定义是在哪个阶段被处理的语法分析那些古怪的表达式是如何被解析成抽象语法树的运算符优先级和结合性是如何起作用的语义分析与代码生成未定义行为在编译时和运行时究竟发生了什么不同的优化等级-O0,-O2,-O3会对代码产生什么戏剧性的影响我建议的练习方法是找到一段简短的IOCCC代码不要直接看解答。预处理先用gcc -E命令只进行预处理看看那些诡异的宏到底被展开成了什么样子。这是破解大部分混淆代码的第一把钥匙。格式化把预处理后的代码用clang-format或indent等工具进行格式化让它恢复常见的缩进和换行结构。重命名把那些单字母变量i、j、_或者令人困惑的宏名根据上下文重命名为有意义的名称。单步调试在调试器中运行观察每一步执行后变量和内存的变化验证你的理解。3.2 深刻认识到代码可读性的重要性经历过被混乱代码折磨的痛苦你才会对清晰代码产生真正的敬畏。你会意识到有意义的命名bufferSize远比bs或n要好isUserAuthenticated远比flag清晰。简单的函数一个函数只做一件事并且保持短小。IOCCC的作品通常只有一个main函数里面塞了所有逻辑这是灾难的典范。避免“聪明”的技巧为了节省一行代码而使用晦涩的三目运算符嵌套或复杂的位运算会给维护者包括未来的你带来巨大的认知负担。注释是为什么而不是是什么好的注释解释意图和背后的原因而不是重复代码的行为。对于混乱代码你被迫去写大量注释来记录自己的推理过程这本身就是一种教育。3.3 锻炼耐心和系统性调试能力逆向混乱代码没有捷径它要求你像侦探一样系统地收集线索编译器警告、预处理结果、反汇编代码、运行时输出并建立假设再验证假设。这个过程锻炼的是一种面对复杂、无文档系统时的通用排查能力。这种能力在你未来调试内存泄漏、性能瓶颈或第三方库的怪异行为时同样至关重要。4. 如何安全地“把玩”这些代码环境与步骤如果你想亲身体验一下而不是停留在理论可以按照以下步骤搭建一个安全的沙盒环境。绝对不要在重要的开发环境或生产服务器上直接运行来路不明的代码。4.1 创建隔离的测试环境这是最重要的一步。你需要一个隔离的环境防止代码中的潜在危险操作比如恶意文件删除、内存破坏影响到你的主力系统。虚拟机使用VirtualBox或VMware创建一个干净的Linux虚拟机如Ubuntu Server。这是最安全的方式。容器如果你熟悉Docker可以创建一个临时容器。例如docker run -it --rm -v $(pwd):/workspace ubuntu:latest bash然后在容器内安装必要的编译工具。容器销毁后所有更改都会消失。专用开发机/云服务器一台不存放任何重要数据的物理机或廉价的按量付费云服务器。4.2 准备工具链在隔离环境中安装基础的编译和调试工具。# 在Ubuntu/Debian中 apt update apt install -y gcc clang make indent gdb # 可选代码格式化工具 apt install -y clang-format4.3 获取和分析代码获取代码从IOCCC的官方网站获取历年获奖代码。通常是一个.tar.gz压缩包。解压并定位解压后每个作品一个目录。先找那些看起来比较短小、著名的作品比如“hello world”的变体或者简单的图形演示。首次编译进入目录通常会有Makefile。直接运行make。观察是否有编译警告或错误。特别注意如果Makefile中有sudo、rm -rf /或任何可疑的网络下载命令立即停止这是基本的安全审查。运行编译成功后运行生成的可执行文件。看看它做了什么。是打印了奇怪的图案还是模拟了什么游戏4.4 开始逆向分析假设你选择了一个名为prog.c的源文件。预处理gcc -E prog.c -o prog.i用文本编辑器打开prog.i你会看到所有宏被展开、头文件被包含后的“真实”代码。虽然可能还是很长但已经去掉了第一层魔法。格式化clang-format -i prog.i # 或者使用 indent indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl prog.i现在代码应该有了清晰的缩进结构。简化与重命名这是最耗时的一步。手动阅读prog.i。将main函数里的内容分块尝试理解每一块在做什么。将全局变量int a, b, c;根据其用途重命名为int counter, flag, buffer_index;在你的分析副本中。将复杂的表达式拆分成多行用临时变量存储中间结果。调试与验证gcc -g -o prog_debug prog.c # 带上调试信息编译 gdb ./prog_debug在GDB中设置断点单步执行打印变量值。你的理解和程序的实际行为是否一致5. 从“混乱”回归“工程”我们该带走什么玩过这些“黑暗艺术”之后最终我们要回到阳光下的工程实践。以下几点是值得带入日常工作的核心收获5.1 对编译警告保持最高级别的敬畏IOCCC的代码通常会在编译时产生大量警告。在正式项目中必须开启并严肃对待所有编译警告。使用-Wall -Wextra -WerrorGCC/Clang等选项将警告视为错误。很多未定义行为和潜在Bug编译器已经向你发出了警告忽略它们就是在项目里埋雷。5.2 建立清晰的代码规范并自动化检查个人或团队的代码规范命名、格式、函数长度、注释要求不能只停留在文档里。要使用工具自动化格式检查使用clang-format并集成到编辑器的保存动作或Git的pre-commit钩子中。静态分析使用clang-tidy、cppcheck等工具进行更深入的代码质量检查。动态分析在测试中使用AddressSanitizer、UndefinedBehaviorSanitizer来捕获运行时内存错误和未定义行为。混乱代码是这些工具最好的“反面教材”它能让你真切感受到没有这些自动化检查的代码库会多么容易失控。5.3 理解“巧妙”与“晦涩”的界限编程中确实存在一些优雅、高效的技巧比如位运算实现特定算法、循环展开优化。但关键在于使用它们的动机和上下文。为性能而优化在性能关键路径上经过充分测试和注释的位运算是可以接受的。为炫技而炫技在普通的业务逻辑中使用晦涩的写法只会增加维护成本。 一个简单的判断标准是如果一段代码需要你写超过它本身长度的注释才能让同事理解那么它很可能就过于晦涩了。可读性永远是第一位的。5.4 将复杂逻辑封装并赋予清晰的接口IOCCC的作品把一切塞进main函数。工程实践则完全相反。当你有一个复杂算法或逻辑时给它起一个清晰的名字函数名。定义明确的输入和输出参数。在函数内部你可以为了效率进行必要的优化甚至是一些“巧妙”的实现但只要接口是清晰的调用者就不需要关心内部细节。在函数头部用注释说明算法原理、关键步骤和任何非常规做法的原因。这样你既保留了实现上的灵活性甚至是一点“巧妙”又保证了代码整体的可维护性。回过头看“该被禁却强得离谱”的C代码就像一把无鞘的利刃。在IOCCC这个特殊的“艺术展”上我们可以欣赏它锻造工艺的精妙绝伦惊叹于匠人对材料语言特性和工具编译器的极致理解。但我们必须清醒地知道这把刀绝不能带入日常的生产车间。真正的“强”是在深刻理解这些危险技巧的基础上写出既健壮高效又清晰易懂的代码。那才是值得在工程项目中追求和传承的“离谱”的强大。
1. 先搞清楚“该被禁”的C代码到底是什么看到“该被禁却强得离谱”这种标题很多人第一反应是某种危险的、能破坏系统的黑客代码。但结合“IOCCC”、“混淆代码”、“逆向工程师”这些关键词来看这里讨论的其实是国际C语言混乱代码大赛的参赛作品。这类代码的“强”不在于它能攻击系统而在于它以一种极其晦涩、违反直觉的方式实现了令人惊叹的功能甚至能“欺骗”编译器。IOCCC的代码从工程角度看确实“该被禁”。它们通常大量使用未定义行为、复杂的宏展开、晦涩的运算符优先级、甚至利用编译器的特性或Bug把代码写得像天书一样。任何正规的团队协作项目里如果有人提交这样的代码肯定会被立刻打回并要求重写。它的“离谱”之处在于在如此混乱的表象下代码逻辑竟然能正确运行并且往往实现了一个精巧的算法或图形效果让阅读者尤其是试图逆向理解的工程师感到既崩溃又佩服。所以这篇文章不是教你写危险代码而是带你看看C语言的边界能被玩出什么花样以及从这些“混乱艺术”中我们能反向学到哪些关于编译器、语言标准和代码可读性的严肃教训。如果你对C语言底层、编译器原理或者单纯对“代码谜题”感兴趣那这类内容值得一看。2. 从IOCCC经典案例看“混乱”的几种套路IOCCC的获奖作品有很多经典套路理解这些套路是读懂它们的第一步。这些套路本质上是在“合法”与“清晰”的边界上疯狂试探。2.1 滥用预处理宏和令牌粘贴这是制造混乱最直接的手段。通过多层宏定义和##令牌粘贴操作符可以让一段看起来完全不像C代码的文本在经过预处理后变成合法的C代码。#define DIT ( #define DAH ) #define __DAH #define DITDAH * #define DAHDIT for #define DIT_DAH malloc #define DAH_DIT gets #define _DAHDIT char _DAHDIT _DAH_[]ETIANMSURWDKGOHVFaLaPJBXCYZQb54a3d2f16g7c8a90l?eb.s;i,d: ;main DIT DAH{_DAHDIT DITDAH _DIT,DITDAH DAH_,DITDAH DIT_, DITDAH _DIT_,DITDAH DIT_DAH DIT DAH,DITDAH DAH_DIT DIT DAH;DAHDIT DIT _DITDIT_DAH DIT 81 DAH,DIT__DIT __DAH;_DITDAH_DIT DIT _DIT DAH;__DIT DIT\nDAH DAH DAHDIT DIT DAH__DIT;DITDAH DAH_;__DIT DIT DITDAH _DIT_?_DAH DIT DITDAH DIT_ DAH:?DAH,__DIT DIT DAH,DAH_ __DAH DAH DAHDIT DIT DITDAH DIT_2,_DIT__DAH_; DITDAH _DIT_DIT DITDAH _DIT_!DIT DITDAH DAH_a? DITDAH DAH_223:DITDAH DAH_ DAH DAH; DIT DITDAH DIT_ DAH __DAH,_DIT_ __DAH DAH DITDAH DIT_ DIT DITDAH _DIT_a? DITDAH _DIT_-a:0 DAH;}_DAH DIT DIT_ DAH{ __DIT DIT DIT_3?_DAH DIT DIT_1 DAH:\0DAH;return DIT_1?-:.;}__DIT DIT DIT_ DAH _DAHDIT DIT_;{DIT void DAH write DIT 1,DIT_,1 DAH;}上面这段代码一个经典的摩斯电码编码器看起来充满了DIT、DAH这样的“单词”完全不像C语言。但经过预处理器的替换例如DIT变成(DAH变成)它就会变回一个结构复杂但语法正确的程序。这种写法极大地挑战了阅读者的模式识别能力。2.2 巧妙或诡异地利用运算符优先级和结合性C语言的运算符优先级表格是许多初学者的噩梦而IOCCC作者则是这张表格的“艺术家”。他们写出看似不可能成立的表达式却因为优先级而能正确计算。int i5; printf(“%d %d”, i, i);这个简单的例子已经能让人争论不休它涉及序列点和未定义行为。IOCCC的作品会把这种特性用到极致比如在一个表达式里混合、--、数组索引[]、函数调用()和多重指针解引用*让人类几乎无法推断出执行顺序但编译器按照标准却有一个确定的或未定义的解释。2.3 将代码“画”成ASCII艺术这是IOCCC最著名的流派之一。代码的布局本身构成一幅画比如一个圆形、一个迷宫或者一张人脸而这幅“画”同时又是一段可以编译运行的C程序。main (_){puts( “Hello, World!” );return 0;}更复杂的作品会利用字符的排列让代码在视觉上隐藏它的逻辑结构。你看到的是一幅图你需要“逆向工程”这幅图找出哪里是变量定义哪里是循环体。这对逆向工程师的耐心和空间想象力是极大的考验。2.4 深入未定义行为的灰色地带这是最“危险”也最体现功力的地方。C标准中定义了大量“未定义行为”意思是编译器可以采取任何行动包括产生看似正确的结果、崩溃、或者更糟——产生安全漏洞。IOCCC的一些作品会故意触发未定义行为并依赖于某个特定编译器如gcc或clang在某个特定版本下的特定实现细节来让程序工作。例如通过数组越界访问来修改函数的返回地址或者利用有符号整数溢出来实现循环。在正式项目中这绝对是致命的缺陷必须被禁止。但在IOCCC的语境下它变成了一种对编译器内部机制的探索和挑战。3. 为什么说逆向分析这类代码是绝佳的学习虽然我们绝不鼓励在项目里写这种代码但主动去阅读、分析和逆向这些“混乱代码”对于一个想深入理解C语言和编译系统的人来说是价值连城的练习。3.1 强迫你理解编译器的“视角”我们平时写代码是从“人类逻辑”到“C语法”的映射。而阅读混淆代码要求你从“混乱的C语法”反推“编译器看到的逻辑”最后再试图理解“人类意图”。这个过程能极大地加深你对以下概念的理解词法分析编译器是如何把一连串字符切割成一个个“令牌”的注释和宏定义是在哪个阶段被处理的语法分析那些古怪的表达式是如何被解析成抽象语法树的运算符优先级和结合性是如何起作用的语义分析与代码生成未定义行为在编译时和运行时究竟发生了什么不同的优化等级-O0,-O2,-O3会对代码产生什么戏剧性的影响我建议的练习方法是找到一段简短的IOCCC代码不要直接看解答。预处理先用gcc -E命令只进行预处理看看那些诡异的宏到底被展开成了什么样子。这是破解大部分混淆代码的第一把钥匙。格式化把预处理后的代码用clang-format或indent等工具进行格式化让它恢复常见的缩进和换行结构。重命名把那些单字母变量i、j、_或者令人困惑的宏名根据上下文重命名为有意义的名称。单步调试在调试器中运行观察每一步执行后变量和内存的变化验证你的理解。3.2 深刻认识到代码可读性的重要性经历过被混乱代码折磨的痛苦你才会对清晰代码产生真正的敬畏。你会意识到有意义的命名bufferSize远比bs或n要好isUserAuthenticated远比flag清晰。简单的函数一个函数只做一件事并且保持短小。IOCCC的作品通常只有一个main函数里面塞了所有逻辑这是灾难的典范。避免“聪明”的技巧为了节省一行代码而使用晦涩的三目运算符嵌套或复杂的位运算会给维护者包括未来的你带来巨大的认知负担。注释是为什么而不是是什么好的注释解释意图和背后的原因而不是重复代码的行为。对于混乱代码你被迫去写大量注释来记录自己的推理过程这本身就是一种教育。3.3 锻炼耐心和系统性调试能力逆向混乱代码没有捷径它要求你像侦探一样系统地收集线索编译器警告、预处理结果、反汇编代码、运行时输出并建立假设再验证假设。这个过程锻炼的是一种面对复杂、无文档系统时的通用排查能力。这种能力在你未来调试内存泄漏、性能瓶颈或第三方库的怪异行为时同样至关重要。4. 如何安全地“把玩”这些代码环境与步骤如果你想亲身体验一下而不是停留在理论可以按照以下步骤搭建一个安全的沙盒环境。绝对不要在重要的开发环境或生产服务器上直接运行来路不明的代码。4.1 创建隔离的测试环境这是最重要的一步。你需要一个隔离的环境防止代码中的潜在危险操作比如恶意文件删除、内存破坏影响到你的主力系统。虚拟机使用VirtualBox或VMware创建一个干净的Linux虚拟机如Ubuntu Server。这是最安全的方式。容器如果你熟悉Docker可以创建一个临时容器。例如docker run -it --rm -v $(pwd):/workspace ubuntu:latest bash然后在容器内安装必要的编译工具。容器销毁后所有更改都会消失。专用开发机/云服务器一台不存放任何重要数据的物理机或廉价的按量付费云服务器。4.2 准备工具链在隔离环境中安装基础的编译和调试工具。# 在Ubuntu/Debian中 apt update apt install -y gcc clang make indent gdb # 可选代码格式化工具 apt install -y clang-format4.3 获取和分析代码获取代码从IOCCC的官方网站获取历年获奖代码。通常是一个.tar.gz压缩包。解压并定位解压后每个作品一个目录。先找那些看起来比较短小、著名的作品比如“hello world”的变体或者简单的图形演示。首次编译进入目录通常会有Makefile。直接运行make。观察是否有编译警告或错误。特别注意如果Makefile中有sudo、rm -rf /或任何可疑的网络下载命令立即停止这是基本的安全审查。运行编译成功后运行生成的可执行文件。看看它做了什么。是打印了奇怪的图案还是模拟了什么游戏4.4 开始逆向分析假设你选择了一个名为prog.c的源文件。预处理gcc -E prog.c -o prog.i用文本编辑器打开prog.i你会看到所有宏被展开、头文件被包含后的“真实”代码。虽然可能还是很长但已经去掉了第一层魔法。格式化clang-format -i prog.i # 或者使用 indent indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl prog.i现在代码应该有了清晰的缩进结构。简化与重命名这是最耗时的一步。手动阅读prog.i。将main函数里的内容分块尝试理解每一块在做什么。将全局变量int a, b, c;根据其用途重命名为int counter, flag, buffer_index;在你的分析副本中。将复杂的表达式拆分成多行用临时变量存储中间结果。调试与验证gcc -g -o prog_debug prog.c # 带上调试信息编译 gdb ./prog_debug在GDB中设置断点单步执行打印变量值。你的理解和程序的实际行为是否一致5. 从“混乱”回归“工程”我们该带走什么玩过这些“黑暗艺术”之后最终我们要回到阳光下的工程实践。以下几点是值得带入日常工作的核心收获5.1 对编译警告保持最高级别的敬畏IOCCC的代码通常会在编译时产生大量警告。在正式项目中必须开启并严肃对待所有编译警告。使用-Wall -Wextra -WerrorGCC/Clang等选项将警告视为错误。很多未定义行为和潜在Bug编译器已经向你发出了警告忽略它们就是在项目里埋雷。5.2 建立清晰的代码规范并自动化检查个人或团队的代码规范命名、格式、函数长度、注释要求不能只停留在文档里。要使用工具自动化格式检查使用clang-format并集成到编辑器的保存动作或Git的pre-commit钩子中。静态分析使用clang-tidy、cppcheck等工具进行更深入的代码质量检查。动态分析在测试中使用AddressSanitizer、UndefinedBehaviorSanitizer来捕获运行时内存错误和未定义行为。混乱代码是这些工具最好的“反面教材”它能让你真切感受到没有这些自动化检查的代码库会多么容易失控。5.3 理解“巧妙”与“晦涩”的界限编程中确实存在一些优雅、高效的技巧比如位运算实现特定算法、循环展开优化。但关键在于使用它们的动机和上下文。为性能而优化在性能关键路径上经过充分测试和注释的位运算是可以接受的。为炫技而炫技在普通的业务逻辑中使用晦涩的写法只会增加维护成本。 一个简单的判断标准是如果一段代码需要你写超过它本身长度的注释才能让同事理解那么它很可能就过于晦涩了。可读性永远是第一位的。5.4 将复杂逻辑封装并赋予清晰的接口IOCCC的作品把一切塞进main函数。工程实践则完全相反。当你有一个复杂算法或逻辑时给它起一个清晰的名字函数名。定义明确的输入和输出参数。在函数内部你可以为了效率进行必要的优化甚至是一些“巧妙”的实现但只要接口是清晰的调用者就不需要关心内部细节。在函数头部用注释说明算法原理、关键步骤和任何非常规做法的原因。这样你既保留了实现上的灵活性甚至是一点“巧妙”又保证了代码整体的可维护性。回过头看“该被禁却强得离谱”的C代码就像一把无鞘的利刃。在IOCCC这个特殊的“艺术展”上我们可以欣赏它锻造工艺的精妙绝伦惊叹于匠人对材料语言特性和工具编译器的极致理解。但我们必须清醒地知道这把刀绝不能带入日常的生产车间。真正的“强”是在深刻理解这些危险技巧的基础上写出既健壮高效又清晰易懂的代码。那才是值得在工程项目中追求和传承的“离谱”的强大。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
