using small or capitalized version of parameters

[uday12]

Suppose I have an indicator that was generated by the Wizard and uses a parameter is that is defined as n1 in the Variable section and N1 in the Properties section. E.g. see below:

-------------
# region Variables
// Wizard generated variables
private double n1 = 150;
....
// User defined variables
private double n2;
private DataSeries lc;
....
#endregion

protected override void Initialize() {
...
n2 = (n1*2+1)/3; // should I use instead n2 = (N1*2+1)/3 ??
...
}

protected override void OnBarUpdate() {
...
lc.Set(myOtherIndicator(n1)[0]) // should I use instead myOtherIndicator(N1)
...
}

#region Properties
...
[Description("")]
[GridCategory("Parameters")]
public double N1
{
get {return n1; }
set { n1 = Math.Max(1, value); }
}
#endregion

-------------

within the codes Initialize() and OnBarUpdate() is there any difference between using n1 versus N1 ?

[sledge]

Did it compile?

Do it both ways and print out N2.

Print ( "n2=" + n2 );
Print ( "N2=" + N2 );

Learning is the best.

[koganam]

Suppose I have an indicator that was generated by the Wizard and uses a parameter is that is defined as n1 in the Variable section and N1 in the Properties section. E.g. see below:

-------------
# region Variables
// Wizard generated variables
private double n1 = 150;
....
// User defined variables
private double n2;
private DataSeries lc;
....
#endregion

protected override void Initialize() {
...
n2 = (n1*2+1)/3; // should I use instead n2 = (N1*2+1)/3 ??
...
}

protected override void OnBarUpdate() {
...
lc.Set(myOtherIndicator(n1)[0]) // should I use instead myOtherIndicator(N1)
...
}

#region Properties
...
[Description("")]
[GridCategory("Parameters")]
public double N1
{
get {return n1; }
set { n1 = Math.Max(1, value); }
}
#endregion

-------------

within the codes Initialize() and OnBarUpdate() is there any difference between using n1 versus N1 ?

You should generally use the public property, but you will still be able to process by using the backing store.

[JerryWar]

uDay12
The way I have come to understand this usage is that "n1" must be defined in the variables section so that it can be used in the get/set of the Properties section, Otherwise, I think it will generate a compile error because there is no variable definition. The public definition of "N1" in the Properties section, as koganam indicated is the variable you should use to access the value. However, having said all that I think you should take Sledges advice and test if there is any difference in Initialize() or OnBarUpdate(). While I would not think so, I can't say as I have never checked for it.

~J

[sledge]

Ok - I see what he is attempting now. I missed that yesterday.

I wouldn't try to code that up in the first place. If I did - I guess I'd access the local VAR if I'm local before the public.

[koganam]

Ok - I see what he is attempting now. I missed that yesterday.

I wouldn't try to code that up in the first place. If I did - I guess I'd access the local VAR if I'm local before the public.

Over the years I have vacillated over this issue many times. For a long while I preferred to use the backing store. Now, however, I always prefer to use properties over their backing stores. There are always exceptions to the rule, but it has many advantages: encapsulating constraints, event triggering, lazy initialization, among other things. Sometimes it's just a lot more work to use the backing store; and sometimes you use other people's code where they have actually put some "work" directly into the property getters and setters, so using the internal variables actually causes problems because you skip raising events or validating or something else.

There is another big reason: being able to handle changes well. Encapsulating a property allows the implementation of the property to change over time without having to update an entire class; only the accessors.

Re: being able to handle change, there is the also the matter of polymorphic properties. In situations where a property is introduced as virtual or inherited from an interface, it is mandatory to access the property internally, instead of using the backing store. For the latter case, properly accessing the property in a polymorphic manner must be done via the interface. Failure to do so can cause bugs when derived classes override the property or re-implement the property's interface to use a different backing store.

Finally, have you noticed that in recent implementations of .NET, it is possible to use implicit properties, where the backing store is not even explicitly declared anywhere in the code? Of course, the backing store is still there, named in Microsoft standard fashion and can be used. Good luck trying to figure out that code when you come back after a year and are reading the code, and realize that you seem to be using an undeclared variable, but the code still seems to be working.