本文来自于微信公众号程序人生(ID：coder_life)，作者：阿木，tag知识库经授权转载。

编写除了自己没人能看懂的代码，是一种怎样的体验?

下面由作为资深挖坑程序员的我，手把手教大家这是怎么做到的?如果各位可以在接下来的时间多加练习，所谓青出于蓝胜于蓝，相信各位不但可以写出别人无法维护的代码，还可能在有朝一日，甚至能技艺炉火纯青地写出自己都维护不了的代码。

编写无法维护的代码说难其实并不难，核心要点就是和编码规范反其道而行之，如果在此基础上再添加一些自己琢磨出的心得的话那就更加完美了。

掌握了这个要点还不够，还要注意一个原则：不要让我们的代码一眼看上去就无法维护，格式之类的还是要注意些的，我们要追求的不是这种肤浅的表面上的无法维护，我们要的是实质是无法维护的。

要是别人一眼就能看出你的代码无法维护，那你的代码就存在需要重写或者重构的风险了，那不成了前功尽弃亲者痛，仇者快的事情了嘛。

了解清常规编程的思维方式再下手!

《孙子兵法》有云“知己知彼，百战不殆”，假如我们要想从心理上彻底击败后续的代码维护人员，我们必须明白常规编程中的一些思维方式。

各位先想下，如果接手程序的是我们自己，而且代码量比较大，一般我们是没有时间去从头到尾一行一行地读一遍的，更不要说能理解代码了。

为了能尽快地上线交差，程序员常见的做法是根据需求，先快速找到代码中需要改动的那一部分逻辑，然后对这部分的代码进行修改、测试。这种修改方式一次只能看到代码的一小部分，管中窥豹。

所以我们要做的是确保让代码维护人员永远看不到我们写的代码的全貌，要尽量保证代码维护人员找不到他想要找到的那部分代码。这还不是最关键的，最关键的是要让修改者知道自己没有忽略任何的东西。

每一个我们精心设计的这些小陷阱都会迫使代码维护者像用放大镜似的，仔细地阅读我们的每一行代码。

有些同学可能觉得这很简单，认为只要按照上文中提到的反编程规范原则来进行即可。但是实际操作起来并没有这么简单，还需要配合我们的精心误用才可。下面我们就对常用的一些核心技能娓娓道来。

第一招：一本正经地乱用注释

这一部分我们先了解下注释的正常用途：注释是用来帮助开发者理解程序的，尤其是对于后来的开发者，通过注释可以更快的了解代码的实际作用。

正常情况下代码注释的原则一般是只在需要注释的地方进行注释。这是一句很正确的废话，解释起来就是很明显就能看懂的代码就不要去注释的了，毕竟看注释也是需要花费时间的。

另外一个原则就是在注释中注明代码的作用需要和代码的实际作用是一致。

在实际工作中，在对代码进行修改后一定要连同代码的注释也一起进行修改。关于注释的其他的一些作用我们在此不再多说，光是这些就已经足够我们用的了。

如何利用代码注释写出让人无法理解的代码呢?

一、多整没用的

这块我分了两种情况来描述，两种情况对应两种处理方式，实用性比较强。

• 明显型注释

让维护者浪费时间看显而易见的注释。

这部分的原则是维护者看完注释后觉得“代码比注释容易读多了”，目的就是误导读代码的人。维护者在看代码时，上眼一看代码很清晰，但又一看竟然还有注释。

此时读代码的人心里肯定是要嘀咕下：看来这代码没我想的这么简单。

然后我们的注释要写的长一些，最后是要阅读者看不懂，改的时候犹豫不决。

如果有余力的话可以在注释中教维护者怎么编程，这种一般杀伤力要比上面写的会高一些，程序员最反感的可能就是你要教他怎么编程了，尤其是教他这么简单的编程，杀伤力加倍。

下面看个例子：

• 废弃代码注释

字面意思已经很清楚了，正常情况下代码中不用的部分我们一般会注释掉或者直接删除掉，即使这段代码将来会使用到也不影响，可以从版本控制工具中再找回来。

针对性的做法就是给删掉的代码加个长长的注释，写明这段代码为什么会被注释起来，也向维护者传达了一个信息，即这段代码不是被”废弃”的，而是”临时”先不用。

这样做的杀伤点就在，如果只注释了代码没加注释说明，根据实际经验大家多数会直接略过被注释的代码，而给代码加了注释后看代码的人可能就要看看这个注释了，不然会漏掉什么关键信息，毕竟代码不是他写的。

