破坏编码标准
软件公司实施了各种编码标准，其目的是提高代码可靠性，可移植性，最重要的是提高不同开发人员共同编写的代码的可读性。 两个著名的例子是MISRA C和为JSF项目开发的C ++标准。 在仔细指定单词“ must”，“ shall”，“ should”，“ might”等之后，这些通常采用以下格式： 例： 规则50：不应测试浮点变量的完全相等或不相等。 原理：由于浮点数容易出现舍入和截断错误，因此即使达到预期，也可能无法实现精确的相等性。 这些编码标准通常会限制从编译器的角度来看是合法的代码，但这些代码很危险或不可读，因此被认为“有害”。 现在让我们滥用它！ 您被接受为公司小型标准化委员会的成员，该委员会旨在设计公司每个开发人员都必须使用的新编码标准。在其他人不知道的情况下，您秘密地在一个险恶的组织中工作，并且以破坏公司为己任。您必须为编码标准提出一个或多个条目，这以后会阻碍开发人员。但是，您必须小心，不要立即使其变得明显，否则您可能会冒不被标准接受的风险。 换句话说，您必须在编码标准中引入看起来合法的规则，并且很有可能被委员会其他成员接受。之后，项目启动和无数的工时投入的代码，你应该能够滥用这些规则（例如，通过一个技术性，或者通过非常字面解释），以将其他正常且高质量的代码标记为违反标准。因此，他们必须付出很大的努力来重新设计它，而规则会从现在开始阻碍它们。但是，由于规则在相当长的一段时间内一直处于活动状态，纯净的势头将使这些角色继续存在，并且存在重大冲突出于不同管理层之间利益关系的考虑，其他经理可能会保持规则有效（他们承认错误会很愚蠢！），从而阻碍了公司的发展！哇哈哈哈哈哈！ 计分 从第一个有效条目开始大约2周后，获得最高票数的答案。我有一个很好的答案的主意，但几天后我将只发布它，因为其他人可能也有相同的主意，并且我不想从他们的快乐中抢走。当然，无论分数如何，我自己的答案都不会被接受。 鼓励选民根据漏洞的隐藏程度以及对开发人员的沮丧程度为答案打分。 条款和规则 一条或多条规则必须看起来专业，就像上面的示例一样 规则看起来应该是真实的（因此“诸如所有变量必须至少包含一个下划线，一个大写字母，一个小写字母和两个数字之类的东西”是不可接受的。它们确实会阻碍开发人员，但很可能不会被开发人员接受。委员会），如果他们的优点不是立即显而易见的，则应给出充分的理由。 以后您应该能够找到一种使用/滥用规则破坏开发人员的方法。您可能会滥用其他规则中的任何歧义，或者您可能会使用多个规则，这些规则本身无害，但一旦组合起来便是有害的！ 您应该在文章结尾处在剧透标签中发布有关如何滥用规则的说明 使用的语言不能是深奥的语言。必须选择一种在实际项目中广泛使用的语言，因此首选具有类似C语法的语言（而不是像Golfscript这样的语言）。