[ARCHIVE!] Any rookie question, so as not to clutter up the forum. Professionals, don't pass by. Can't go anywhere without you - 4. - page 91
![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
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.