Comments on: Automatic Properties (And Why You Should Avoid Them)

By: none

none — Mon, 27 Jul 2009 08:27:14 +0000

I’m sorry – but this is absolute rubbish.

By: Chuck

Chuck — Mon, 27 Jul 2009 00:50:39 +0000

Well, I’m not saying I can’t tell (of course I can) and my classes are rarely _huge_, but I *do* zip around my open files pretty fast. One thing that I’ve noticed is that when I do that, I’m not looking at the actual text, I’m looking more for the *structure* of the text in the code file. When I see explicit getters and setters with backing fields, I know I’m in a concrete class.

McConnell has a whole section of Code Complete which discusses "code shape" and how it affects readability (see chapter 31). I think this is along the same veins. You gain *NOTHING* by using automatic properties, but you sacrifice readability and clarity. I don’t think that the argument of "saving a couple lines" is a valid one since you can just as easily collapse those into regions and save many more lines.

As McConnell writes:

"Making the code look pretty is worth something, but it’s worth less than showing the code’s structure. If one technique show the structure better and another looks better, use the one that shows the structure better."

"The smaller part of the job of programming is writing a program so that the computer can read it; the larger part is writing it so that other humans can read it."

My belief is that using backing fields shows the _structure_ of the class better than using automatic properties (which was my point in the blog post). Automatic properties are a convenience for the author, but it sacrifices structural cues to the purpose and usage of a given code file, IMO.

By: Pragmatic

Pragmatic — Sun, 26 Jul 2009 20:40:57 +0000

1. Automatic properties are a double edged sword. They are very useful in reducing boilerplate, however can cause some trouble at advanced edge cases. For example, I once wanted to add some validation to a property, and had to change it to a normal property. So far so good, the problem was that it meant changing the name of the backing field, therefore making the new version no longer serialization-compatible with the previous one.

Still, I would not give up automatic properties, and another large project they have enabled me to use a design that simply wouldn’t be feasible otherwise.

2. The above said, your argument in this post is just plain silly. Your main argument is that you can’t tell the nature of the class\interface you’re in by just looking at the syntax of an automatic property. Can’t imagine why that bothers you so much, but if it does, you can just change the auto-snippet that comes with Visual Studio to add a comment at the end of each automatic property.

It would now look like this:

string FirstName { get; set; } /*This is an automatic property, knucklehead*/

Problem solved.

3. I’m not sure how bracing style has anything to do with the topic, but I do insist on using KNF bracing, it saves me from constantly staring at 30% blank lines.

4. To people who think regular properties clutter their code, you say to hide it away with regions and not look at it. That’s quite funny, coming from a guy who just posted an entire rant about how he doesn’t quite like what the syntax of automatic properties looks like. Why don’t YOU just surround your automatic properties with regions and not look at it?

By: Craig

Craig — Sun, 26 Jul 2009 19:37:52 +0000

I would hope that your classes are not so large that you get lost in them and forget where you are working. I’m sorry, but I have never had this issue, and quite frankly think it’s a poor reason to dismiss a feature.

That being said, I’m all ears if you can give a better reason for not using a feature other than "It feels untidy".