问题标签 [coding-style]

我正在使用许多“帮助器”类，它们有效地具有一堆静态函数，允许控制器和操作访问共享功能块。

问题是这些文件已被用作跨模块/应用程序所需的任何功能的垃圾场，因此它们的大小 > 3k 行，并且在顶部它们有大约 50 个require_once声明！

显然，如果应用程序中的视图不想使用这些帮助程序提供的一小部分功能，它会继承所有必需的文件，最终导致应用程序膨胀。

require_once如果我要根据需要包含文件，那么当我需要使用这些帮助程序提供的大量功能时，我最终可能会对所需文件进行多次调用，这有它自己的开销（与频率相结合）文件。

所以基本上我的问题是在哪里取得平衡，是否有可以采用的最佳实践？

谢谢，

弗隆加

您发现发布编码标准的最佳方式是什么？为什么？

我的编码风格包括以下成语：

这使我能够使用“super”作为 Base 的别名，例如，在构造函数中：

甚至在从其覆盖版本中的基类调用方法时：

它甚至可以被链接起来（不过，我仍然需要找到它的用途）：

无论如何，我发现“typedef super”的使用非常有用，例如，当 Base 是冗长和/或模板化时。

事实是 super 是用 Java 和 C# 实现的（它被称为“base”，除非我错了）。但是 C++ 缺少这个关键字。

所以，我的问题：

• 在您使用的代码中，这种使用 typedef 是超级常见/罕见/从未见过的吗？
• 这种使用 typedef 是否超级好（即您是否看到了不使用它的强烈或不那么强烈的理由）？
• “超级”应该是一件好事，它是否应该在 C++ 中有所标准化，或者通过 typedef 使用它已经足够了吗？

编辑： Roddy 提到 typedef 应该是私有的。这意味着任何派生类都无法在不重新声明的情况下使用它。但我想它也会阻止 super::super 链接（但谁会为此哭泣呢？）。

编辑2：现在，在大量使用“超级”几个月后，我完全同意罗迪的观点：“超级”应该是私有的。我会两次赞成他的回答，但我想我不能。

我使用 Ruby 已经有一段时间了，我发现，对于更大的项目，它会占用相当多的内存。在 Ruby 中减少内存使用的最佳实践是什么？

• 请让每个答案都有一个“最佳实践”，并让社区投票。

有时我将ifs 中的长条件分成几行。最明显的方法是：

视觉上不是很吸引人，因为动作与条件融为一体。但是，这是使用正确的 Python 缩进 4 个空格的自然方式。

目前我正在使用：

但这不是很漂亮。:-)

你能推荐一种替代方法吗？

我们正在制定我们希望在我们的开发团队中使用的设计指南，并在今天就如何命名 ASP.NET 控件展开讨论。我说的是我们的好朋友 Label、TextBox、Button 等。

我们提出了以下三种我们投票的可能性：（示例是输入/显示名字的文本框）

1. 将控件类型作为后缀添加到控件 ID：[FirstName _TextBox] 或 [FirstName _tbx]
2. 将控件类型作为前缀添加到控件 ID [tbxFirstName]
3. 将控件的 ID 设置为 FirstName 并命名相关字段（如文本框的标签或验证器），如选项 2 [lblTextBox] 中所示。

我们最终决定使用选项 2。它不像选项 1 那样冗长，我喜欢它在控件名称之前指定它是什么控件。

我的问题是，Microsoft 是否针对这些前缀发布了任何指南，或者您是否对我们的决定有任何意见。

在处理大型 C/C++ 项目时，您是否对源文件或头文件中的#include有一些特定规则？

例如，我们可以想象遵循以下两个过度规则之一：

1. .h文件中禁止使用#include ；由每个.c文件来包含它需要的所有头文件
2. 每个.h文件都应包含其所有依赖项，即它应该能够单独编译而不会出现任何错误。

我想任何项目之间都有权衡，但你的呢？你有更具体的规则吗？或者任何支持任何解决方案的链接？

我最近遇到了这段 JavaScript 代码：

我很感兴趣，因为要编写这个测试，我会这样做：

这只是风格上的差异，还是其他代码的作者知道一些我不知道的优化？或者也许有不同的充分理由这样做，或者不使用正则表达式......？

在我看来，使用String.indexOf()for this 有点难以阅读（但是，我对正则表达式很满意），但是在某些情况下它可能比编写等效的正则表达式“更好”吗？

通过“更好”可能更快或更有效，（尽管显然这取决于浏览器的 JavaScript 引擎），或者我不知道的其他一些原因。任何人都可以启发我吗？

在Google C++ Style Guide中，运算符重载部分建议不要重载任何运算符（“除非在罕见的特殊情况下”）。具体来说，它建议：

特别是，不要重载 operator==或operator<只是为了让你的类可以用作 STL 容器中的键；相反，您应该在声明容器时创建相等和比较函子类型。

我对这样的仿函数看起来有点模糊，但我的主要问题是，你为什么要为此编写自己的仿函数？定义operator<和使用标准std::less<T>函数不会更简单吗？使用其中一个有什么优势吗？

拥有一个使用默认参数的类构造函数是一种好习惯，还是应该使用单独的重载构造函数？例如：

任何一个版本似乎都可以工作，例如：

你喜欢或推荐哪种风格，为什么？