mql4言語の特徴、微妙なニュアンスとテクニック - ページ 11

新しいコメント
 
Ihor Herasko:

多くのソフトウェア会社では、このようなコードは指をすべて叩き切られてしまう。まず、いつでもどこでも求められるのは、「無駄な読書」をしないことです。例えば、関数を入力する際に条件を使用する場合。

と書くとよいでしょう。

この方法は、条件が付かない場合にはとても有効です。

またしても、面倒なことになりそうです。結局、OrderType()関数が何を返すのか、誰もチェックしなかったのです。それとも、-1や6が返ってきたのでしょうか？これは、コンパイラのプロパティに依存する例であり、常に避けるべきものです。あなた自身、クロスプラットフォームのコードの例をたくさん挙げていますね。では、なぜ今回はそこから離れていくのでしょうか？新しいMQコンパイラが登場すると、このコードはもう正しく動作しなくなります。

ソフトウエア会社と我々の議論に何の関係があるんだ！？コードが動かなくなることはない。ここでコスパを求める必要はない。

コンティニューも同じ状況です。のようなコードです。

の方が読みにくい。

それでいて、実行の効率はどちらも同じです。

この場合、6行のコードより1行のコードの方が読みやすい。しかも、何らループの中に縛られることがないので、より論理的である。つまり、2つ目のケースを気にすることなく、1つ目のケースをコピー＆ペーストすることができるのです。

 
fxsaber:

上記のLots[]の例は、コードがいかに超古典的でありながら、完全に理解できるものであるかを示す宝の山である。

コードを理解できると思うのは、あなた自身です。しかし、ドキュメントに目を通しただけで、あなたのコードを見た人は、ドキュメントには6つのオーダータイプしか 書かれていないのに、なぜ配列のサイズが8なのか、と思うでしょう。

また、個人的には、条件を別々に、つまりこのように区切った方が読みやすいと思います。

if (!OrderSelect(i, SELECT_BY_POS))
   continue;

if (OrderSymbol() != Symbol())
   continue;

if (OrderMagicNumber() != m_nMagicNumber)
   continue;

私も、こうしているよりかは楽なんです。

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)
{
}

でも、好みや習慣の問題だと思うんです。誰も何かを押し付けたり、証明したりする必要はないのです。

一方で、私もそのことに同意しています。

MT4-история торгов отсортирована по времени закрытия и это правило меняться не будет.

そして、論理的だと思うのですが、他の回は記憶にありません。

 
Alexey Kozitsyn:

あなたにとって、コードは理解できるものです。しかし、ドキュメントに目を通しただけで、あなたのコードを見た人は、ドキュメントにあるオーダータイプは 6しかないのに、なぜ配列のサイズは8なのかと、すぐに疑問に思うでしょう。

シンプルなコードが、いかに人々の心に正しい問いを生み出すか、おわかりいただけたでしょうか？その後、ドキュメンテーションに書かれていることをすべて信用すべきなのでしょうか？

 
fxsaber:

その後、ドキュメントのすべてを信用すべきなのでしょうか？

それはRTFM プログラミングの基本原則です。

RTFM
  • lurkmore.to
RTFM (изначально сокр. от англ. read the following manual, «обратитесь к прилагаемому руководству») — типичный ответ службы поддержки на вопрос пользователя, обычно сопровождающийся номером или названием этого руководства.
 
Igor Makanu:

べきであり、それはRTFM プログラミングの基本原則である。

現実はこの原則に反している。

 
fxsaber:

ソフトウエア会社と我々の議論に何の関係があるんだ！？

では、他に誰を権威として引き合いに出せばいいのでしょうか？

コードが動かなくなることはない。ここでコスパを求める必要はない。

MT4はほぼ埋まっているので、99％の確率でそうなります。しかし、クロスプラットフォームでそのような芸当をしようとすると、すぐに致命的なエラーにつながる欠陥が消えてしまいます。

この場合、6行のコードより1行のコードの方が読みやすい。しかも、ループの中である必要性に一切縛られないので、より論理的です。つまり、最初のケースは簡単にコピーできますが、2番目のケースはコピーできません。

特定のケースについて話しているのであれば、与えられたコードはすべてのEAにほぼ標準的であるため、それは真実である可能性があります。しかし、もっと複雑なものを取り上げると、1行で書かれたときに読みにくいんです。

あなたのコードを扱う人が、宇宙からの呪いに耳を傾ける必要はないでしょう？))

 
Ihor Herasko:

では、他に誰を権威として引き合いに出せばいいのでしょうか？

