本文来自程序生命周期的公共微通道号（ID：coder_life），作者：Amu，Hyun-woo Technology经许可转载。 编写除了自己之外没人能理解的代码有什么经验？ 现在，作为高级挖掘程序员，我将教您如何做。 如果您下次可以练习更多，那么所谓的蓝色胜于蓝色。 我相信，您不仅可以编写别人无法维护的代码，而且有一天，您甚至可以编写无法熟练掌握的代码。 编写难以维护的代码并不难。 核心是要与编码标准相反。 如果您在此基础上添加一些想法，它将更加完美。 仅仅掌握这一点还不够，还要注意一个原则：不要一眼就使我们的代码难以维护，而要注意格式等。 我们要追求的不是这种表面和表面的不可维护性。 我们想要的是该物质无法维持。 如果其他人一眼就能看出您的代码不可维护，那么您的代码就有被重写或重构的风险。 放弃家庭和敌人将不会感到痛苦。 开始之前，请了解常规编程的思维方式！ 《孙子兵法》说：“认识自己和敌人，永远不要结束一百场战斗”。 如果我们想从心理上彻底击败后续的代码维护者，我们必须了解常规编程中的一些思维方式。 大家首先考虑一下，如果我们是接管程序的人，并且代码量相对较大，我们通常没有时间从头到尾逐行阅读它，更不用说理解代码了。 为了能够尽快上线，程序员的常规做法是根据他们的需要快速找到需要在代码中更改的逻辑部分，然后修改和测试该部分代码。 。 这种修改方法一次只能看到一小部分代码，因此您可以一窥。 因此，我们要做的就是确保代码维护者永远不会看到我们编写的代码的全部内容，并尝试确保代码维护者找不到他要查找的部分代码。 这不是最重要的事情，最重要的是让修改者知道他没有忽略任何东西。 我们精心设计的每个小陷阱都会迫使代码维护人员使用放大镜阅读我们的每行代码。 一些学生可能认为这很简单，并认为可以按照上述反编程原则来完成。 但是实际操作并非如此简单，我们需要配合谨慎使用的情况进行合作。 下面我们将讨论一些常用的核心技能。 第一个技巧：认真使用评论。 首先，让我们了解注释的常规用法：注释用于帮助开发人员理解程序，特别是对于以后的开发人员，通过注释，您可以快速了解代码的实际作用。 在正常情况下，代码注释的原理通常是仅在需要注释的地方注释。 这是一个非常正确的废话。 如果您对此进行了解释，很明显，您不应对可以理解的代码发表评论。 毕竟，阅读这些评论需要花费时间。 另一个原则是在注释中指出代码的角色需要与代码的实际角色一致。 在实际工作中，修改代码后，必须将其与代码注释一起进行修改。 关于注释的其他功能，我们在这里不再赘述，仅这些就足够了。 如何使用代码注释编写难以理解的代码？ 首先，我将整个无用的部分分为两种情况来描述。 这两种情况对应于两种处理方法，这两种方法更为实用。 明显的注释会使维护人员浪费时间查看明显的注释。 这部分的原理是，维护人员在阅读注释后会感到“代码比注释容易阅读”，目的是误导阅读代码的人。 维护人员查看代码时，乍一看代码就清晰了，但是第二眼就看到了注释。 这时，阅读代码的人必须喃喃自语：似乎代码并不像我想的那么简单。 然后，我们的评论应写得更长一些，最后，读者将无法理解和犹豫进行更改。 如果您有剩余容量，则可以在注释中教会维护人员如何进行编程。 这种一般的致死率高于上面所写的。 程序员最恶心的是，您必须教他如何编程，特别是如果您教他如何编程。 编程，杀伤力加倍。 让我们看一个例子：被丢弃的代码的注释的字面意思非常清楚。 通常情况下，我们通常会注释掉或删除代码中未使用的部分。 即使将来使用此代码，也不会影响它。 您可以从版本控制工具下载它。 在中国再次找到它。 目标方法是在已删除的代码中添加一个长注释，说明为什么要对此代码进行注释，并向维护者传达一条信息，指出该代码未“已放弃”，但未使用“临时”。 杀手point的是，如果您只注释代码而不注释，则根据实际经验，大多数人将直接跳过注释的代码，在向代码添加注释后阅读代码的人们可能希望查看此注释。 否则，将丢失一些关键信息。 毕竟，代码不是他写的。 样板代码：2.这个地方将来会被修改。 这种注释是我们经常提到的“ TODO”类型注释。 在正常情况下，TODO注释不是没有用的。 例如，在初始化项目时，TODO注释非常有用。 通常建议在项目发布时将其删除。 如果必须保留它们，通常需要指定处理它们的特定日期。 通常不建议在项目代码中长期存在TODO类型的注释。 正常的处理逻辑通常是：如果存在错误，则尽快修复该错误；如果没有错误，则删除注释。 通过以上描述，我相信每个人都已经知道如何处理这一部分。 我个人的建议是为需要修改的更改写更多的TODO注释，不要指出更改的原因和计划的更改时间，以使后面的维护人员甚至可能不知道这是否已被修改。 阅读后改变了。 所以杀人的效果也有些。 样板代码：3.错误的注释信息此部分表示代码和注释不匹配，即注释信息不正确。 我们要做的是在不更改注释的情况下更改代码。 这种方法更没有麻烦，并且根本不需要做任何额外的工作，但是有点昂贵。 应该注意的是，最好在这种类型的注释中添加一个特殊的注释。 标记它以防止以后观看时进入。 无需添加示例示例。 场景太多了。 当您在自己占地1英亩的三美分土地上耕种时，可以在现场播放。 4.讲故事只是说明为什么要用这种方式编写代码。 当然，这当然不是简单的原因。 除了原因外，一般建议在评论中写下当前情况，例如在某个年月中与某人讨论此问题，某人说如何处理此问题，您说此问题不应 这样处理，应该这样处理。 后来，有人加入了讨论，有人评论了两者之间的讨论，最后决定使用当前代码来实现此功能。 简而言之，原则是清楚地描述问题的细节，越详细越好。 一些学生可能建议将当天的天气情况也写下来，并且仍然存在讨论恼人的S *名称也应带上。 我个人认为可以适当添加天气，但是不鼓励写S *名称。 毕竟，同事应该在游戏中彼此相爱。 每个人都应遵循公司的实际情况。 选择具体的治疗方法。 样板代码：5.不写原因。 根据注释的规范，不仅要解释程序的含义，而且更重要的是，指定编写原因的原因，即编写这种代码的原因是什么。 对策已经很明显了。 对于复杂的程序，例如某些特殊的边界条件判断，只需写下该程序的字面含义，为什么要这样写特定的边界值判断，为什么可以忽略该值，并让维护者可以自由猜测。 6.琐碎的。 这里需要注意的是，在这种情况下通常不使用大多数程序注释。 通常建议解释一些复杂的算法。 算法越复杂，越推荐。 原理是把这部分内容写在文件中是写在代码中的。 确保记下该算法的所有详细设计。 评论的内容应分为几段，并对各段进行分级。 建议在每个段落中添加一个数字，以便您基本上可以确保代码注释与文档内容一致。 后续维护基本上可以确保您在看到这样的评论时会更大，而如果有多个这样的评论，效果会更好。 考虑到样例示例中注释的长度，因此未添加任何示例。 七。 单位问题单位这部分与特定的业务方案有关，例如与时间相关的通常为毫秒，秒，分钟，小时，天，月，年等，涉及大小（如像素，英寸等）的方案，以及文件大小 。 诸如字节，KB，MB，GB等场景。在这种类型的代码中，我们的原则是不对单元进行注释，而仅使用它。 如果您可以在代码中混合使用各种单位，那自然会更好。 例如，在文件处理方案中，KB，MB和GB的多个单元以混合的方式使用，因此以后的维护人员必须努力工作以理解代码这一部分中这些单元的真实含义。 根据我们的正常逻辑，如果后面的人想要更改代码这部分的逻辑，则他们必须首先了解每个数据的单位，并且他们不敢随意修改。 通常，对于这种情况只有一种解决方案。 一遍又一遍地调试和测试程序以计算每个数据的实际单位会花费大量时间。 8.这种恐吓手段可以说是杀手级的评论。 您可以向程序添加一些可选代码。代码，它显然是不需要的，然后在该程序中添加注释。 注释指出“切勿注释或删除此代码，否则程序将异常！！”，您需要注意不要解释将发生哪种异常。 这样，当维护人员看到此代码时，他们将首先想到他们之前阅读过的一些文章，并坚信此“废话代码”一定不能删除。 如果代码中有多个这样的注释，效果会更好。