存在哪些命名反模式？[关闭]

有一些名字，如果您发现自己喜欢这些名字，那您就知道自己已经搞砸了。

例如：

XxxManager
这很不好，因为一个类应该描述该类做什么。如果您能为该班级提出的最具体的词是“管理”，则该班级太大。

还有哪些其他命名反模式？

需要澄清的是，我并不是在问“名字不好”的问题-这个问题完全是主观的，无法回答。我问，“什么名字表示系统的总体设计问题”。也就是说，如果您发现自己想调用组件Xyz，则可能表明该组件不安全。还要注意，每条规则都有例外-我只是在寻找警告标志，以指示何时确实需要停止并重新考虑设计。

以下命名反模式与.NET（尤其是C＃）相关：

• 不一致之处。如果您决定在每个字段名称前都使用下划线开头，请坚持使用。
• 带有元音缺失的Ambiguos缩写。我已经认真看过诸如的字段名称cxtCtrlMngr。您几乎无法猜测这应该代表什么。
• 变量名太长且太冗长。ILoginAttemptRepository很好且具有描述性- ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMapping具有描述性，但绝对不可行。

我经常遇到的一种情况是，根本不使用任何命名模式。通常表示开发人员无知（命名模式是一件好事），并且这种反模式也倾向于通过将与类相关的各种方法填充到该类本身中来严重违反SRP，例如，客户类具有属性，CRUD方法以及应用程序某些部分所需的与Customer远程相关的任何内容。

我还要补充一点，使用“ Engine”作为后缀与使用“ Manager”大约相同。这是非常模糊的，一个叫做class的类XxxEngine往往相当于一个VB样式的模块，其中包含一堆方法，因此它处于一个“易于使用”的位置，而无需任何面向对象编程的知识或想法。

好吧，首先给出简单的答案：输入匈牙利语（http://mindprod.com/jgloss/unmainnaming.html，也有其他一些好主意。关于何时匈牙利语不是邪恶的观点更为平衡， http://www.joelonsoftware.com /articles/Wrong.html）

在接口名称前添加“ I”，在抽象类名称前添加“ Abstract”。在没有抽象类概念的语言中，或者在接口和抽象类之间没有区别的语言中，这可能是可以原谅的，但是例如在Java中，这总是一个坏主意。

另外，在经理方面，我也不同意您的看法。有时，我会使用该模式，这意味着如果我尝试使用其他名称，该名称将比XxxxxManager更具描述性。有些任务（不一定是复杂的任务）只是不能用一两个词来巧妙地概括。

撒尿：

我有严重的残疾，不会拼写。没有拼写检查器，我无能为力，我尝试将创建的所有名称复制到文字处理器中进行验证，但是我总是会错过一些名称。在我的上一个项目中，我编写了大部分的api，我想我第一次使用responce一词时并没有拼写检查，而且我认为这是正确的，因为没有人告诉我。我们至少有50个具有响应功能。一个新成员加入团队，问我为什么使用响应，我感到很愚蠢。

好吧，恐怕我的观点有点争议。但是让我们尝试...

就我而言，我必须同意Mike Baranczak，像XxxController，XxxHandler这样的名字是我们真正经常使用的东西。对我们而言，Controller就像是“封装”的入口点，例如管理事务，处理意外错误，调用XxxHandler进行实际工作。我会说XxxManager是控制器的同义词。我认为重要的是，不要在一种情况下使用Manager，而在另一种情况下使用Controller。如果您在团队中工作，保持一致非常重要。

很难为这样的东西找到更好的名字，甚至是不可能。最好选择Xxx，以使情况更加清楚。

我个人不喜欢的是，当一个名为get ...或set ...的方法不仅仅是一个简单的访问器时。我喜欢det ...确定。

我想到的另一件事是：鲍伯叔叔。方法名称中的“ And”表示已做很多事情。但是生活并不总是黑白的-在某些情况下我认为还可以-例如。由于性能问题（当您已经有数据以检查为什么不处理它们时）...

我个人也是系统匈牙利表示法的忠实拥护者-大多数情况下，您在IDE ok中处理源代码。但是通常您只使用编辑器，或者在浏览器中浏览存储库。一个缺点可能是由于类型前缀而导致的工具支持...

我认为最重要的是，对我而言，养蜂是一种不理想的习惯，比没有习惯更好。

也许最糟糕的命名反模式是：

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

我们有[foo，bar]对的三元素列表。如果需要第四列，则必须向表中添加新列。

导致这样的代码：

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

应该使用foo和bar列创建一个单独的表，并将其链接到东西表：

create table fubar(foo string, bar string, stuff_id long)

第二个最糟糕的情况是：

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

在这里，我们有六个字段，而不是Address类的两个实例。

此反模式由一系列由两部分组成的名称标记，列出了两组的每种组合，例如[foo，bar] x [1,2,3]或[home，perm] x [街道，城市，州]

重言式的任何类或接口命名都是不好的，不仅是链接所讨论的Java，而且是任何语言。

重言式（修辞格），即使重复没有提供清晰的含义，也使用不同的词来表达相同的意思。

我经常遇到带有通用名称（例如Library或）的软件库Common。它们表示次优设计：开发人员努力避免代码重复，但未尝试创建基于功能分解的设计。

从Microsoft的命名开始，我可以提供以下不良名称列表：

1. 它们不是语义的，这意味着它们具有名称，而不是强调其功能，而是强调其使用的技术或其基于的模式。
2. 他们没有遵循语法上的一致性。例如，名称的一部分用驼峰大小写，而另一部分则用pascal大小写。
3. 它们是难以理解的缩写，例如ScrollableX而不是CanScrollHorizo​​ntally
4. 选择它们的目的是使它们与该环境的关键字混淆。