枚举和匹配属性的C#命名约定 [英] C# naming convention for enum and matching property

查看:105
本文介绍了枚举和匹配属性的C#命名约定的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我经常发现自己实现一个维护某种自己的status属性作为枚举的类:我有一个Status类型的Status枚举和ONE Status属性。我应该如何解决这个名字冲突?

  public class Car 
{
public enum Status
{
关,
开始,
移动
};

状态= Status.Off;

public状态状态// <=====不会编译=====
{
get {return status; }
set {status = value;做一点事(); }
}
}

如果状态枚举对不同类型是常见的,我把它放在课外,问题会解决。但是状态仅适用于Car,因此在类之外声明枚举是没有意义的。



在这种情况下,您使用什么命名约定?



注意:这个问题在这个问题。由于它不是主要的问题,它没有太多的可见性。



编辑:Filip Ekberg建议一个IMO的优秀解决方案具体情况状态。然而,我会很有趣的阅读有关枚举/财产名称不同的解决方案,如Michael Prewecki的回答



EDIT2 (2010年5月):我最喜欢的解决方案是根据Chris S的建议来复制枚举类型名称。根据MS指南,这应该仅用于标志枚举。但是我越来越喜欢它了。我现在也使用它作为常规枚举。

解决方案

我将添加我的1欧元的讨论,但它可能不会添加任何新的。



明显的解决方案是将状态从嵌套的枚举中移出。大多数.NET枚举(除了Windows.Forms命名空间中可能有一些)不是嵌套的,它使得烦人的开发人员使用您的API,必须在该类名前面。



没有提到的一件事就是标签枚举根据MSDN指南应该。= / n> (枚举所谓的国家)是职业,地位是一个名词,这个名词是英语,我们大多数语言从拉丁语中吸收。 Vocative是您为其条件命名的名词,而nominative是动词的主题。



所以换句话说,当汽车正在移动时,这是动词 - 它的状态。但汽车不会熄灭,它的发动机。引擎没有启动(你可能在这里选择了一个例子,所以这可能是无关紧要的)。

  public class Car 
{
VehicleState _vehicleState = VehicleState.Stationary;

public VehicleState VehicleState
{
get {return _vehicleState; }
set {_vehicleState = value;做一点事(); }
}
}

public enum VehicleState
{
固定,空闲,移动
}

状态是一个广义的名词,不是更好地描述它指的是什么状态?像我上面那样



我的视图中的类型示例不涉及读者类型,而是其数据库。如果您正在描述读者的数据库产品,这不一定与读者的类型(例如,读者的类型可能只是向前,缓存等),我更喜欢它。所以

  reader.Database = Databases.Oracle; 

在现实中,这不会发生,因为它们被实现为驱动程序和继承链,而不是使用枚举是为什么上面的线看起来不自然。


I often find myself implementing a class maintaining some kind of own status property as an enum: I have a Status enum and ONE Status property of Status type. How should I solve this name conflict?

public class Car
{
  public enum Status
  {
    Off,
    Starting,
    Moving
  };

  Status status = Status.Off;

  public Status Status // <===== Won't compile =====
  {
    get { return status; }
    set { status = value; DoSomething(); }
  }
}

If the Status enum were common to different types, I'd put it outside the class and the problem would be solved. But Status applies to Car only hence it doesn't make sense to declare the enum outside the class.

What naming convention do you use in this case?

NB: This question was partially debated in comments of an answer of this question. Since it wasn't the main question, it didn't get much visibility.

EDIT: Filip Ekberg suggests an IMO excellent workaround for the specific case of 'Status'. Yet I'd be interesting to read about solutions where the name of the enum/property is different, as in Michael Prewecki's answer.

EDIT2 (May 2010): My favorite solution is to pluralize the enum type name, as suggested by Chris S. According to MS guidelines, this should be used for flag enums only. But I've come to like it more and more. I now use it for regular enums as well.

解决方案

I'll add my 1 euro to the discussion but it's probably not adding anything new.

The obvious solution is to move Status out of being a nested Enum. Most .NET enums (except possibly some in Windows.Forms namespace) aren't nested and it makes it annoying to use for the developer consuming your API, having to prefix the classname.

One thing that hasn't been mentioned is that flag enums according to MSDN guidelines should be pluralized nouns which you probably already know (Status is a simple enum so singular nouns should be used).

State (enum called States) is the vocative, "Status" is the nominative of a noun that the English like most of our language absorbed from Latin. Vocative is what you name a noun for its condition and nominative is the subject of the verb.

So in other words when the car is moving, that's the verb - moving is its status. But the car doesn't go off, its engine does. Nor does it start, the engine does (you probably picked an example here so this might be irrelevant).

public class Car
{
  VehicleState _vehicleState= VehicleState.Stationary;

  public VehicleState VehicleState 
  {
    get { return _vehicleState; }
    set { _vehicleState = value; DoSomething(); }
  }
}

public enum VehicleState
{
    Stationary, Idle, Moving
}

State is such a generalised noun wouldn't it be better to describe what state it is referring to? Like I did above

The type example also in my view doesn't refer to the reader type, but its database. I would prefer it if you were describing the reader's database product which isn't necessarily relevant to the type of reader (e.g. the type of reader might be forward only, cached and so on). So

reader.Database = Databases.Oracle;

In reality this never happens as they're implemented as drivers and an inheritance chain instead of using enums which is why the line above doesn't look natural.

这篇关于枚举和匹配属性的C#命名约定的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