属性类型的命名约定
如果您在地址上定义了“人员属性”，则
public class Address
{
public int AdressId {get; set;}
public Person AddressesPerson {get;set;}
public string FullAddress {get; set;}
}
命名其他类型的属性的正确约定是什么（如果有）？
If you a have Person Property on Address defined like
public class Address
{
public int AdressId {get; set;}
public Person AddressesPerson {get;set;}
public string FullAddress {get; set;}
}
What is the proper conventions, if any, for naming a property of another type?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不认为有一个硬性规定，但一般来说，我喜欢尽可能遵守以下准则：
Owner可能是合适的属性名称，因为Person拥有特定的Address。I don't think there's a hard and fast rule, but generally I like to stick to the following guidelines as much as possible:
Ownermight be an appropriate property name, since aPersonowns a particularAddress.根据属性的语义来命名。坦率地说，在地址上拥有 Person 属性是很奇怪的 - 通常情况恰恰相反。这里的人是什么意思？地址和人之间有什么关联？例如，您可能有
Owner或Resident- 但在其他情况下这是不合适的。Name the property according to its semantic meaning. Frankly it's quite odd to have a Person property on an address - it would normally be the other way round. What's the meaning of the person here? What's the association between the address and the person? You might have
OwnerorResident, for example - but in other cases that wouldn't be appropriate.我会根据两种类型之间的关系来命名财产，例如居民、所有者等。
I would name the property from the relationship between the two types, e.g. Resident, Owner etc.
选择一个并坚持下去。
在您的具体情况下，我想知道为什么一个人从属于一个地址，而不是相反，但基本上只是选择您想要使用的一个并继续使用它。只要它不是完全不可读或违反某种团队编码指南的东西，您可能就很好。
Pick one and stick with it.
In your specific case, I wonder why a person is subordinate to an Address, instead of the other way around, but basically just pick the one you want to use and keep using it. As long as it's not something completely unreadable or against some kind of Team coding guidelines, you're probably good.