This is why we have so many bugs in code today. The biggest advantage of a property is to allow you to check the incomming value bedore you assign it to your member. Not writing error code and value checking when you write your class is being lazy and being a poor programmer. If everyone took the time to do this write code would be more robust and a lot less buggie. These are simple things that you should do for EVERY class and EVERY member. As the power of computers get more and more powerful people seem to get lazier and lazier about writing good and complete code.

I have worked in the industry for over 15 years, from what I have seen if you don't put in error checking when you create a function or class people rarely go back and do it until a bug shows up to bite them. This is one of the reasons that buffer overflows still exist, they could have been stomped out a long time ago by a little value and error checking.

theTroll

Quote:Original post by TheTroll
This is why we have so many bugs in code today. The biggest advantage of a property is to allow you to check the incomming value bedore you assign it to your member. Not writing error code and value checking when you write your class is being lazy and being a poor programmer. If everyone took the time to do this write code would be more robust and a lot less buggie. These are simple things that you should do for EVERY class and EVERY member. As the power of computers get more and more powerful people seem to get lazier and lazier about writing good and complete code.

I have worked in the industry for over 15 years, from what I have seen if you don't put in error checking when you create a function or class people rarely go back and do it until a bug shows up to bite them. This is one of the reasons that buffer overflows still exist, they could have been stomped out a long time ago by a little value and error checking.

theTroll

That contradicts what you previously said, when at the same time stating the obvious.
Yes you should always use properties. Always. Seeing a publically visible field in a class gives you pause to question the quality of the code.
And there is nothing wrong with having a property that simply wraps a field. As has been mentioned, this makes serialization a lot easier (think xml serializer), it allows the value to be visible in a property grid, it causes no performance loss, looks neater, and above all in the event you do need to limit the value range *or* change the underlying data representation, then there is no need to change the class externally.

as for:

Quote:
This is one of the reasons that buffer overflows still exist, they could have been stomped out a long time ago by a little value and error checking.

Buffer overflows are a moot point in .net, however in C++ the vast majority of the time they are caused by a method taking in a array pointer instead of a vector/list/what-have-you. Those sorts of things are very difficult to track down, and pretty much impossible to error check.
The other main time I've dealt with buffer overflows is when error values are ignored. A function returns -1 to signal an error, yet the value still gets used as an array index. Naturally managed exception's helps out enormously here.

And last thing I'll say is it's not possible to forsee every possible use of a class/property at the time of creation. It simply can't be done.

RipTom you are missing the point. What I said was if you are going to just wrap a member with a property then you might was well just make the member public. By the way you should not do that because it breaks the rules of encapsilation, as does a property that just wraps a member.

The point I am trying to make and you seem to either not get or just refuse to see is that properties are the first line of defense for bad data. Lets say I am doing some basic graphics stuff, was a a POINT class, with just an x and y. Well we would not want a negative x or x, and we also would not want a x or y that is greater then the display max. A property can check the value before you write it and make sure that it is valid.

Should you always do this, YES. Every value coming into your program should have some type of checking on it. Why? Because then you can have anyone use your class and know that it will never have a value that can not be used. When you are writing code, at least in the buisness world, you will be working with others, they will use your class and might not be as careful as you would. You should always write your classes to protect themselves. Does it take more work and is about the most boring thing in the world to do, sure is, but if you do it you are writing much more robust code.

No you can not see every possible condition your class may face, but that does not mean that you should not do what you can to protect it. It is not hard to take a look at your class and figure out what will break it and test to make sure that your members are not invalid.

TheTroll

Imagine you want to debug some code.

You set a breakpoint into the Getter/Setter of a property that simply wraps a field.

What would you do when you just make the field public? Make it a property and after debuging change it back to a field?


And to add one thing, properties might not look very different in your code, but they are a big difference when it comes to reflection. Imagine you want to write an own serializer class like the XmlSerializer, for CSV files for example. It is a lot easier to limit it on properties than to use both, properties and fields.

Take a close look at the .NET framework. It is a very well formed library, especially when you look at the Windows.Forms. Do you see any public fields? Is it because of bad programmers? Or is it your turn to change your mind?

I think the troll's saying the same thing we are except in a way that was easy to misinterpret.
"With the way you are doing things you might as well make _state public."
is actually analog to
"If you're starting to like James Blunt, you might as well kill yourself"
And we go "No, suicide is never a good solution!"

If you make a public property that does nothing but set the member you have not provided encapsulation, you have just made your member public. That is the point that I am trying to make. There is no difference between a public member and a public property that just does a set. You are doing the same thing.

Some of you may be wondering why this is such a big thing to me. I have spend thousands of hours fixing bugs because people did not add basic error checking in thier member sets. What would have taken 5 minutes at design and code time can take hours when debugging.

Now there is no reason that you have to take my advice, but in the end someone is going to pay for it.

theTroll

This is ridiculous

You suggest not using properties when you have nothing to validate and just set the member.

And the reason you give to do this is: people don't do good validation.


It's like:
If you write a program in C++ and you don't use polymorphism you should stick with C. Because people write bad code in C++.

Once again people completely miss the point. I am not saying don't use properties. I am saying do some basic error checking. Wrapping a member set does nothing for you, nothing at all, and yes there will be some people saying it helps with serialization and other things but you can do those without wrapping the member. Your set property is the first line of defense to write some robust code. If you are not using it then you are really missing the point. Using something just becuase you can without adding benifits to your code is just a waste of typing. Sure properties look pretty, but they are there to give you the ability to protect yourself, not just to look pretty.

Now I am going to get blamed for "Trolling" but what part of this is so hard to understand? Is there a reason that I am missing that people do not want to write robust code? And before someone starts, yes you can find cases in which there can be not error checking, but these are the exception not the rule.

theTroll