编写除了自己没人能看懂的代码，是一种怎样的体验？
下面由作为资深挖坑程序员的我，手把手教大家这是怎么做到的？如果各位可以在接下来的时间多加练习，所谓青出于蓝胜于蓝，相信各位不但可以写出别人无法维护的代码，还可能在有朝一日，甚至能技艺炉火纯青地写出自己都维护不了的代码。
编写无法维护的代码说难其实并不难，核心要点就是和编码规范反其道而行之，如果在此基础上再添加一些自己琢磨出的心得的话那就更加完美了。
掌握了这个要点还不够，还要注意一个原则：不要让我们的代码一眼看上去就无法维护，格式之类的还是要注意些的，我们要追求的不是这种肤浅的表面上的无法维护，我们要的是实质是无法维护的。
要是别人一眼就能看出你的代码无法维护，那你的代码就存在需要重写或者重构的风险了，那不成了前功尽弃亲者痛，仇者快的事情了嘛。
1、了解清常规编程的思维方式再下手！
《孙子兵法》有云“知己知彼，百战不殆”，假如我们要想从心理上彻底击败后续的代码维护人员，我们必须明白常规编程中的一些思维方式。
各位先想下，如果接手程序的是我们自己，而且代码量比较大，一般我们是没有时间去从头到尾一行一行地读一遍的，更不要说能理解代码了。
为了能尽快地上线交差，程序员常见的做法是根据需求，先快速找到代码中需要改动的那一部分逻辑，然后对这部分的代码进行修改、测试。这种修改方式一次只能看到代码的一小部分，管中窥豹。
所以我们要做的是确保让代码维护人员永远看不到我们写的代码的全貌，要尽量保证代码维护人员找不到他想要找到的那部分代码。这还不是最关键的，最关键的是要让修改者知道自己没有忽略任何的东西。
每一个我们精心设计的这些小陷阱都会迫使代码维护者像用放大镜似的，仔细地阅读我们的每一行代码。
有些同学可能觉得这很简单，认为只要按照上文中提到的反编程规范原则来进行即可。但是实际操作起来并没有这么简单，还需要配合我们的精心误用才可。下面我们就对常用的一些核心技能娓娓道来。
2、第一招：一本正经地乱用注释
这一部分我们先了解下注释的正常用途：注释是用来帮助开发者理解程序的，尤其是对于后来的开发者，通过注释可以更快的了解代码的实际作用。
正常情况下代码注释的原则一般是只在需要注释的地方进行注释。这是一句很正确的废话，解释起来就是很明显就能看懂的代码就不要去注释的了，毕竟看注释也是需要花费时间的。
另外一个原则就是在注释中注明代码的作用需要和代码的实际作用是一致。
在实际工作中，在对代码进行修改后一定要连同代码的注释也一起进行修改。关于注释的其他的一些作用我们在此不再多说，光是这些就已经足够我们用的了。
如何利用代码注释写出让人无法理解的代码呢？
一、多整没用的
这块我分了两种情况来描述，两种情况对应两种处理方式，实用性比较强。
- 明显型注释
让维护者浪费时间看显而易见的注释。
这部分的原则是维护者看完注释后觉得“代码比注释容易读多了”，目的就是误导读代码的人。维护者在看代码时，上眼一看代码很清晰，但又一看竟然还有注释。
此时读代码的人心里肯定是要嘀咕下：看来这代码没我想的这么简单。
然后我们的注释要写的长一些，最后是要阅读者看不懂，改的时候犹豫不决。
如果有余力的话可以在注释中教维护者怎么编程，这种一般杀伤力要比上面写的会高一些，程序员最反感的可能就是你要教他怎么编程了，尤其是教他这么简单的编程，杀伤力加倍。
下面看个例子：
- 废弃代码注释
字面意思已经很清楚了，正常情况下代码中不用的部分我们一般会注释掉或者直接删除掉，即使这段代码将来会使用到也不影响，可以从版本控制工具中再找回来。
针对性的做法就是给删掉的代码加个长长的注释，写明这段代码为什么会被注释起来，也向维护者传达了一个信息，即这段代码不是被”废弃”的，而是”临时”先不用。
这样做的杀伤点就在，如果只注释了代码没加注释说明，根据实际经验大家多数会直接略过被注释的代码，而给代码加了注释后看代码的人可能就要看看这个注释了，不然会漏掉什么关键信息，毕竟代码不是他写的。
样板代码：
二、这个地方将来会修改
这种注释就是我们经常提到的“TODO”型注释。正常情况下TODO注释并非一无是处，比如在初始化项目的时候TODO注释还是非常有用的，到项目release 时一般是建议去掉的，如果必须要留着一般需要写明在具体什么日期会处理掉。一般是不推荐TODO型注释长期存在于项目的代码中，正常的处理逻辑一般是遵循有Bug尽快Fix，无Bug则去掉注释。
通过上面的描述相信大家已经知道这块具体要怎么应对了。个人建议是对于有待修改的多写点TODO注释，且不注明更改的原因以及计划更改的时间，这样后面的维护人员在看的时候可能连这块到底是不是已经改过了都搞不清楚，所以杀伤效果也是有一些的。
样板代码:
三、错误注释信息
这部分的意思是造成代码和注释的不匹配，也就是注释的信息不正确。
我们要做的就是改完代码后不改注释就行了，此种方式比较省事，额外工作一点也不用多做，但是稍微有些代价，需要注意的是最好是在此类注释中加个特殊的标记，防止自己后续看的时候把自己也绕进去。
样板实例这块就不用加了吧，场景太多了，大家在自己的一亩三分地上耕作时临场发挥即可。
四、讲故事
简单说来就是写明这段代码为什么要这样写，当然肯定不是单纯的原因。除了原因一般建议在注释中写上当时的情况，比如某年某月和某人在某地讨论了这个问题，某人说这个问题应该怎样处理，你说这个问题不该这样处理应该那样处理，后来某某人又加入了讨论，某某人对俩的讨论做了某某的评价，最后决定要用现在的代码去实现这块的功能。
总之，原则就是把事情的细节描述清楚，越细越好。有些同学可能会建议将当天的天气情况也写上，还有讨论中那个气死人的S*名字也要带上，我个人认为天气可以酌情添加，但写上S*名字是不太鼓励的，毕竟同事一场，要相互爱护的，大家按照自己公司的实际情况来选择具体的处理方式吧。
样板代码：
五、不要写原因
按照注释的规范，注释时不但要解释程序的表述的意思，更重要的是写明为什么写，即代码这么写的原因是什么。
这样应对之策也已经显而易见了，对于复杂程序，比如一些特殊的边界条件判断，只写下程序的字面意思，具体边界值判断为什么要这样写，为什么是这个值可以忽略掉，让维护的人尽情去猜吧。
六、琐碎
在这需要注明的是大部分程序注释一般是用不到这种情况的，一般是推荐放在一些复杂算法的解释上，越是复杂的算法越是推荐，原则就是把这部分应该写到文档中的内容写到代码中。
一定要把算法的所有的详细设计都写上，注释内容分段落，段落之间要分级，每个段落建议加上编号，这样就基本可以保证代码的注释和文档的内容保持一致。后续的维护看到这样的注释的时候基本可以保证头大一圈，如果此类注释存在多处的话效果更佳。
鉴于样板示例中注释篇幅太长就不加示例了。
七、单位问题
单位这部分和具体的业务场景相关，比如时间相关的一般会有毫秒、秒、分钟、小时、天、月、年等，涉及尺寸的场景如像素、英寸等，涉及文件大小的场景如字节、KB、MB、GB等。
这一类的代码中我们的原则是不对单位进行注释，只管使用，如果可以在代码中各种单位混用，那自然是更加优秀。
比如在关于文件处理的场景中，KB、MB、GB多个单位混合使用，这样后来的维护人员要想搞懂这部分代码中单位的真正含义就要下一番功夫了。
按照我们的正常逻辑，后面的人要想改这部分的代码的逻辑首先要先弄懂各个数据的单位，搞清楚之前肯定是不敢随意修改的，一般这种情况只有一种解决办法那就是一遍遍的调试、测试程序来推算各个数据实际的单位，花费的时间自然是相当的多。
八、恐吓
这一招可以说是杀手锏级别的注释，可以在程序中加一部分可有可无的代码，而且是很明显可有可无的那种，然后给这段程序加个注释，注释中写明“千万不要注释掉或者删除这段代码，否则程序会出现异常！！！”，需要注意的是不要解释会出现什么样的异常。
这样维护人员在看到这段代码的时候肯定首先会联想到自己以前看过的一些文章，并坚信这段“废话代码”肯定是不能删除的。代码中如果存在多处这种注释的话效果更佳。
3、障眼法篇
一、入门
让你的代码和注释交融在一起，算是入门级的代码伪装术，主要目的是恶心后来的维护者，假使看代码的人刚好头昏脑涨的话肯定会直接懵逼一会，懵逼完之后再一阵恶心。
如果代码和注释的逻辑刚好是一脉相承下来的那自然更好，具体操作可以参考下面的样板实例。
样板示例：
二、同义词
这种招式一般是建议用在C类程序的宏定义中，使用的原则也比较简单，即宏名称和具体的值杂糅使用即可，造成一种你中有我，我中有你的既视感。
样板示例：
三、命名不一致
这部分主要应用在前端开发中，举个例子大家就清楚了，比如Web界面上邮政编码显示为postal code，代码中把变量名命名为zipcode，我相信不论谁看到这种情况都不敢直接改代码的，肯定要反复确认一会postal code 对应的变量到底是不是zipcode。
四、宏定义隐藏
需要说明的是这里的隐藏不是说将宏定义藏到找不到的地方，那肯定是不行的，说不定我们自己还要进行修改呢。
这里说的宏定义隐藏是指将宏定义写的不像宏定义，让看代码的人一眼看去觉得这不是一个宏，然后略过去。
话不多说，上样板：
#define a=b a=0-b
五、变量名换行
这一招我只能用猥琐来形容了，因为真的是猥琐。产生的效果是即难阅读也很难进行变量名的搜索。
样板示例：
#define local_var xy\ _z // local_var OK
六、全局变量
这里说的是隐藏全局变量，方法就是在函数里面使用全局变量时不直接使用，而是以传参的形式传进来后进行使用，这样很难分辨出这是一个全局变量。
七、函数重载
正常重载后的函数，其功能应该和被重载的函数应该是接近的，我们要做的就是让重载后的函数和被重载函数的功能完全没有关系。
这个时候看代码的人如果基础不牢的话，可能需要去温习下函数重载的知识，是不是自己以前理解错了。
八、操作符重载
操作符重载是一种很变态的招式，因为他会让你的代码变的非常的诡异，只要按照下面描述的方式进行使用基本可以把代码的混乱程度直接拉升到艺术的级别，艺术就是打破常规，所以一般只要不按照操作符重载推荐的使用方式去使用都能收到意想不到的效果。
样板示例：类中重载 ! 操作符，重载后的功能不是取反而让其返回一个整数，于是当使用!!时会先调用被重载后的函数，返回一个整数，然后再取反，最后返回个bool值，一脸懵逼。
九、混乱#define
这一招用上后我觉得看代码的人如果不是稳如老狗的老司机应该会抱头痛哭的。不信可以看下面的这段样板代码。
样板示例：
4、变量命令篇
一、大小写任意交替
这种基本上就是一种骂娘的命名方式，为啥会这么容易引起怒火，看个例子就知道了：gGEtpRoDucTnaME，有没有脑裂的感觉？
二、单字母变量
名称上毫无逻辑可言。
样板代码：
三、字母 数字很配
如果字母a – z 不够使用，可以考虑字母 数字的组合，这样一般就足够使用了，毕竟数字是无限的。
样板示例：
四、故意拼错
变量名称拼错并不是随意一个单词就拼错，此处指的是比较有创意的拼写错误。
因为随意的拼写错误是很容易被发现的，高级的拼写错误由于很难看出来，所以在进行变量搜索的时候根本搜不出来。 比如：SetPintle、SetPintalClosing。
五、重复名称
函数或者方法的内嵌结构中使用和函数或者方法层面中同名的变量名，变量名多的话可能会一阵眩晕。
5、进阶篇
前面的注释和变量命名可以说是本文的基础篇，主要是较大家一些基本的编程技巧。这一篇作为进阶的一篇，我会给大家介绍一下常见的一些稍微高端的编程技巧，废话不多说，一起看下：
一、void*
不管什么类型的指针一律都用声明定义为void*，当实际用到时再转换为需要的类型。
二、条件表达式
条件表达式这块可以发挥的空间就比较大了，从实际编码情况来看，每个简单的条件表达式都可以进行拆分，看个例子就明白了。
10 == num，拆分为 num >= 99 && num <= 101
三、长代码
什么，一行最多80个字符？ 不行，这才哪到哪，一定要跨行，而且要跨多行，不能因为换行影响了我们写代码的那股激情。
原则就是越长越好，这样后续阅读代码的人就需要来来回回地读，想想都觉得累。
四、嵌套
一个优秀的程序员必须能够在一行代码中使用超过10个小括号()，如果觉得很难得话在一个函数里面使用超过5层的大括号也是可以的，还不行的话把嵌套的条件语句if … else 转为[?:] 也是可以说明你是个优秀的程序员的。
五、不要break
不要在代码的循环中使用break，更不要使用goto，这样可以保证一行break可以处理的代码最少要写5层的if … else 来解决，一遇到break 就多出百十行代码，想想都过瘾，一天下来光看看新增的代码行数就觉得充实。
六、尽量使用XML
XML 的强大是无人能及的，不是JSON、Yaml这些所能及的。项目中使用XML 可以帮助我们将原来只需要10行的代码变为100行(可能还不止)。XML是无所不能的，哪怕是自己封装自己也是可以做到的，信XML 得永生，信XML 的自信!
样板代码：
七、测试
测试，不存在的。
一般建议不要测试，测试是一种懦夫的行为，作为一个优秀的程序员我们必须保持这种对自己代码的自信，再者测试会影响你的生产力，直接影响你写代码的行数，所以测试这一步直接跳过就好啦。
作者简介：阿木，目前就职于国内某知名互联网公司，担任云计算技术部高级工程师，近3年云计算从业经验，爱读书、爱写作、爱技术。
作者 | 阿木
责编 | 伍杏玲
出品 | 程序人生（ID：coder_life）
整理 |千锋web前端
,
