使用私有自动属性而不是简单变量来实现编程标准
在与同行的讨论中，有人提出我们应该考虑对所有类级别变量使用自动属性......包括私有变量。
因此，除了像这样的公共属性之外：
public int MyProperty1 { get; set; }
我们的私有类级变量看起来像这样：
private int MyProperty2 { get; set; }
而不是：
private int _myProperty2;
我对为什么有人想要这样做持观望态度，但我无法决定我是否不愿意接受这个是因为我自己对如何按照我已经使用了 10 年的相同编程标准和命名约定编写代码进行了内部洗脑，或者因为我以前从未见过这种情况（出于某种原因）。
我意识到这是需要输入的额外代码，但说实话，在使用自动属性时，由于“prop”和“propg”片段，我认为我从未输入过它，因此设置起来非常简单创建一个新的代码片段来创建一个私有自动属性，这样额外的代码就不会太困扰我，因为我从来不需要输入它。
除了我的潜意识中的审美之外，使用完全私人的汽车财产是否会导致任何问题？有什么充分的理由这样做或不这样做吗？我每天在 stackoverflow、codeplex、codeproject 等上看到很多代码，但从未见过有人使用这个标准......有什么原因吗？
In a discussion with a peer, it was brought up that we should consider using auto properties for all class level variables... including private ones.
So in addition to a public property like so:
public int MyProperty1 { get; set; }
Our private class-level variables would look like this:
private int MyProperty2 { get; set; }
Instead of:
private int _myProperty2;
I'm on the fence about why someone would want to do this but I can't decide if my reluctance to accept this is because of my own internal brainwashing with how I write my code to the same programming standards and naming conventions I've used for 10 years or because I've never seen this before (for a reason).
I realize it's extra code to type but to be honest, when using auto-properties, I don't think I've ever typed it out due to the 'prop' and 'propg' snippets so it'd be very simple to set up a new snippet to create a private auto property so the extra code doesn't bother me too much since I never have to type it.
Other than aesthetics which may just be my subconscious, are there any issues that could result from using fully private auto properties? Are there any good reasons to do this or not to do it? I've seen a lot of code in my day on stackoverflow, codeplex, codeproject, etc. and I've never seen anyone use this standard.... is there a reason why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在我看来，私人汽车财产完全没有意义。私有自动属性提供哪些值是普通字段不能提供的？
（当自动属性只是部分私有时（例如，带有私有 setter 的公共/受保护 getter），或者当您使用私有非自动属性来包装其他属性时，情况会有所不同围绕 getter/setter 的代码。）
Private auto-properties are completely pointless, in my opinion. What value does a private auto-property provide that a plain field doesn't?
(It's different when the auto-property is only partially private -- eg, a public/protected getter with a private setter -- or when you use a private non-automatic property to enable you to wrap additional code around the getter/setter.)
这没有多大意义。
我可以想到一个“好处”：
但坦率地说，您的类不应该变得太大，以至于这很有用。
您的属性不能用作
ref或out参数的参数。This does not make too much sense.
I can think of a 'benefit':
but frankly your classes should not become so big that this is useful.
Your properties won't work as arguments to
reforoutparameters.它对私人的用处不如对公众的有用。
假设您采用了自动私有属性，然后在其中构建了一些逻辑（能够在不破坏任何内容的情况下做到这一点是自动道具的全部要点）...
这将需要您为要包装的属性创建一个私有支持成员。
因此，现在您有两种不同的私有方法（成员和属性）来做同样的事情，尽管其中一种具有隐藏的副作用（属性），并且您现在还遇到了确保类中的其他方法无法访问的问题直接那个成员。
最终比从一开始就使用私人成员更令人头疼。
It's not nearly as useful for privates as for publics.
Suppose you took your automatic private property and later built some logic into it (being able to do that without breaking anything is the whole point of auto props)...
This would require you to create a private backing member for the property to wrap.
So now you've got two different private ways (member and property) of doing the same thing though one has hidden side effects (the property) and you've now also got the problem of ensuring none of your other methods in the class access that member directly.
Ends up being much more of a headache than just using a private member from the beginning.
此策略将为您提供一个机会，将任何未来的更改放入之前自动生成的私有属性中，而不会影响获取或设置您的私有属性的任何其他代码。我个人并没有使用这么多，但在处理可能发生变化的情况下它可能会很有用。它还标准化了代码，以便始终通过属性访问字段。没有真正的缺点，但在大多数情况下也没有多大好处。我认为在大多数情况下，风格确实是最大的驱动力。
What this strategy will do for you is provide an opportunity to put any future changes into the previously autogenerated private property without affecting any of the other code that gets or sets your private property. I personally haven't used this much but it can be beneficial in a case where changes to handling may occur. It also standardizes the code so that fields are always accessed by properties. There are no real drawbacks but it is not really much benefit in most situations either. I think style is really the biggest driver in most situations.
所以你可以直接使用
public int MyProperty1 { get;放;此外，它减少了您的代码行和快速实施
So you can directly go with
public int MyProperty1 { get; set; }Moreover it reduces your line of code and Quick Implementation
我是 KISS 的坚定信徒。当字段可以使用时，我从不使用属性，并且我认为没有什么理由使用私有访问器（get）。
属性的主要目的是成为私有数据的公共访问器。因此，对于除了设置或获取值之外不执行任何操作的简单属性，私有访问器和设置器没有任何意义。
话虽如此，当您需要在读取数据时转换数据时，或者当您需要在更新值时执行副作用时，您应该使用字段。改变你的价值观会引发事件吗？那么字段是理所当然的。但是，这不是您用 {get; 声明的自动字段。放;}
I'm a firm believer in KISS. I never use a property when a field will do, and I see very little reason to use private accessors (get).
The primary purpose of a property is to be a public accessor for private data. So for simple propreties that do nothing but set or get a value, private accessors and setters make no sense.
Having said that, when you need to transform the data as it's being read, or when you need to perform a side effect when updating the value, you should use a field. Does changing your value raise an event? Then a field is a no-brainer. But then, that's not an auto field that you're declaring with {get; set;}