to save reading, I usually write it down like this:
Thanks for the tip, I got a bit dizzy when I thought "how many inverted commas do I have to fill in, don't miss any and put them in the right places". Being able to write that way brought me back to life.
paladin80: The possibility of such an entry brought me back to life.
just remember that if there is only one operator in a loop/condition, you don't have to use inverted commas.
the main thing is not to get caught up in nested type conditions:
if (cond1)
{
if (cond2) operator1;
else operator2;
}
записывать вот так нельзя:
if (cond1)
if (cond2) operator1;
else operator2;
так как оператор else непонятно к чему относится
к cond1 или cond2.
Just remember that if there is only one operator in a loop/condition, you don't have to use inverted commas.
The main thing is not to get caught in nested type conditions:
if (cond1)
{
if (cond2) operator1;
else operator2;
}
записывать вот так нельзя:
if (cond1)
if (cond2) operator1;
else operator2;
так как оператор else непонятно к чему относится
к cond1 или cond2.
Actually, it's kind of straightforward here: else refers to the nearest earlier if, not closed else. Or am I missing something here?
But in any case, when in doubt, it is better to put all sorts of brackets - both curly and round brackets. I try to do this whenever the structure is non-trivial.
Actually, it's kind of straightforward: else refers to the nearest earlier if, not closed else. Or am I missing something here?
But in any case, when in doubt, it's better to put all sorts of brackets - curly and round brackets. I always try to do this if the structure is non-trivial.
A proger can easily make a mistake, meaning this
if(cond1)
{ if (cond2) operator1; }
else operator2;
instead of this
if (cond1)
{
if(cond2) operator1;
else operator2;
}
I understand, of course. But an experienced coder won't make such a mistake because he puts curly brackets right there, even if there's nothing there yet :)
But an inexperienced one, who saves on brackets and strings (as if it were paper), of course, is more prone to make a mistake.
I was just talking about the parsing rule adopted in modern languages, if there are no braces.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
2.
as we are not sure that in MT4 the && operations are checked in order, with interruption at false
Thanks for the info, I'll fix my code.
To save reading, I usually write it like this:
to save reading, I usually write it down like this:
The possibility of such an entry brought me back to life.
just remember that if there is only one operator in a loop/condition, you don't have to use inverted commas.
the main thing is not to get caught up in nested type conditions:
The advice is clear. Are there any contraindications to using || (or) e.g. here:
.
Just remember that if there is only one operator in a loop/condition, you don't have to use inverted commas.
The main thing is not to get caught in nested type conditions:
Actually, it's kind of straightforward here: else refers to the nearest earlier if, not closed else. Or am I missing something here?
But in any case, when in doubt, it is better to put all sorts of brackets - both curly and round brackets. I try to do this whenever the structure is non-trivial.
The advice is clear. Is there any contraindication to using || (or), e.g. here:
No, you can't put || in if "in a row".
except with an intermediate variable.
bool b1=A1 || A2; // here we can use long conditions
if (b1) // and here b1 can be combined with various other conditionsActually, it's kind of straightforward: else refers to the nearest earlier if, not closed else. Or am I missing something here?
But in any case, when in doubt, it's better to put all sorts of brackets - curly and round brackets. I always try to do this if the structure is non-trivial.
A proger can easily make a mistake, meaning this
instead of this
understand?
I understand, of course. But an experienced coder won't make such a mistake because he puts curly brackets right there, even if there's nothing there yet :)
But an inexperienced one, who saves on brackets and strings (as if it were paper), of course, is more prone to make a mistake.
I was just talking about the parsing rule adopted in modern languages, if there are no braces.
I was just talking about the parsing rule adopted in modern languages if there are no curly brackets.
I've found one without brackets, but I didn't look into it further.