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

新しいコメント
 
Ihor Herasko:

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

と書くとよいでしょう。

この方法は、条件を付けることに対して非常に有効です。

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

同じ状況が続いています。みたいなコード。

の方が読みにくい。

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

それは全く残念なことです。

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

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

if (OrderMagicNumber() != m_nMagicNumber)
   continue;
 
Vitaly Muzichenko:

まったくもって残念な話ですよね。

ティニーって何？超表現の1行が大変なことになる。人間はコンピューターではないので、それ以外の条件を処理する必要はないのです。人間はコンピュータと違って、式全体を最後まで計算し、その最初の成分が誤った結果を導くことだけを理解しなければならない。

すべてが単純な条件によって分解されるエントリでは、この計算は不要である：最初の条件が満たされていない - 消えている。

文字列ではなく、時間を節約する必要があるのです。しかし、彼らはただ簡潔さを求めて戦うだけで、それは実際には操作と条件を互いに詰め込むことなのです。この梱包で生産性がかなり上がるのであれば、理解できるのですが。でも、そうじゃないんです。最大成長率は測定誤差の範囲内です。人々は、文字列の節約には関心があっても、コードの理解やデバッグに費やす時間の節約についてはまったく考えていないのです。

 
Ihor Herasko:

スズって何？1行の超式......そこが大変なんです。人間はコンピュータではないので、残りの条件を処理する必要がないことをすぐに理解できる。人間はコンピュータと違って、式全体を最後まで計算し、その最初の成分が誤った結果を導くことだけを理解しなければならない。

記録では、すべてが単純な条件によって分解されるため、そのような計算は不要である。

文字列ではなく、時間を節約する必要があるのです。しかし、彼らはただ簡潔さを求めて戦うだけで、それは実際には操作と条件を互いに詰め込むことなのです。この梱包で生産性がかなり上がるのであれば、理解できるのですが。でも、そうじゃないんです。最大成長率は測定誤差の範囲内です。人々は、文字列の節約には関心があっても、コードの理解やデバッグに費やす時間の節約についてはまったく考えていないのです。

読みにくい超式とは言いません。

if(!OrderSelect(i, SELECT_BY_POS) || OrderSymbol() != Symbol() || OrderMagicNumber() != m_nMagicNumber)
   continue;

あ、あと「計算周期が短い」というのは、条件を読み取るときに、頭で考えなくても「自動的に」考慮される基本的なことですね。

繰り返しになりますが、純粋に主観的な意見です。

 
Vladislav Boyko:

あなた自身も、習慣の問題だと認めていますね。

そして、何度も言います。別に習慣を変えて、フェルトペンの味の違いを探すことを勧めているわけではありません。

イゴール・マカヌ

おっしゃるとおり、好みの問題ですが、ご存知のとおり、フェルトペンはすべて違います ))))

フェルトペンの群れは、色だけが違っていて、味は同じです。
 
Vladislav Boyko:

読みにくい最上級品とは言いません。

そして、ここで何かを呼び出す必要はありません。今のところ、私の反対派（あなたも含めて）は、この表現が改行より読みやすいという主張を一つもしていません。

しかし、私からは、3つもの主張がなされています。

  1. 長い線は 視野に入りません。少なくとも最小限の頭部の回転を必要とする（処理時間が長くなる）。短い線とそれに続く線は、それほど大きな力を必要としません。
  2. 長い列の中では、ミスをしても気づかないことが多い。行に分けることで、このようなミスが発生する確率を下げることができます。
  3. 長い線はデバッグができない。文字列に分割することは問題ありません。
主観的な好みがない。すべては実用的なセンスによって正当化され、それ以上のことはないのです。たしかに、右足のかかとで左耳を掻いたほうが便利な人もいるかもしれませんが、この方法が実用的かというと、そうではありません。自然界では、すべてが実用性に左右され、より実用性の高いものが生き残る。
 
Ihor Herasko:

また、ここで何かを名指しする必要はありません。今のところ、私の反対派（あなたも含めて）は、この表現が改行より読みやすいという主張を一つもしていません。

しかし、私からは、3つもの主張がなされています。

  1. 長い線は 視野に入りません。少なくとも最小限の頭部の回転を必要とする（処理時間が長くなる）。短い線とそれに続く線は、それほど大きな力を必要としません。
  2. 長い列の中では、ミスをしても気づかないことが多い。行に分割することで、このようなミスが発生する確率が下がります。
  3. 長い線はデバッグができない。文字列に分割することは問題ありません。
主観的な好みがない。すべては実用的なセンスによって正当化され、それ以上のことはないのです。たしかに、右足のかかとで左耳を掻いたほうが便利な人もいるかもしれませんが、この方法が実用的かというと、そうではありません。そして自然界では、すべてが実用性に左右され、より実用性の高いものが生き残る。

イゴール 眼球が眼窩の中で動かず、頭を回さなければならない場合、そのように書くことができます。

if(OrderSelect(i, SELECT_BY_POS)
&& OrderSymbol() == _Symbol
&& OrderMagicNumber() == m_nMagicNumber)
 {
  // Делаем что надо...
 }

そして、エラーが出ている短いセリフにどれだけ出くわしたことか......。どうやら、エラーの数や確率は線の長さには依存しないようです。

デバッグで納得するしかない。しかし、その習慣はmql4でデバッガが登場する前から身についており、誰もが習慣を変えることができるわけではありません。

 
Alexey Viktorov:

イゴール 眼窩の中で目が動かず、首を回さなければならない場合は、そのように書けばいいのです。

そして、エラーが出ている短いセリフにどれだけ出くわしたことか......。どうやら間違いの数や確率は、線の長さには関係ないようです。

デバッグに納得するしかない。しかし、その習慣はmql4のデバッガ以前から身に付いているもので、誰もが習慣を変えることができるわけではありません。

しかし、このスタイルでは、プログラムの1ブロックを見るのに、画面を2回スクロールしなければならず、1つの画面ですべてのコードを見るよりも、操作性が悪くなります。(あなたに関することではなく、あくまで一例です）。

 
fxsaber:

残念ながら、この神話はフォーラムの歴史に何の裏付けもありません。しかも、開発者は一貫して「原則的にそのような変更はできない」という立場を明確にしています。

そんなものがあったんですね。仕分けが影響したのです。

おそらく、旧metatrader4.comのフォーラム（最近もオープン、現在はmql5.comにリダイレクトされています）で議論されていたのでしょう。

 
Andrey Khatimlianskii:

こんな感じでしたね。仕分けに影響が出た。

旧metatrader4.comのフォーラム（最近もオープン、現在はmql5.comにリダイレクトされています）で議論されていたのでしょう。

そうだった、そうだった。今までのヒストリカルオーダーの 数と同じように、「今日」を設定すると、OrdersHistoryTotal()は今日決済された注文の数を返します。履歴」タブに古い注文が表示されない場合は、チケットでもご利用いただけません。

 
Alexey Viktorov:

そうだった、そうだった。今までのヒストリカルオーダーの 数と同じように、「Today」を設定すると、OrdersHistoryTotal()は今日決済された注文の数を返します。履歴」タブに古い注文が表示されない場合は、チケット単位でも利用できません。

それは仕分けについてです。当時は、時間順にソートされていないと、インデックスで最後の1枚を探すことができなかったんですねー。

そして今、歴史の深さは、選択されたタブに依存しない？私見では、今でもそうだと思います。

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