IF/THEN's or Not

[coolmoss]

I have no formal programming education, so much of what I do is trial and error and my own version of common sense. I often run into situations where I have a string of conditions to check.

For example: A > B && C ==D && E != F and so on. I just string them all together in one line for the IF, then follow with the THEN block of code to execute.

Would there be a performance advantage to next IF/THENs. And if not, then why do programmers tend to use all these nested statements, which to me is more confusing to follow.

For example:

if (A>B)
if(C==D)
if(E != F)
{
//do stuff
}

[sledge]

I usually need to code else statements for the inner checks.

Usually , with NT , it is to make the logic less complicated by isolating the if statement as to why the code isn't entering my conditions..

[coolmoss]

Thanks, Sledge. I never even thought of debugging in that fashion. If anyone at Ninja has input on whether there are performance considerations, I'd appreciate hearing any comments on that.

When I started this project, I was at maybe 200 lines of code in total. I'm now around 1400 and counting. I'm amazed every time I run the thing and it works, LOL.

[NinjaTrader_AdamP]

coolmoss,

This syntax :

if (A>B)
if(C==D)
if(E != F)
{
//do stuff
}

Is incorrect. Think of && as an operator just like addition is an operation with "+" as its operator symbol.

A>B will return "true" if A is greater than B, and returns "false" otherwise.

C==D will return "true" if C is equal to D, and returns "false" otherwise.

A>B && C==D checks to see if both expressions are "true". If they are both true it returns "true", or if one or both are "false" it returns "false".

Expression1 && Expression2 has a truth table like this (the ^ is "and") : http://www.marco-learningsystems.com...nny/p105-2.png

If you need to string stuff together with && operators, I would suggest using the following for visual clarity :

if (  A > B
&& C==D)
&& E != F)
{
//do stuff
}

What Sledge said I believe is to use nested If statements, so like this :

if (A>B)
{
    if(C==D)
    {
         if(E != F)
         {
             //do something
         }
    }
}

This is logically equivalent to the former example I gave you, but a lot of extra characters.

Have you watched this? : http://www.youtube.com/watch?v=JZpo01eSO9c

[coolmoss]

Thanks Adam,

Sorry to make you type out so much. I realized I made a huge syntax error when posting my original question. I do realize the 3 If's in a row is not correct.

Thanks for your clarifications and for the links.

[koganam]

I have no formal programming education, so much of what I do is trial and error and my own version of common sense. I often run into situations where I have a string of conditions to check.

For example: A > B && C ==D && E != F and so on. I just string them all together in one line for the IF, then follow with the THEN block of code to execute.

Would there be a performance advantage to next IF/THENs. And if not, then why do programmers tend to use all these nested statements, which to me is more confusing to follow.

For example:

if (A>B)
if(C==D)
if(E != F)
{
//do stuff
}

I guess it depends on one's thinking style. For me, that (no-block) syntax is more difficult to follow too, but in C# is actually legal and correct.

That is because C# allows one to follow an if statement with code not enclosed in braces, in which case C# will execute only the next statement as the condition of the if. That single statement that follows an if statement can itself be an if statement, which is why the syntax works.

If you ask me, I prefer to have explicit logical AND/OR statements for my if's. It is just easier for me to follow the code. Then again, some others find the other way easier. I know Big Mike does, as quite a bit of his code on his BMT forum does use the unbraced nested if construct.

[sledge]

Thanks Adam,

Sorry to make you type out so much. I realized I made a huge syntax error when posting my original question. I do realize the 3 If's in a row is not correct.

Thanks for your clarifications and for the links.

I assumed you were being brief and 'psuedo' coding

[sledge]

Is ninjascript interpreted or compiled as machine code for run time, or interpreted compiled machine code? lol

Depending on the optimization, I don't think any speed gains would be if you had all your conditions in an IF statement or layered them with multiple if statements. It will check them in order, and perform the 'short circuit boolean evaluation' if applicable ....

So I guess you are left with code readability and nesting level readability.

I guess it depends on one's thinking style. For me, that (no-block) syntax is more difficult to follow too, but in C# is actually legal and correct.

That is because C# allows one to follow an if statement with code not enclosed in braces, in which case C# will execute only the next statement as the condition of the if. That single statement that follows an if statement can itself be an if statement, which is why the syntax works.

If you ask me, I prefer to have explicit logical AND/OR statements for my if's. It is just easier for me to follow the code. Then again, some others find the other way easier. I know Big Mike does, as quite a bit of his code on his BMT forum does use the unbraced nested if construct.

[koganam]

Is ninjascript interpreted or compiled as machine code for run time, or interpreted compiled machine code? lol

Depending on the optimization, I don't think any speed gains would be if you had all your conditions in an IF statement or layered them with multiple if statements. It will check them in order, and perform the 'short circuit boolean evaluation' if applicable ....

So I guess you are left with code readability and nesting level readability.

NT seems to compile all its .cs files into NinjaTrader.Custom.dll, which would make it compiled code. Then again, if you export stuff as an assembly, NT creates a separate .cs file to hold the wrappers that correspond to the dll, so it would appear that that part of the code may actually be interpreted.

[coolmoss]

Thanks to all who contributed here. If any educated programmer were to look at my code, no doubt they would cry. It looks crazy, but I can understand it so much better than conventional practices. My only concern was if I was causing any bad performance issues by just grouping a bunch of AND's and OR's together versus layering the conditions in nested IF/THEN's.

Since there doesn't appear to be, and I'm the only one I need to please with my code, I'm satisfied

[NinjaTrader_AdamP]

coolmoss,

There isn't really another way to do it. In programming you are always checking if something is true, or false, then instructing your program to do something. If/Then/Else are staples of functional programming languages, however it may be the case you could reduce more sprawled code to something much simpler, or to use some algorithm that is more efficient.

It gets a bit different when you start going into the object-oriented programming realm but NinjaScript can be thought of as a subset of full C# that is a bit easier to "script" with. You can basically use it as a functional language.

If you are interested in learning programming, I would suggest maybe putting yourself through a free tutorial.

Here is a reference : http://en.wikibooks.org/wiki/C_Sharp_Programming

This is a tutorial : http://www.csharp-station.com/Tutorial.aspx/

[sledge]

Thanks to all who contributed here. If any educated programmer were to look at my code, no doubt they would cry. It looks crazy, but I can understand it so much better than conventional practices. My only concern was if I was causing any bad performance issues by just grouping a bunch of AND's and OR's together versus layering the conditions in nested IF/THEN's.

Since there doesn't appear to be, and I'm the only one I need to please with my code, I'm satisfied

The only thing I could recommend, would be to sort your IF conditions such that the ones that are the hardest to satisfy are first, so all the easy conditions aren't really checked until the hardest is checked. Maybe move the ones that are very computational and take longer to calculate near the end.

I hope that makes some sense.

But when you are talking 2+GHZ machines, you shouldn't be losing much time anyways, and just work on program correctness.