问题标签 [anti-patterns]

首先让我说我不提倡这种方法，但我最近看到了它，我想知道是否有一个名字可以用来指出有罪的一方。所以这里。

现在你有了一个方法，你想返回一个值。您还想返回错误代码。当然，异常是更好的选择，但无论出于何种原因，您都需要一个错误代码。记住，我在这里扮演魔鬼的拥护者。因此，您创建了一个通用类，如下所示：

然后像这样声明你的函数：

此模式的一种变体是使用枚举作为错误代码而不是字符串。现在，回到我的问题：有这个名字吗？如果有，它是什么？

我继承了一个怪物。

它伪装成 .NET 1.1 应用程序处理符合医疗保健索赔支付 (ANSI 835) 标准的文本文件，但它是一个怪物。正在处理的信息涉及医疗保健索赔、EOB 和报销。这些文件由在前几个位置具有标识符的记录和根据该类型记录的规范格式化的数据字段组成。一些记录 ID 是控制段 ID，用于分隔与特定类型事务相关的记录组。

为了处理一个文件，我的小怪物读取第一条记录，确定即将发生的事务类型，然后根据当前正在处理的事务类型开始处理其他记录。为此，它使用嵌套的 if。由于有许多记录类型，因此需要做出许多决定。每个决策都涉及一些处理和 2-3 个其他决策，需要根据之前的决策做出。这意味着嵌套的 if 有很多嵌套。这就是我的问题所在。

这个嵌套的 if 有 715 行长。是的，这是正确的。七百五十条线。我不是代码分析专家，所以我下载了几个免费软件分析工具，得出的 McCabe 循环复杂度等级为 49。他们告诉我这是一个相当高的数字。与亚特兰大地区的花粉计数一样高，其中 100 是高标准，新闻称“今天的花粉计数为 1,523”。这是我有幸看到的箭头反模式最好的例子之一。在其最高处，缩进深度为 15 个制表符。

我的问题是，你会建议用什么方法来重构或重组这样的东西？

我花了一些时间寻找想法，但没有什么能让我站稳脚跟。例如，用保护条件代替级别是一种方法。我只有其中一个。一窝下来，十四走。

也许有一种设计模式可能会有所帮助。指挥链会是解决这个问题的一种方式吗？请记住，它必须保留在 .NET 1.1 中。

感谢您的任何想法。

你能发布一个真实的，过度的意大利面条代码的简短示例，可能会说明它的作用吗？你能告诉我一个小调试器的噩梦吗？

我不是说IOCCC代码，那是科幻小说。我的意思是发生在你身上的现实生活中的例子......

更新

重点已经从“发布一些意大利面条代码”变为“究竟什么是意大利面条代码？”。从历史的角度来看，目前的选择似乎是：

• 大量使用计算 goto 的旧 Fortran 代码
• 使用 ALTER 语句的旧 Cobol 代码

我使用 Struts 1.2.4 继承了这个巨大的遗留 Java Web 应用程序。我有一个关于 ActionForms 的具体问题。其中一些只有字符串属性（即使是数字），其中一些使用看似合适的类型（整数、日期、字符串等）。这里的最佳做法是什么？

此外，如果一个属性是整数类型，并且用户输入的值不是整数值，Struts 会默默地接受它，只是不设置属性。这是怎么回事？

我使用 Struts 1.2.4 继承了这个巨大的遗留 Java Web 应用程序。我有一个关于行动的具体问题。大多数页面只有一个 Action，而 processExecute() 方法是可怕的怪物（非常长且大量基于请求参数的嵌套 if 语句）。

鉴于动作是命令模式的一种实现，我正在考虑将这些动作拆分为每个用户手势一个动作。不过，这将是一次大型重构，我想知道：

1. 这是正确的方向吗？
2. 有没有我可以采取的中间步骤，一种处理单体操作内部混乱的模式？也许动作中的另一个命令模式？

I periodically am called upon to do maintenance work on a system that was built by a real rocket surgeon. There's so much wrong with it that it's hard to know where to start.

No, wait, I'll start at the beginning: in the early days of the project, the designer was told that the system would need to scale, and he'd read that a source of scalability problems was traffic between the application and database servers, so he made sure to minimize this traffic. How? By putting all of the application logic in SQL Server stored procedures.

Seriously. The great bulk of the application functions by the HTML front end formulating XML messages. When the middle tier receives an XML message, it uses the document element's tag name as the name of the stored procedure it should call, and calls the SP, passing it the entire XML message as a parameter. It takes the XML message that the SP returns and returns it directly back to the front end. There is no other logic in the application tier.

(There was some code in the middle tier to validate the incoming XML messages against a library of schemas. But I removed it, after ascertaining that 1) only a small handful of messages had corresponding schemas, 2) the messages didn't actually conform to these schemas, and 3) after validating the messages, if any errors were encountered, the method discarded them. "This fuse box is a real time-saver - it comes from the factory with pennies pre-installed!")

I've seen software that does the wrong thing before. Lots of it. I've written quite a bit. But I've never seen anything like the steely-eyed determination to do the wrong thing, at every possible turn, that's embodied in the design and programming of this system.

Well, at least he went with what he knew, right? Um. Apparently, what he knew was Access. And he didn't really understand Access. Or databases.

Here's a common pattern in this code:

Okay, fine. You don't trust the query optimizer either. But how about this? (Originally, I was going to post this in What's the best comment in source code you have ever encountered? but I realized that there was so much more to write about than just this one comment, and things just got out of hand.) At the end of many of the utility stored procedures, you'll see code that looks like the following:

Yes, that code is doing exactly what you can't allow yourself to believe it's doing lest you be driven mad. If the variable contains a NULL, he's alerting the caller by changing its value to -9999. Here's how this number is commonly used:

Really.

For another dimension of this system, see the article on thedailywtf.com entitled I Think I'll Call Them "Transactions". I'm not making any of this up. I swear.

I'm often reminded, when I work on this system, of Wolfgang Pauli's famous response to a student: "That isn't right. It isn't even wrong."

This can't really be the very worst program ever. It's definitely the worst one I've worked on in my entire 30-year (yikes) career. But I haven't seen everything. What have you seen?

在最近的Dot Net Rocks 播客中，Jon Skeet 提到了可能滥用 LINQ 语法。人们见过哪些用 LINQ 做疯狂事情的​​例子？

在开发嵌入式系统时，您认为应该遵循哪些“最差实践”？

我对不该做什么的一些想法是：

在典型的“四人帮”列表中，是否有任何您经常发现被滥用、误解或过度使用的设计模式（除了备受争议的 Singleton）？换句话说，您是否建议在使用前三思而后行的设计模式？（为什么？）

对于那些不熟悉这个概念的人来说，抽象反转是在高级构造之上实现低级构造，并且通常被认为是一件坏事，因为它增加了不必要的复杂性和不必要的开销。当然，这是一个有点不精确、主观的定义。

在您看来，使用单一范式 OOP 语言进行编程，其中所有内容都必须是类的一部分，并且不会暴露诸如指针之类的东西，例如 Java 或 C#，是否不可避免地会导致抽象反转？如果是，在什么情况下？