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
And this?
If all the conditions are met, we work. Otherwise - no. Why so many ifs and continues when only one if is enough?
So, I don't understand your complaint here about the code and the programmer who wrote it in some preferences of his own.
Where?
If all the conditions are met, we work. Otherwise - no. Why so many ifs and continues when one if is enough?
There is no difference. But your love to pack everything into one line makes the code hard to read.
And here, I think, is a material for studying. So you shouldn't impose something that will be difficult to understand.
I'm sorry, your codes are hard to understand :) As long as you take it apart and turn it into understandable conditions, you'll get a mess.
Plus, macros cannot be debugged.
There's no difference. But your love to pack everything into one line makes the code hard to read.
And here, I think it's material for studying. So you shouldn't impose something that will be difficult to understand.
I'm sorry, your codes are hard to understand :) While you are parsing it and unfolding it in understandable conditions, you will have a mess.
Plus, macros cannot be debugged.
What does my personal style have to do with it? Or does code evaluation now depend on authorship?
You can ask people which code is clearer. In my opinion, nothing is clearer
If all conditions are satisfied - we work. Otherwise - no.
If all the conditions are met, we work. Otherwise - no. Why so many ifs and continues when one if is enough?
Where?
Well, maybe not a complaint, but a constant hint at a wrong approach.
I think (well, since I got here yesterday) that different approaches to code compilation have the right to exist and not only those that one of us - those present here - just likes.
But still, I'll try to repeat myself - there are teaching codes in kodobase. And our task is to explain to people who ask about something.
So far, though, I can see that only the two of us have any interest. And then, we speak from our own bell tower ;)
It would be interesting to hear someone else's opinions. Otherwise you and I will go round and round - I'm talking about the fact that it's a textbook, and you're talking about the fact that any textbook should be absolutely flawless. (What about "Hello Word!" ? :))
I mean it's a textbook, and you mean any textbook should be absolutely flawless.
There should be no obvious mistakes. There are no complaints about stylistics, just an attempt to understand and show that it is possible otherwise.
ZЫ No one reads this thread, because KB-prog discussion threads are opened only by accident.
What does my personal style have to do with it? Or does code evaluation now depend on authorship?
You can ask people which code is clearer. I don't think it's any clearer
Two identical codes written slightly differently. It's not about the preferences of each individual.
But you asked the question: "why this way and not that way".... I think it is because:
Forum on trading, automated trading systems and testing trading strategies.
Expert Advisors: Diff_TF_MA_EA
fxsaber, 2018.02.02 10:05 am.
What does my personal style have to do with it? Or does code evaluation now depend on authorship?
You can ask people which code is clearer. In my opinion, nothing is clearer
There should be no obvious mistakes. There are no complaints about the stylistics, just an attempt to understand and show that it can be done differently.
Of course it can be different. And I don't see any obvious errors in the context of the code of the whole programme. Yes, the checks are cut down. But they are not necessary, that's why they are probably cut down. And I have already explained the enumeration replacement - they replaced it in vain - now it is more difficult to improve it - you need to change the input enumeration. All other things being equal.
Two identical codes written slightly differently. It's not about the preferences of each individual.
But you asked the question: "why this way and not that way".... I think it's because:
I assume that he is not aware of the alternative. But the author keeps silent.
By the way, this "personal style of the programmer" is actually the result of using it in QB.
Of course you can do it differently. And I don't see any obvious errors in the context of the code of the whole programme. Yes, the checks are cut down. But they are not necessary, that's why they are cut down. And I have already explained the enumeration replacement - they replaced it in vain - now it is more difficult to improve it - you need to change the input enumeration. All other things being equal.
I replaced it.
A serious mistake.
I assume he is not aware of the alternative. But the author is silent.
By the way, this "programmer's personal style" is actually the result of using it in KB.
We can find out only when the author answers us.
But about personal styles depending on the use of KB, this is probably overkill - you have published in KB, don't you know the requirement to bring the style to the MK style? I know, and I am quite surprised that my codes in KB are published in my style. Here, most likely, it's either the programmer's style or the requirement of identical style of the whole KB.