在我们正在实施的每个方法中使用#region 是否好？答案

【问题标题】：Is it good to Use #region in every Method that we are implementing在我们正在实施的每个方法中使用#region 是否好？
【发布时间】：2011-03-01 04:50:30
【问题描述】：

最近我的项目经理要求为我们迄今为止所做的所有工作编写 cmets、摘要和#regions。甚至他也要求编写变量声明。就像如果我们将金额声明为双倍，那么他要求我们这样写

  /// <summary>
    /// RegularPay declared as double
    /// </summary>
    private double m_dRegularPay;

即使是 Get Set 也是如此

  /// <summary>
    /// Get and Set FirstName
    /// </summary>
    public string FirstName
    {
        get
        {
            return m_sFirstName;
        }
        set
        {
            m_sFirstName = value;
        }
    }

和区域同时实现一些代码

   #region EmpHourly
    /// <summary>
    /// Get Employe Hourly Amount
    /// </summary>
    /// <param name="EmpAmount"></param>
    /// <param name="EmpRegularHours"></param>
    /// <param name="EmpHourlyRate"></param>
    /// <param name="EmpBonusPay"></param>
    /// <param name="EmpOtherHours"></param>
    /// <param name="EmpOverTimeHours"></param>
    /// <returns></returns>
    public bool GetEmpHourlyAmount(out double EmpAmount, out double EmpRegularHours, out double EmpHourlyRate, out double EmpBonusPay, out int EmpOtherHours, out int EmpOverTimeHours)
    {
     }

我想知道的是编码标准的更好方式

【问题讨论】：

放弃 m_* 变量并使用自动实现的属性 - msdn.microsoft.com/en-us/library/bb384054.aspx
第一条评论是可怕的。
顺便说一句，一个方法不应该有这么多的'out'返回值。相反，它应该是一个返回类、结构或可能的 Tupple 的非 void 方法。

标签： c# asp.net coding-style

【解决方案1】：

注释类字段和属性是一种很好的做法，但这里的区域似乎毫无意义。我还要补充一点，过度使用 out 变量不是很好的 C# 风格。你最好返回一个对象。

【讨论】：

是的，这似乎是某种员工类，成员是工时和薪酬类。

【解决方案2】：

地区太可怕了。他们只是隐藏了您想要查看的代码。对我来说，这就像试图读一本书，但有人在每个段落上都加上了封面。没有意义。

我也认为学校的评论请求值得回击。它增加了零值，创造了忙碌的工作，并掩盖了真正的 cmets（即代码本身）。

/// <summary>
/// RegularPay declared as double
/// </summary>
private double m_dRegularPay;

这句话说了三遍。它在评论中说 RegularPay 是双倍，私人双倍 RegularPay 是私人双倍，而 m_dRegular pay 是私人双倍。

实际上，注释和符号表明在某个时间点 m_dRegularPay 是双精度的。私有双精度标识符表明 它仍然是一个私有双精度。

private double regularPay;

只说明一次。

【讨论】：

没有。它们隐藏了您不想想看到的代码。没有区域，你能做到的最好的就是折叠轮廓，这比展开所有的属性、方法和它们的 cmets 更加混乱。
是的，他们隐藏了我想看的代码。如果我不想看到它，我就不会打开文件。
@Ritch Melton - 99.99999999% 的时间，我不想看到给定文件中的每一行代码。我想查看我正在调查的线路。当您打开一本书时，您想同时查看每一页的每一行吗？
@Ritch：您希望多久一次查看所有代码？通常当我查看代码时，我想查看特定部分。区域（正确命名和组织）可以帮助找到该部分。
不，但是如果您将页面与类相关联，那么可以。地区会增加摩擦。如果你愿意，可以使用它们，但我不会。

【解决方案3】：

这种评论惯例似乎过分热心……但前后不一致。

在double RegularPay 行注释“RegularPay 声明为双精度”是一项非常忙碌的工作。这是显而易见的，指出它是多余的，浪费时间。

在您所在的地区，GetEmpHourlyAmount 的摘要可能很重要，但不会被如此对待。方法的名称和注释一样有用。

一般来说，如果您发表评论，评论应该会告诉您一些名称并没有明确告诉您的内容。评论应该显示更多有用的信息。

【讨论】：

对，这取决于评论的质量。示例 cmets 是多余的，但我经常希望获得有关其名称未提供给我的字段的目的和预期用途的更多信息。

【解决方案4】：

对我来说似乎太过分了。

为了记录它们而记录自我描述的方法/变量是浪费金钱。它们变得陈旧、过时并使代码更难阅读。

此外 - 使用区域是代码异味的标志。如果你有这么大的班级，你必须把它分成几个区域，你需要重新考虑设计。

文档和区域不会修复错误代码，并使其更难维护。好的代码是自我描述的，不需要像“评论一切”这样的笼统规则。

