This seems rather verbose, particularly since it requires six lines to declare an input property that could be declared through a single line in EasyLanguage. This sort of complexity might frighten away potential users who are more familiar with EasyLanguage.

I did some hacking, and I found a shorter way to declare the same property:

I tested this in MC.net, and it works great. I've attached a revised version of the MovAvg_Cross_LE signal, in which I replaced three properties using this syntax. It's quite a bit shorter and, in my opinion, simpler and easier to read.

To support this, I had to create two derived classes with some helper code, one for the "SignalObject" base class and one for the "InputAttribute" base class (called "DefaultValueInputAttribute" and"DefaultValueSignalObject," attached). To run this code, put the two derived classes into the "Functions" folder, and the "MovAvg_Cross_LE_Rev" file into the "Signals" folder.

Note that it would be possible for MC.net to include this code in the underlying SignalObject and InputAttribute classes. This would eliminate the need to have the additional derived classes, and allow for shorter syntax like this:

Would it be possible for MultiCharts to consider using this syntax or something similar for future releases of MC.net? I generally think that shorter, simpler code is a good thing, especially to help people who might be transitioning from EasyLanguage to C#.

The auto-implemented way is actually semantically equivalent to the verbose way. When it's compiled to MSIL (the intermediate language), the compiler compiles it to a form that's equivalent to the verbose way, with a hidden backing variable. Consequently, there isn't any performance difference.

1. Can “Auto-implemented Properties” improve the performace?

No. It is just helping you to type shorter code but it doesn’t improve the performance since the compiler will generate the same as the way what it generates for normal class that doens’t have auto-implemented properties.

I actually think that this approach would be better than the method I suggested above -- it's cleaner and easier to read. Unfortunately, the "[Input]" attribute in MC .net doesn't currently work for public variables. Perhaps MultiCharts could support this in a future release.

There are some object-oriented "purists" who say that it's bad form to use public variables instead of public properties, but those rationales don't really apply when you just have basic getters and setters that don't perform any validation logic -- like the "verbose" form above. There's a good post about that here from Jeff Atwood:

When is a property not a property? When it's a glorified public variable.Why waste everyone's time with a bunch of meaningless just-in-case wrapper code? Start with the simplest thing that works-- a public variable. You can always refactor this later into a property if it turns out additional work needs to be done when the name value is set. If you truly need a property, then use a property. Otherwise, KISS!

However, note that there isn't a meaningful performance difference between simple properties and public variables. The JIT compiler recognizes when you're using a simple public property, and ends up performing some in-line optimizations that make the code run just as fast as a public variable. That's discussed here:http://stackoverflow.com/a/3265377

Auto Implemented properties is implemented without having explicitly defined the member variable which is maintained by the property. C# compiler automatically implements the underlying member variable. In C#, it is called as hidden backing field. C# compiler defines the private backing field at the compile time. Due to that the name of the auto implemented private backing field is not visible within your C# code base (at the development time). So, it is not accessible. So, you have to manually initialize in some place in your code.