类名称中的“助手”一词是否有代码味道？
我们似乎是从网页中抽象出许多逻辑方式，并创build“帮手”类。 可悲的是，这些class级听起来都是一样的，例如
ADHelper，（Active Directory）AuthenicationHelper，SharePointHelper
这个命名约定其他人有大量的类吗？
我认为它可以作为一种代码味道， 但要记住代码味道并不一定会带来麻烦。 这是你应该看看，然后决定是否可以。
话虽如此，我个人发现这样一个名字增加了很less的价值，因为它是如此通用的types可能很容易成为一个非相关的效用方法桶。 即助手类可能会变成大类，这是常见的代码气味之一 。
如果可能的话，我build议find一个更接近描述这些方法的types名称。 当然这可能会提示更多的帮手类，但只要他们的名字有帮助，我不介意数字。
前一段时间，我在代码审查过程中遇到了一个名为XmlHelper的类。 它有很多方法，显然都与Xml有关。 然而，从types名称中不清楚这些方法有什么共同之处（除了与XML有关）。 原来，一些方法是格式化Xml和其他人parsingXml。 所以海事组织这个class应该分成两个或更多的部分，更具体的名称。
一如既往，这取决于上下文。
当你使用自己的API时，我肯定会认为它是一种代码异味，因为FooHelper指出它在Foo运行，但行为很可能直接属于Foo类。
但是，当您使用现有的API （如BCL中的types）时，无法更改实现，因此扩展方法成为解决原始API中缺陷的方法之一。 你可以select像FooExtension这样的名字以及FooExtension 。 这是同样臭（或不）。
取决于课程的实际内容。
如果辅助类中有大量实际的业务逻辑/业务规则，那么我会说是。
如果这些类实际上只是可以在其他企业应用程序中使用的帮助器（绝对意义上的重用 – 不能复制然后自定义），那么我会说帮助者不是代码味道。
这是一个有趣的观点，如果一个字变成了名字上的“样板”，那么它可能会有些微妙 – 如果不是一个真正的味道。 也许使用一个'助手'文件夹，然后让它出现在命名空间保持它的使用，而不是过度使用这个词？
Application.Helper.SharePoint Application.Helper.Authentication
等等
在许多情况下，我使用以Helper结尾的类作为包含扩展方法的静态类。 对我来说似乎并不臭。 你不能把它们放到一个非静态的类中，而这个类本身并不重要，所以Helper很好，我想。 无论如何，这样的类的用户将不会看到类名。
.NET框架也是这样做的（例如WPF中的LogicalTreeHelper类，它只有一些静态（非扩展）方法）。
问问你自己，如果你的助手类中的代码被重构为“真实”的类，也就是符合你的类层次结构的对象，代码会更好。 代码必须在某个地方，如果你不能确定它真正属于哪个类/对象，就像简单的帮助函数（因此是“Helper”），你应该没问题。
我不会说这是一种代码味道。 在ASP.NET MVC中是相当普遍的。
