Automatic Properties (And Why You Should Avoid Them)
Ah yes, automatic properties. Insn’t it great that you don’t have to do all of that extra typing now? (Well, you wouldn’t be doing it anyways with ReSharper, but that’s besides the point.) For some reason, they’ve never sat well with me; they just seem like a pretty useless feature and, not only that, I think it severely impacts readability.
Quick, are these members in a class, an abstract class, or an interface?
|
1 2 3 4 5 |
<font face="Lucida Console"><font color="#0000ff">int </font><font color="#000000">Id { get; set; }</font> <font color="#0000ff">string </font><font color="#000000">FirstName { get; set; }</font> <font color="#0000ff">string </font><font color="#000000">LastName { get; set; }</font></font> |
Can’t tell! Perhaps you code at a leisurely pace, but when I’m in the zone, I’m flying around my desktop, flipping through tabs like crazy, ALT-TABbing between windows, and typing like a madman. It’s happened to me more than once where I’ve been working in a file, trying to add some logic to a getter and getting weird errors only to realize that I was working in the interface or abstract class instead of the concrete class. Of course I don’t normally write many non-public properties, but it’s easy to make the mistake of missing the access modifier if you’re working furiously and tabbing back and forth, especially if the file is long (so that you can see the class/interface declaration at the top of your file).
Look again:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
<font face="Lucida console"><font color="#0000ff">public interface </font><font color="#000000">IEmployee</font> <font color="#000000">{</font> <font color="#0000ff">int </font><font color="#000000">Id { get; set; }</font> <font color="#0000ff">string </font><font color="#000000">FirstName { get; set; }</font> <font color="#0000ff">string </font><font color="#000000">LastName { get; set; }</font> <font color="#000000">}</font> <font color="#0000ff">public class </font><font color="#000000">Employee</font> <font color="#000000">{</font> <font color="#0000ff">int </font><font color="#000000">Id { get; set; }</font> <font color="#0000ff">string </font><font color="#000000">FirstName { get; set; }</font> <font color="#0000ff">string </font><font color="#000000">LastName { get; set; }</font> <font color="#000000">}</font> <font color="#0000ff">public abstract class </font><font color="#000000">AbstractEmployee</font> <font color="#000000">{</font> <font color="#0000ff">int </font><font color="#000000">Id { get; set; }</font> <font color="#0000ff">string </font><font color="#000000">FirstName { get; set; }</font> <font color="#0000ff">string </font><font color="#000000">LastName { get; set; }</font> <font color="#000000">}</font></font> |
It’s even more confusing when you’re working within an abstract class and there’s implementation mixed in. Not only that, it looks like a complete mess as soon as you have to add custom logic to the getter or setter of a property (and add a backing field); it just looks so…untidy (but that’s just me; I like to keep things looking consistent). I’m also going to stretch a bit and postulate that it may also encourage breaking sound design in scenarios where junior devs don’t know any better since they won’t think to use a private field when the situation calls for one (just out of laziness).
I get that it’s a bit more work (yeah, maybe my opinion would be different if I had to type them out all the time, too – but I don’t :P), but seriously, if you’re worried about productivity, then I really have to ask why you haven’t installed ReSharper yet (I’ve been using it since 2.0 and can’t imagine developing without it). It’s easy to mistake one for the other if you’re just flipping through tabs really fast. I’ve sworn off using them and I’ve been sticking to my guns on this.
There are three general arguments that I hear, from time to time, from the opposition:
- Too many keystrokes, man! With R#, you simply define all of your private fields and then ALT+INS and in less than 5 or 6 keystrokes, you’ve generated all of your properties. I would say even less keystrokes than using automatic properties since it’s way easier to just write the private field and generate it using R#. If you’re worried about productivity and keystrokes and you’re not using R#, then what the heck are you waiting for?
- Too much clutter, takes up too much space! If that’s the case, just surround it in a region and don’t look at it. I mean, if you really think about it, using KNF instead of Allman style bracing throughout your codebase would probably reduce whitespace clutter and raw LOC and yet…
- They make the assembly heavier! Blah! Not true! Automatic properties are a compiler trick. They’re still there, just uglier and less readable (in the event that you have to extract code from an assembly (and I have – accidentally deleted some source, but still had the assembly in GAC!)). In this case, the compiler generates the following fields:
<FirstName>k__BackingField
<Id>k__BackingField
<LastName>k__BackingField
Depending on the project, there may also be unforseen design scenarios where you may want to get/set a private field by reflection to bypass logic implemented in a property (I dunno, maybe in a serialization scenario?).
So my take? Just don’t use them, dude!
Update: To clarify, 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 or even switch bracing styles.
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 file 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. There is no benefit except to save a few keystrokes for the author, but in that case, even more keystrokes can be saved using R# and explicit backing fields.
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".
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?
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.
I’m sorry – but this is absolute rubbish.