在适当的地方发表评论，并使用区域作为您需要修复文件结构的警告标志。

【讨论】：

【解决方案5】：

IMO 区域是一种代码味道。它们影响readability 和maintainability。当代码文件很大并且需要划分代码时，您需要区域。但是，您真的应该编写小类，每个类都做自己的任务。

在编辑带有区域的代码文件时，很难决定要将新方法放在哪个区域等。我经常看到许多区域包含应该属于另一个区域的代码。

注释属性很好，但您还应该写下属性的用途\用途以使事情更清楚。理想情况下，目的应该从名称本身就很明显。

我认为写像'字段被声明为双精度'这样的cmets是没有意义的。 IDE 智能已经完成了使注释变得多余的工作。

另外，考虑使用auto properties 删除样板代码。

【讨论】：

如果你有一个大的代码文件，你还有其他问题。拆分课程或改为部分课程。
更不用说该字段何时不再是双精度，但评论没有更新。评论过时，代码不会。
区域影响可读性是有争议的。它们究竟如何影响可维护性？
@Thomas - 假设您有一个带有区域的大文件，假设您有两个用于两个接口实现的区域，那么您想添加一个私有方法，供两个区域中的代码使用，其中你写吗？那么您可能会创建一个名为“私有方法”的第三个区域。之后，您只需使用 IDE 创建一个新的私有方法或提取一个方法，它就会添加到您的公共方法下方。然后你必须将它移动到私有方法的区域。等等..不是很痛苦吗？
@Unmesh Kondolikar - 您在您所在地区使用的方法显然至关重要。假设您有一个大文件，其中每个方法都包装在一个区域（而不是大型通用部分）中，其中区域名称是方法范围和名称。你为什么问？这样，当您折叠文档时，该方法的 cmets 将与区域一起折叠，而不是作为单独的行（并变灰）。

【解决方案6】：

如果函数很大，我认为使用区域的更好方法是对函数和函数部分进行逻辑分组。我认为对于功能描述摘要就足够了。

【讨论】：

【解决方案7】：

说明痛苦显而易见的评论比没有 cmets 更糟糕。除了给代码添加噪音外，他们还倾向于与他们描述的代码不同步，并最终对代码的作用撒谎。

而不是“获取和设置名字”，如果确实必须在那里发表评论，我可能会将评论更改为“获取或设置员工的名字”之类的内容。

而不是“RegularPay 计算为双倍”，我会......嗯......一个更好的变量名称。 VS 使重命名变量变得如此容易，只需将鼠标悬停在变量上即可轻松查看它是什么，因此最好的文档将是更具描述性形式的代码本身。

至于#regions，如果该区域包含明显不止一种方法，那么明确命名的区域可能会有所帮助。但是，对于单一方法，这不值得付出努力——VS 已经可以随时折叠方法，因此#region 会增加噪音，但不会给您带来任何好处。

【讨论】：

【解决方案8】：

这些 cmets 可用于自动生成代码文档。请咨询您的项目经理是否属于这种情况。

我同意其他人的观点，即评论显而易见的事情绝对是浪费时间。定期工资是双倍的就是这样一种评论。一个示例或其他不立即显现的信息会更有用。例如，“每周固定工资”或“每年固定工资”或“以美分为单位的固定工资”。这些 cmets 是必要的，因为没有人会为变量命名为 RegularPayPerWeekInCentsExcludingOvertimeRatesAndTaxDeductions。

【讨论】：

【解决方案9】：

您所做的评论变量没有任何意义，因为它隐含地表明有效性。

   private double m_dRegularPay;

说明一切

现在对于区域来说，最好是拥有庞大的代码库，并且您可以从逻辑上使占位符说成 handlers、constructors、computation强>等... 对于新进入者来说，它喜欢一本书的索引（有时会很有帮助）

【讨论】：

【解决方案10】：

如果您在类/文件区域中有几千行代码可能会有所帮助

【讨论】：

【解决方案11】：

区域可能永远不应该在函数内部使用或只包含一个函数 - 一个简单的注释或块就足够了。如果你的函数看起来太大，也许你应该考虑重构。如果您的类实现了多个接口，则区域可能围绕接口实现有意义。
一个类可能永远不应该只包含一个区域 - 否则该区域只是类（也许您已经对该类进行了评论或阻止），因此这只是重复信息。
在您的私有变量声明周围放置一个区域 - 这取决于您的编程风格，我将所有私有声明放在类的顶部，并且 99% 的时间当我打开文件时我正在修改函数或属性所以除非我正在创造新的东西，否则没有必要看到它们，所以对我来说，将它们放在一个区域中是有意义的。

可能还有更多，也许这个列表会随着时间的推移而增长。我并不是说要以这种方式使用它们，但如果您要使用它们，请三思而后行并明智地使用它们。

【讨论】：