Anti patterns 常见的模糊设计实践？

您在design by Fuzzation群组中看到了哪些常用的实践？我觉得在不允许重写的项目上工作很有趣，而这将是解决问题的更快、最有效的方法。

我们有一位同事将文件存储在文件夹调用/kensington中，以便“隐藏”它们。它只是包含了一些他不想看到的xml文件，并且认为人们不会在其中查看。

我和一个程序员一起工作，他曾经编写过非常复杂的条件，当遇到这些条件时，会调用一个简单地完成系统的方法。在整个应用程序中，他这样做了几十次。仍然不知道为什么……

代码中没有注释或无用的注释，也没有有用的文档。

我的最爱总是围绕变量展开……在代码中留下不再使用的变量，然后给它们所有无意义的名称。当然，如果你真的想混淆，你必须小心避免几乎所有的惯例。所以，一个完美的方法是使用两个类似的变量，一个名为myVar1，另一个名为myVarOne。诸如此类的事情

---

另一个是包含未使用的控件，这些控件仅在代码中可见。我盯着一个ASP.NET站点看了好几个小时，试图弄清楚为什么会将FormView放入其中（没有答案）。

我曾经编写过perl代码，作者决定让大多数Sub接收一个散列作为变量，并返回相同的散列，同时添加或删除数据。基本上，一个全局散列用于通过不同的代码路径传递数据

它看起来像这样：

my $hash = ();

$hash->{'CUSTID'} = 1001;
$hash = GetAccounts($hash);

if ($hash->{'AccountTotal'} > 100) {
    $hash = getTotals($hash);
    $hash->{'Acct_Sbkt_Marker'} = 'R1';
    $hash->{'Acct_Invr_Marker'} = 'BT';
    $hash = removeInvalidAccount($hash);
}

直到今天，我还不知道他试图用这个实现什么样的设计模式

---

我记得

$hash

会排列得很好

在那里，我认为设计良好的代码应该独立阅读，而不是破译

我知道，鼓励关心模糊处理的人在其他环境中使用dotfuscator等工具。混淆的意思是使代码更难反编译，而不仅仅是使它成为一种痛苦的工作

---

我无法理解为什么有人会故意设计可怕的代码（除了演示gotchas之外）。

我不理解你的问题。混淆和想要重写代码之间有什么联系？我的观点是关于代码是一个彻底的破坏，使它混淆，我只是想听听其他人有过的乐趣。可怕的是，大多数这些模式都出现在产生这个问题的项目中。我想这取决于代码。我曾经见过添加评论只是杂乱无章的情况。但是其他时候，如果能知道开发人员的想法，那就太好了。当代码被更改并且注释与代码的功能不再匹配时，这通常是一个问题。使下一位读者很难判断代码是否错误或注释是否正确。没有评论总比错误的评论好。我不反对。意外或故意的“设计混淆”可能是一种真正的痛苦。我正试图对人们遇到的其他“设计”有所了解