Getting the "empty controlled statement found" warning | MetaEditor - mql4

Question

How would I ensure that the following if, else if statement follows the following rule:
"If everything in either /*Condition 1*/ or /*Condition 2*/ is true,thencarry on assessing /*Conditions 3 - 12*/"
At present, I am getting the empty controlled statement found 313 38 compiler error/warning.
if(shiftOneClose < shiftOneOpen){ /*Condition 1*/
if((bearHammer / (shiftOneOpen - shiftOneLow) <= OoTMax))
if((bearHammer / bullNail) <= OoTMax)
if(bearHammer >= Transform(PCM,2)); /*Line 313*/
}
else if(shiftOneClose > shiftOneOpen){ /*Condition 2*/
if((bullHammer / (shiftOneClose - shiftOneLow) <= OoTMax))
if((bullHammer / bullNail) <= OoTMax)
if(bullHammer >= Transform(PCM,2));
}
if.... /*Conditions 3 - 12*/
if....
if....
if....
if....
if....
if....
if....
if....
if....
{
[execute trade]
}

Answer 1

You can use general control structures followed by other programming languages like C++, JAVA.
In case you are unfamiliar:
&& this indicates and
|| this means or
Example:
//--- so in order to make it evaluate conditions 3-12, if only condition 1 or 2 is true
if(condition1 || condition2){
if(condition3 && condition4){ /* so on until 12 */
//--- execute trade
}
}
In order to improve the readability of the code I suggest you move some of the conditions into functions

Answer 2

Q : "How would I ensure that the following if,else if statement follows the following rule:
"If everything in either /*Condition 1*/ or /*Condition 2*/ is true,then carry on assessing /*Conditions 3 - 12*/""
The original code blew up in line 313, because the ;-character terminates a statement-constructor, while there was nothing to "execute" if (either) of the if(){...}else{...}-ed conditions were met (the same problem is in the else{...} part, where is also none {...}-code-block present and the formal-statement constructor gets panic not knowing what to "execute" in either of the if(){...}else{...}-branches, as the statement is formally not complete).
if ( shiftOneClose < shiftOneOpen ) /*Condition 1*/
{
if ( ( bearHammer / ( shiftOneOpen - shiftOneLow ) <= OoTMax ) )
if ( ( bearHammer / bullNail ) <= OoTMax )
if ( bearHammer >= Transform( PCM, 2 ) ); /*Line 313*/
}
So, not telling what to do if conditions get met is the root problem above.
The Solution to the "HOW WOULD I ENSURE ..." part:
A syntactically correct would be this explanatory logic-preserving code template:
if ( ( ( shiftOneClose < shiftOneOpen
&& OoTMax >= ( bearHammer / ( shiftOneOpen - shiftOneLow ) )
&& OoTMax >= ( bearHammer / bullNail )
&& Transform( PCM, 2 ) <= bearHammer
) /*--------------------------------------------------------------------- Condition 1 */
|| ( shiftOneClose > shiftOneOpen
&& OoTMax >= ( bullHammer / ( shiftOneClose - shiftOneLow ) )
&& OoTMax >= ( bullHammer / bullNail )
&& Transform( PCM, 2 ) <= bullHammer
) /*---------------------------------------------------------------- .OR. Condition 2 */
)
&& ( ... ) /*---------------------------------------------------------------- .AND.Condition 3 */
&& ( ... ) /*---------------------------------------------------------------- .AND.Condition 4 */
&& ( ... ) /*---------------------------------------------------------------- .AND.Condition 5 */
&& ( ... ) /*---------------------------------------------------------------- .AND.Condition 6 */
&& ( ... ) /*---------------------------------------------------------------- .AND.Condition 7 */
&& ( ... ) /*---------------------------------------------------------------- .AND.Condition 8 */
&& ( ... ) /*---------------------------------------------------------------- .AND.Condition 9 */
&& ( ... ) /*---------------------------------------------------------------- .AND.Condition A */
&& ( ... ) /*---------------------------------------------------------------- .AND.Condition B */
)
{...} /*---------------------------------- CODE-BLOCK TO EXECUTE ------------------------------*/
In my ~ 20+ years of Quant modelling, we always preferred to have wide-layout (screens are cheap and having 4 x 2 and larger multi-screen seats is so easy and so common in more than a recent decade ), emphasis on the logic, then reducing dup-es in computation(s) (best pre-computing any & all logic-"control-values" to be then re-used and due to low-latency ( often ultra-low-latency ) reasons, we never resorted to spend any extra time on calling function ( overheads with context-switching & passing parameters there & results back ). Not all compilers (versions) did short-cutting the execution branches due to laws-of-logic, so care must be taken here ( most expensive functions being those that manipulate/query the db.POOL-storage with trades' data, having an awfully expensive costs of first having to do a db.POOL-pointer manipulation and then & only then (on success thereof & never otherwise) re-access the db.POOL-record's items of data ).
One should also notice that there is a logical blind-spot -- shiftOneClose == shiftOneOpen.