I've got some questions regarding Automatic properties! :)
Basically, we have had a reviewed 'Coding Standards' document for the place I work and these are now banned, I've tried getting these unbanned saying that they quicker to write, easiest to maintain and make development much cleaner..
But that has been dismissed on the grounds that there are issues with automatic properties in enterprise development - they cant remember what they are but they suspect its down to performance or threading. Does anyone know if this is true? or do you know anything I could put forward for another argument :)
cheers.
Absolute nonsense, it's just syntactic sugar and will compile into the same thing eventually if they think the "right" way is manual backing fields...
Performance and threading issues do not stem from auto-properties, properties or any other construct in C# programming. They stem from the minds of the people designing the system and likely the same people enforcing this ban...
An argument would be to produce proof of said issues, if no proof materialises then your argument to continue using them stands. You could also go down the "reduced productivity" route.
I'm guessing someone doesn't like the way they look in the code, and unfortunately has the power to stop them being used.
As for them being safe in enterprise-scale applications: I have worked on a few and have never seen a defect come through that was caused by the use of a stock auto-property or stock property. Plenty from abusing properties, but nothing from the most basic usage.
<>__PropertyName
and that's what gets used as an XML tag. Unless you run your debugging sessions where you catch exceptions as soon as they're thrown (rather than if they're unhandled) you'll likely never have an issue with them. - Agent_9191
XmlSerializer
type? I had no exceptions and a nicely formatted XML document with my auto-properties in it. However, this makes sense to me as the backing fields should be private. Serializers that access the private fields, as you say, may have problems if they don't like the naming. - Adam Houldsworth
You could compare the resulting MSIL (which is obtainable through ildasm.exe [1]), which will show that auto-implemented properties compile to almost the same bytecode as manually created properties.
The following code:
class AutoProperties
{
public String AutoName { get; set; }
private String _manualName;
public String ManualName
{
get { return _manualName; }
set { _manualName = value; }
}
}
Will create (almost) the same variables and methods in MSIL:
<AutoName>k__BackingField: private string
_manualName : private string
get_AutoName : string()
get_ManualName : string()
set_AutoName : void(string)
set_ManualName : void(string)
AutoName : instace string()
ManualName : instace string()
[1] http://msdn.microsoft.com/en-us/library/f7dy01k1%28v=vs.80%29.aspxThey are safe, but can be abused. For a readonly property that is only set once in the constructor, I prefer a property with a readonly
backing field over public SomeType MyPrperty { get; private set}
.
But of course, that's no reason to completely ban automatic properties.
The only reason to avoid autoproperties is if you are using [Serializable] objects as attributes for serialization can only be added to fields and not properties. This is important if you want to allow different versions of objects to be used by different code versions.
http://msdn.microsoft.com/en-us/library/ms229752(v=vs.80).aspx
Automatic properties are just syntactic sugar. In the background, the compiler will create regular backing fields for you (can easily be verified with .NET Reflector or any other IL disassembler).
I cannot think about any possible issue with automatic properties. When you inspect the generated IL you will notice that all the compiler does is to generate a backing field and get
and set
methods.
There is no danger in it.
Automatic properties are totally safe for enterprise (or casual software develoment). They are expanded by the compiler to a property with a getter and setter backed by a field, hence the perform in exactly the same way as the more manual / verbose property.
set{_backingField=value;}
as code smell as well: blog.ploeh.dk/2011/05/26/CodeSmellAutomaticProperty.aspx - Daniel Hilgarth