是否有充分的理由在#region中包装单个属性?

前端之家收集整理的这篇文章主要介绍了是否有充分的理由在#region中包装单个属性?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我最近继承了一些C#代码,其中文件中的几乎每个项目都包含在一个单独的#region / #endregion块中 – 每个类,每个函数,每个属性,每个枚举,但不包括字段.这些中的每一个又被包裹在“分组”#region中(例如“属性”,“构造函数”,“方法”等).单个函数有多个重载具有不同的参数列表,但它们每个都包含在具有相同名称的单个区域中,而不是包含所有三个重载的单个区域.编写此代码的人不再与公司合作,并且从源代码控制的历史记录中可以看出,这些代码存在于初始提交中,并且随着新属性方法添加,该实践将继续贯穿代码的后续版本.

知道为什么要这样做吗?一些想法:

>过度热心的VS功能(或代码清理工具)自动插入#region / #endregion块,作者没有删除它们.
>有一个IDE折叠区域但不折叠函数,所以这是获得语法折叠所必需的.
>这是一种在实现代码之前删除代码结构的方法.

编辑:我选择了Jonathan的答案,因为它为人们可能选择这样做提供了一个新的理由.谢谢你的讨论!

解决方法

当涉及到非自动实现的属性时,它可以使代码更容易导航.例如,下面的许多代码(在区域内)只是赘肉 – 它总是看起来一样(因为属性实际上不应该有副作用).有一行说“Property – Name”可以更好地导航.
#region Property - Name
private string _name;
/// <summary>
/// Gets or sets the name of the customer.
/// </summary>
/// <remarks>
/// This should always be the full name of the customer in the format {First Name} {Last Name}.
/// </remarks>
/// <example>
/// customer.Name = "Joe Bloggs";
/// </example>
/// <seealso cref="Customer"/>
/// <value>
/// The name of the customer.
/// </value>
public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}
#endregion

但是,就“成员类型”(方法,属性,构造函数,字段)而言,我觉得它使代码更难以导航;然而,其他人觉得它更容易.

最后,它是一个编码标准和宗教.如果您不喜欢它,请不要将其用于您的个人项目.如果您因标准要求使用它,请使用它.

猜你在找的C#相关文章