Coding Standard Question
-
that's what I thought as I'm in Orcas. I'll just stick to my usual style. Thanks for everyone's feedback
rather have something you don't need, than need something you don't have
-
donsolms wrote:
Which is better according to coding standard for c#? this: public bool isDraggable { get { return _draggable; } set { _draggable = value; } } or this: public bool isDraggable{ get; set; } without using private members? Or is this a matter of personal choice?
Hi, For Orcas, I thought that these were essentially identical, that the compiler would generate some private fields for you. Perhaps I've missed something - I'm living in a .NET 2.0 world - but, that was my understanding of it. I suspect someone will correct me if I'm wrong. Hope that helps.
It isn't enough to do well in life. One must do good when and where one can. Otherwise, what's the point?
Matthew Cuba wrote:
the compiler would generate some private fields
Ew, I wouldn't want that. Having the compiler create a default constructor is one thing, but generating fields? Yuck!
-
donsolms wrote:
Which is better according to coding standard for c#? this: public bool isDraggable { get { return _draggable; } set { _draggable = value; } } or this: public bool isDraggable{ get; set; } without using private members? Or is this a matter of personal choice?
Hi, For Orcas, I thought that these were essentially identical, that the compiler would generate some private fields for you. Perhaps I've missed something - I'm living in a .NET 2.0 world - but, that was my understanding of it. I suspect someone will correct me if I'm wrong. Hope that helps.
It isn't enough to do well in life. One must do good when and where one can. Otherwise, what's the point?
Matthew Cuba wrote:
For Orcas, I thought that these were essentially identical
That is true, .NET 3.5 introduced the idea of automatic properties. The only drawback is that it doesn't provide any way to do validation and you must always have both a get and a set.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
Which is better according to coding standard for c#? this:
public bool isDraggable { get { return _draggable; } set { _draggable = value; } }or this:public bool isDraggable{ get; set; }without using private members? Or is this a matter of personal choice?rather have something you don't need, than need something you don't have
My preference would almost always be the first example. The second example is good if you can guarantee that you will never need to do anything more advanced in the property getter or setter. Both of thees example are equivalent, with the second one allowing the compiler to automatically generate the backing variable. I have used both styles, and generally only use the second for very simple classes and structs. For future reference, you should be clear that you are referring to a .NET 3.5 (Orcas) feature, especially with this question as the second example is also the way a property is defined in an interface.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
My preference would almost always be the first example. The second example is good if you can guarantee that you will never need to do anything more advanced in the property getter or setter. Both of thees example are equivalent, with the second one allowing the compiler to automatically generate the backing variable. I have used both styles, and generally only use the second for very simple classes and structs. For future reference, you should be clear that you are referring to a .NET 3.5 (Orcas) feature, especially with this question as the second example is also the way a property is defined in an interface.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
Scott Dorman wrote:
with the second one allowing the compiler to automatically generate the backing variable.
<rant> Man, that's gotta be about the dumbest thing I've heard Microsoft do recently. Does that mean even the class itself is required to use the property? I hope the calls will be inlined. </rant> On the other hand, maybe they're trying to entice more VB programmers to C#, that's a worthwhile goal.
-
Scott Dorman wrote:
with the second one allowing the compiler to automatically generate the backing variable.
<rant> Man, that's gotta be about the dumbest thing I've heard Microsoft do recently. Does that mean even the class itself is required to use the property? I hope the calls will be inlined. </rant> On the other hand, maybe they're trying to entice more VB programmers to C#, that's a worthwhile goal.
PIEBALDconsult wrote:
maybe they're trying to entice more VB programmers to C#, that's a worthwhile goal
That's polluting the gene pool - we wouldn't want that.
Deja View - the feeling that you've seen this post before.
-
donsolms wrote:
it does, but you can use it in a normal class as well
You can - but it doesn't actually accomplish much.
Deja View - the feeling that you've seen this post before.
You are wrong. What it does is to implicitely create a private field which is accessed (I think this was introduced with .Net 3.5). Up to there you could just create a public field instead but this one has the advantage that you can replace it with a real property/field pair at any time without having to change anything on accessing classes. Robert
-
My preference would almost always be the first example. The second example is good if you can guarantee that you will never need to do anything more advanced in the property getter or setter. Both of thees example are equivalent, with the second one allowing the compiler to automatically generate the backing variable. I have used both styles, and generally only use the second for very simple classes and structs. For future reference, you should be clear that you are referring to a .NET 3.5 (Orcas) feature, especially with this question as the second example is also the way a property is defined in an interface.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
Scott Dorman wrote:
The second example is good if you can guarantee that you will never need to do anything more advanced in the property getter or setter.
Well you can change it to a "real" property and field combo any time you want. Accessing classes won't notice the difference. Robert
-
You are wrong. What it does is to implicitely create a private field which is accessed (I think this was introduced with .Net 3.5). Up to there you could just create a public field instead but this one has the advantage that you can replace it with a real property/field pair at any time without having to change anything on accessing classes. Robert
Robert Rohde wrote:
You are wrong. What it does is to implicitely create a private field which is accessed (I think this was introduced with .Net 3.5). Up to there you could just create a public field instead but this one has the advantage that you can replace it with a real property/field pair at any time without having to change anything on accessing classes.
Only from .NET 3.5 onwards. At the time of replying to this post, we had no idea that the poster was using Orcas and not asking questions about current versions of .Net.
Deja View - the feeling that you've seen this post before.
-
Scott Dorman wrote:
with the second one allowing the compiler to automatically generate the backing variable.
<rant> Man, that's gotta be about the dumbest thing I've heard Microsoft do recently. Does that mean even the class itself is required to use the property? I hope the calls will be inlined. </rant> On the other hand, maybe they're trying to entice more VB programmers to C#, that's a worthwhile goal.
In theory, I agree with you. In practice, however, I don't mainly because there are already a lot of cases where Microsoft is generating code for you. If you use any .NET remoting or serialization, the JIT is compiling an entire assembly on-the-fly at runtime for you; the using statement, ~T (finalizer), anonymous delegates, and generics all generate code at compile time on your behalf. There really isn't a way around it anymore...if you use .NET at somepoint Microsoft is generating code for you either at compile time, run time, or both.
PIEBALDconsult wrote:
Does that mean even the class itself is required to use the property?
I'm not sure what you mean by this. In the class, when you want to reference the property you use it just like you would any other property. The only difference is that there isn't an excplict backing variable that you could access instead, so you always use the property.
PIEBALDconsult wrote:
I hope the calls will be inlined.
How would this matter? I don't believe they are, since this is really just more syntatic sugar, the compiler treats them just like it would any other property.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
Scott Dorman wrote:
The second example is good if you can guarantee that you will never need to do anything more advanced in the property getter or setter.
Well you can change it to a "real" property and field combo any time you want. Accessing classes won't notice the difference. Robert
Robert Rohde wrote:
Well you can change it to a "real" property and field combo any time you want. Accessing classes won't notice the difference.
Yes, you can change it to a "real" property anytime you want without affecting the callers. My only issue with automatic properties is that it forces both a get and a set on the property and they must both be at the same access level.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
Robert Rohde wrote:
Well you can change it to a "real" property and field combo any time you want. Accessing classes won't notice the difference.
Yes, you can change it to a "real" property anytime you want without affecting the callers. My only issue with automatic properties is that it forces both a get and a set on the property and they must both be at the same access level.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
Another issue is newbies who learn the lazy way and never learn the "better" way, and therefore wind up giving more access to their classes because they don't know any better.