5

考虑以下不符合 CLS 的代码(仅区分大小写):

protected String username;

public String Username { get { return username;} set { username = value; } }

所以我把它改成:

protected String _username;

public String Username { get { return _username;} set { _username = value; } }

这也不符合 CLS(具有前导下划线)。

成员/属性是否有任何不违反 cls 合规性的通用命名方案

4

4 回答 4

5

与其公开支持字段,不如使您的属性虚拟化,以便继承者可以覆盖该功能而无需公开支持字段的实现。

private String username;

public virtual String Username { get { return username;} set { username = value; } }

继承人不必知道您的类实现的任何内容。

请参阅公开受保护字段的最佳方式

于 2011-11-27T00:03:48.223 回答
2

这套规则适用于 Visual Basic,但对于 C# 应该有类似的一套:

Visual Basic 中的元素名称必须遵守以下规则:

它必须以字母字符或下划线 (_) 开头。

它只能包含字母字符、十进制数字和下划线。

如果它以下划线开头,则它必须包含至少一个字母字符或十进制数字。

它的长度不得超过 1023 个字符。

但是,以下内容也适用:

以下划线 (_) 开头的元素名称不是公共语言规范 (CLS) 的一部分,因此符合 CLS 的代码不能使用定义此类名称的组件。但是,元素名称中任何其他位置的下划线都符合 CLS。

以上来自MSDN 文档

这是MSDN 上公共语言规范文档的链接,该文档又引用了 CLS 命名约定的最终仲裁者:Unicode 标准 3.0 技术报告 15 的附件 7

于 2011-11-27T00:05:23.230 回答
1

MFC 来救场。只需使用旧的 m_ 前缀:

private string m_Username;
public string Username ...
于 2011-11-27T05:55:27.033 回答
0

你想用这个来达到什么目的?

public String Username {get; protected set};

或者

private String _username;

protected void setUserName(String argUsername);
{
  if (_username != Username) // an overload of String.Compare would be better here
  {
    _username = value;
    // Do the stuff you have to do because username has changed
  }
}

public String Username {get {return _username;} protected set {setUsername(value);}}

按照您的方式,要获得 CLS 合规性,您必须将 pulic 和 prtectred 版本称为不同的名称,这会让人感到困惑。

于 2011-11-27T00:28:49.907 回答