ここで権威という概念に触れているのは不思議なことです。

はい、MT4では99％の確率でそうなります、MT4はほぼ埋まってますから。しかし、クロスプラットフォームでそのような芸当をしようとすると、たちまち致命的なエラーにつながる欠陥が消えてしまうのです。

MT5での書き込みは同一です。

特定のケースに限って言えば、与えられたコードは各EAのほぼ標準的なものなので、そうなる可能性があります。しかし、もっと複雑なものを取り上げると、一行で書かれたものでは読みにくくなってしまいます。

また、if→else if→elseという構文もある。条件演算子のbool式は、なぜ最も原始的な形で与えなければならないのか、理解できない。

 
Alexey Kozitsyn:

あなたにとって、コードは理解できるものです。しかし、ドキュメントに目を通し、あなたのコードを見た人は、ドキュメントにあるオーダー タイプが6しかないのに、なぜ配列のサイズが8なのかとすぐに疑問に思うでしょう。

また、個人的には、条件を別々に、つまりこのように区切った方が読みやすいと思います。

私も、こうしているよりかは楽なんです。

でも、好みや習慣の 問題だと思うんです。誰も何かを押し付けたり、証明したりする必要はないのです。

一方で、私もそのことに同意しています。

そして、論理的だと思うのですが、他の回は記憶にありません。

それがキーワードです。

個人的には、continueのスペルが全くないのが気になる。

何のためにあるんだ？を読むと 

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)

すべてロシア語で書かれています。

オーダーが決まり、オーダーシンボルが「私たちのもの」、マジシャンも「私たちのもの」であれば...。であれば、すべてを中括弧で囲む。

でも、それだとロシアっぽくないですよね。

令状が選択されていない場合は、ファックオフ...

令状記号が私たちのものでないなら、消えてしまえ...。

といった具合に。

何度、自分たちをそこに送り込めばいいんだ......。

どうやらこれはmql3では意味があったようです。状態を確認する時間を短縮するためだ。そして、最初から最後まで、すべての条件をチェックします。しかし、この状況はとっくに解決されており、チェックが未達成の条件に遭遇した場合、それ以降のチェックは停止される。しかも、これらの仕掛けはまったく意味がない。

 
Alexey Viktorov:

これがキーワードです。

個人的には、continueのスペルが全くないのが気になります

何のためにあるんだ？を読むと

すべてロシア語で読みます。

オーダーが決まり、オーダーシンボルが「私たちのもの」、マジシャンも「私たちのもの」であれば...。であれば、すべてを中括弧で囲む。

でも、それだとロシアっぽくないですよね。

令状が選択されていない場合は、ファックオフ...

令状記号が私たちのものでないなら、消えてしまえ...。

といった具合に。

何度、自分たちをそこに送り込めばいいんだ......。

mql3では意味があったのでしょう。条件チェックの時間を短縮するための工夫だったのです。その際、最初から最後まですべての条件を確認しました。しかし、とっくの昔に解決している。チェックで条件が満たされていないことにつまずくと、それ以降のチェックがストップしてしまうのだ。しかも、これらの仕掛けはまったく意味がない。

習慣の問題だと自分でも納得していますね。私などは、不要な入れ子に悩まされるので、いつもreturnやcontinueで削除しています。また、「地獄に落ちる」ではなく、「条件1と2が満たされている」という読み方に慣れてしまいがちです。

if(!condition1 || !condition2)
   continue;
 
Vladislav Boyko:

例えば、私は不必要なネストに悩まされているので、いつもreturnやcontinueを使って削除しています。

ブール否定 NOT(!)」は、CTsコストがかかるだけでなく、論理式を読むと「逆読み」になってしまうので、イラッとします )))。

私は、bool関数では常に最も期待される応答として "true "を返すようにしています。

bool ServerDisable(int count=10){
   for(int i=0;i<count;i++){
      if(IsConnected())
         if(IsTradeAllowed())
            if(!IsTradeContextBusy()){RefreshRates(); return(false);}
      Sleep(157);
   }
   Print(__FUNCTION__," Торговый сервер не отвечает");
return(true);}

かなり読みやすく、論理的と言えるでしょう。

if(ServerDisable()) return;

サーバーがビジー状態なら - 終了、私は通常、貿易関数で使用、それは忙しいので、要求でサーバーを悩ます必要はありません。

よく言われるように、好みの問題ですが、ご存知のように、好みは分かれますね ))))

1...456789101112131415161718...35
新しいコメント