样板代码：

二、这个地方将来会修改

这种注释就是我们经常提到的“TODO”型注释。正常情况下TODO注释并非一无是处，比如在初始化项目的时候TODO注释还是非常有用的，到项目release 时一般是建议去掉的，如果必须要留着一般需要写明在具体什么日期会处理掉。一般是不推荐TODO型注释长期存在于项目的代码中，正常的处理逻辑一般是遵循有Bug尽快Fix，无Bug则去掉注释。

通过上面的描述相信大家已经知道这块具体要怎么应对了。个人建议是对于有待修改的多写点TODO注释，且不注明更改的原因以及计划更改的时间，这样后面的维护人员在看的时候可能连这块到底是不是已经改过了都搞不清楚，所以杀伤效果也是有一些的。

样板代码：

三、错误注释信息

这部分的意思是造成代码和注释的不匹配，也就是注释的信息不正确。 

我们要做的就是改完代码后不改注释就行了，此种方式比较省事，额外工作一点也不用多做，但是稍微有些代价，需要注意的是最好是在此类注释中加个特殊的标记，防止自己后续看的时候把自己也绕进去。

样板实例这块就不用加了吧，场景太多了，大家在自己的一亩三分地上耕作时临场发挥即可。

四、讲故事

简单说来就是写明这段代码为什么要这样写，当然肯定不是单纯的原因。除了原因一般建议在注释中写上当时的情况，比如某年某月和某人在某地讨论了这个问题，某人说这个问题应该怎样处理，你说这个问题不该这样处理应该那样处理，后来某某人又加入了讨论，某某人对俩的讨论做了某某的评价，最后决定要用现在的代码去实现这块的功能。

总之，原则就是把事情的细节描述清楚，越细越好。有些同学可能会建议将当天的天气情况也写上，还有讨论中那个气死人的S*名字也要带上，我个人认为天气可以酌情添加，但写上S*名字是不太鼓励的，毕竟同事一场，要相互爱护的，大家按照自己公司的实际情况来选择具体的处理方式吧。

样板代码：

五、不要写原因

按照注释的规范，注释时不但要解释程序的表述的意思，更重要的是写明为什么写，即代码这么写的原因是什么。

这样应对之策也已经显而易见了，对于复杂程序，比如一些特殊的边界条件判断，只写下程序的字面意思，具体边界值判断为什么要这样写，为什么是这个值可以忽略掉，让维护的人尽情去猜吧。

六、琐碎

在这需要注明的是大部分程序注释一般是用不到这种情况的，一般是推荐放在一些复杂算法的解释上，越是复杂的算法越是推荐，原则就是把这部分应该写到文档中的内容写到代码中。

一定要把算法的所有的详细设计都写上，注释内容分段落，段落之间要分级，每个段落建议加上编号，这样就基本可以保证代码的注释和文档的内容保持一致。后续的维护看到这样的注释的时候基本可以保证头大一圈，如果此类注释存在多处的话效果更佳。

鉴于样板示例中注释篇幅太长就不加示例了。

七、单位问题

单位这部分和具体的业务场景相关，比如时间相关的一般会有毫秒、秒、分钟、小时、天、月、年等，涉及尺寸的场景如像素、英寸等，涉及文件大小的场景如字节、KB、MB、GB等。

这一类的代码中我们的原则是不对单位进行注释，只管使用，如果可以在代码中各种单位混用，那自然是更加优秀。

比如在关于文件处理的场景中，KB、MB、GB多个单位混合使用，这样后来的维护人员要想搞懂这部分代码中单位的真正含义就要下一番功夫了。

按照我们的正常逻辑，后面的人要想改这部分的代码的逻辑首先要先弄懂各个数据的单位，搞清楚之前肯定是不敢随意修改的，一般这种情况只有一种解决办法那就是一遍遍的调试、测试程序来推算各个数据实际的单位，花费的时间自然是相当的多。

八、恐吓

这一招可以说是杀手锏级别的注释，可以在程序中加一部分可有可无的代码，而且是很明显可有可无的那种，然后给这段程序加个注释，注释中写明“千万不要注释掉或者删除这段代码，否则程序会出现异常!!!”，需要注意的是不要解释会出现什么样的异常。

这样维护人员在看到这段代码的时候肯定首先会联想到自己以前看过的一些文章，并坚信这段“废话代码”肯定是不能删除的。代码中如果存在多处这种注释的话效果更佳。