代码之家 › 专栏 › 技术社区 › Jeffrey Knight

两个C#命名约定:你怎么看?[闭门]

naming-conventions c#

Jeffrey Knight · 技术社区 · 17 年前

C#编码约定我一直带着复杂的感觉练习。我很想听听人们怎么想。他们是:

#2:“匹配属性名称”

#1.在其实例所在的类后面命名实例,camelCased

我使用此作为命名约定的默认设置。当然,也有例外。但是一直使用它 戏剧性地

var dataConnection = new DataConnection();
//not: var dataConn, dbConn, sqlConn, myDbPickOfTheDay etc.

FileInfo fileInfo = new FileInfo();

Timer timer = new Timer(); 

//etc.

DataConnection dbConn = new DataConnection();

我要强调的是,这个惯例如何消除了变量名游戏的痛苦和愤怒。

对我来说,这个惯例是黄金。它还防止了为同一事物稍微调整变量名的可怕做法。

class Person { ...
   public string FirstName { get; set; }

//and then
var person = new Person();
person.FirstName = firstName; //where firstName comes from somewhere else.

非常容易阅读。很无聊。当涉及到维护代码时,无聊是件好事。

然而

(因为没有更好的标题)

下面是一个例子:

public class ShoppingCart { ..
  private Item item;
  public Item Item {  //<---- ?
  get { return this.item; } ...

编译器对此非常满意。事实上,它公开了一个非常好的界面:

//notice how tempting it is to just say "ShoppingCart cart ... "
ShoppingCart shoppingCart = new ShoppingCart();  
shoppingCart.Item = item;

现在,另一种选择是创造性的——您实际上需要为项收集两个好的变量名:公共属性名和私有成员变量名。

 public class ShoppingCart { ..
      private Item cartItem;
      public Item ShoppingCartItem { 
      get { return this.cartItem; } ..
  ///....
  ShoppingCart userShoppingCart = new ShoppingCart();
  userShoppingCart.ShoppingCartItem = userSelection;

我对传统的感觉很强烈,我想我可以接受。

7 回复 | 直到 17 年前

Chad Grant 17 年前

如果你不知道,如果你在乎的话,C#已经有了一个命名标准

http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx

还有,再看看你的惯例。。。这里还有一些建议。

如果我能在6+mos之后再回到您编写的代码时给出任何建议。你会抓挠你的头,试图找出并追踪你的dbConn和fileInfo到底是什么。什么文件?什么数据库?很多应用程序都有几个数据库,这是OrdersDB的数据库连接还是ShoppingCartDB的数据库连接?
类命名应该更具描述性。我们更喜欢购物车而不是购物车。如果每个列表框、下拉列表等都将其集合项命名为“Item”,那么您将与许多名称空间发生冲突,并将被迫使用MyNameSpace.ShoppingCart.Item丢弃代码。

说了这么多。。。即使经过多年的编码,我仍然搞砸了,没有100%的时间遵守规则。我甚至可能使用了FileInfo fi=。。。但这就是为什么我喜欢我的Resharper“Refactor->Rename”命令,而且我经常使用它。

Cuga 17 年前

惯例1可能会令人困惑。如果你有两个 FileInfo

变量名应该是助记的——向临时观察者表明其使用意图。

也许你会对这两种习俗的结合感到最幸福。。。例如,根据本例,sourceFileInfo和targetFileInfo。

bsneeze 17 年前

字符串*, 但是对于那些你不经常使用的东西,特别是那些你只需要其中一个的东西,以及它的功能 在代码中

不管怎样,我就是这么做的。

我会使用一个更具体的名称,比如计时器对象。计时器是用来干什么的?

*即使“字符串”不是关键字。。。

JohnOpincar 17 年前

Caleb Vear 17 年前

我通常会遵循约定#1,尽管对于长类名称,我倾向于使用类的首字母缩写。如果我引用的是同一类型的多个对象,那么我会用一个名称预先挂起类型名称,该名称指示它是哪一个或它的用途。

如果有意义的话,我经常使用约定2。没有什么比您列出的cart.ShopingCartItem示例更糟糕的了,因为它是ShoppingCart的一个属性,所以属性名称的这一部分完全多余。但是,我很可能会将类命名为ShoppingCartItem和属性项。Item是一个有点过于通用的名称,而ShoppingCartItem会告诉您正在使用的是哪种商品。

G S 17 年前

我一直遵守第一公约。不过,如果有两个对象并排出现,我会添加一个附加的限定符。

但是,尽管如此,强制执行这项公约可能会有问题:

在某种情况下 cart 可能是一个很好的名字,一个 ShoppingCart
有时公约可能会完全模糊所申报对象的目的。例如 Window scoreBoard = new Window() Window window = new Window() 这完全隐藏了这个窗口背后的意图。

supercat 13 年前

我非常不喜欢在范围中有多个标识符的概念,这些标识符只在大写/小写的用法上有所不同;如果我有我的druthers,使用标识符的代码将被要求使用与其声明相同的大小写字母组合,但代码既不能在同一范围内声明两个仅因大小写不同的标识符,也不能访问任何与内部范围内的标识符相匹配的标识符(大小写除外)。尽管我所知道的任何语言(当然不是VB或C)都没有强制执行这些规则,但按照这些规则编写的代码可以在区分大小写和不区分大小写的语言之间自由移植,而无需重命名标识符。

因此,我不喜欢这种模式#2。CLS合规性要求将该样式的任何标识符限制为 private 或 internal Trait ,我看不出有什么理由赞成 trait 结束 _trait

至于模式#1,如果类型或方法的全部目的都围绕某个特定类型的单个封装对象进行解析,我更喜欢在字段前面加上前缀 my the . 即使在编译器允许对实例成员和参数使用相同名称的情况下,使用不同的前缀也可以避免在需要另一个前缀时意外使用其中一个前缀。