コーディングスタイルについて - ページ 4

 
Mathemat >> :

由良 1回で返すという例は、もちろん論理的です。しかし、この場合、returnが多い場合とは異なり、条件を満たす文字列に到達した直後に関数から抜けるため、すべてのifが常に実行されることに注意する必要があります。

ForexToolsさん、ありがとうございます!書式については、あなたの考えを採用させていただきました。

数学、条件演算子「if」にも「else」のようなギミックがあるからです。

if(式1) operator1;

else if(expression2)オペレータ2;

else if(expression3)オペレータ3;

else operator4;

そして、最初の真条件の後に演算子が実行され、それでおしまいです。すべてのifは、さらに実行されません。真の条件が見つかった場合、対応する演算子が実行され、この構文の後にプログラムが続行されます(構文内の検索はこれ以上行われません)。

 

私は議論しているのではない、セルゲイ。ここでは、ジュラの デザインについて話していました。

 

MQLのプログラムを書くとき、プラットフォームの制限はどの程度影響するのでしょうか? 例:論理的に分離された計算を別々の関数で行う方が、コードの記述、理解/読解、保守が容易になる。しかし、(特にMQLのようなインタプリタでは)関数を呼び出す たびに、時間のかかる操作が必要です。もちろん、1回の呼び出しは重要ではありませんが、ほとんどの場合、ループの中でそのようなことを書かなければなりません(for int i=0; i<Bars; i++)など。ここで、より重要なことを決め始めるのです。(関数形式で、後で書いたことを理解できるように)美しいコードと実行速度(同様の断片のコピーで、次のティックが来るまでにループがずっと動作するように)。

それぞれのケースで-黄金平均線の判定が異なることは明らかですが...。誰がこの問題を解決するのか?

 

同じスレッドの1ページ目に、短い研究結果を掲載しました。私の計算量では(少ないですが)、1行の長さでもかなり満足できる機能です。しかし、このスレッドには他の意見もある。

 
そういうことじゃなくて...。プラットフォーム(MTに限らず)の外部制約を考慮する必要性から、コーディングスタイルがどの程度影響を受けるかということです。
 

おそらく効果があるのでしょう。私は以前、古代のトルボ・パスクアル語を理想的なものとして考えていました。そこでは、関数の構造化、すなわち関数の中の関数の宣言が可能である。Cはそれを許さない。そして、これはまさに今私がやろうとしていることなのですが、基本的にはCプラットフォームでやっています。もちろん、これはあくまでも外見上のことです。

より正確に、セルゲイ

 

Раньше я считал идеальным древний язык Трубо Паскуаль. Там есть возможность структурирования функций, т.е. объявление функций в функциях.

一体どうなんだ?個人的には、プログラミング言語の学習は、C言語から始めた時代でした。今は、CとC++の2つを知っています。そして、他の言語を勉強することに全く魅力を感じないというのが正直なところです。なぜ関数の中で関数を宣言しなければならないのですか?個人的には、CとC++だけで育ったので、この方法は理解できません。

 
C-4 >> なぜ、関数の中で関数を宣言する必要があるのでしょうか?>> 個人的には、CとC++だけで育ったので、この方法は理解できません。

でも、今は理解できています。6次までの機能がある場合、異なる次数の機能をひとまとめにするのは不便なことが多いんです。通話構造の全体像がわからなくなる。そして、「Trubo Pasqualee」では、これですべて便利になります。主要な処理を行うメイン機能をいくつか用意し、その中に小さなサブ機能をすべて隠しているのです。

でも、それは習慣の問題でしょう。長い間、何も書いていないのですが......特に後悔はしていません。

 
C-4 >> :

なぜ関数の中で関数を宣言しなければならないのですか?個人的には、C, C++だけで育ったので、この方法は理解できない。

"世の中には我々の賢者が夢にも思わなかったことがたくさんある、友よホレイショ" ;)

いわば、カプセル化の中のカプセル化という美しさがあるのです。でも真面目な話、賢く使えば本当に便利なツールなんですよ、他のものと同じようにね。

数学 私は以前、古代のトルボ・パスクアル語は完璧だと思っていたんです。

MQLで簡単だけど必要なもの(例えばトレーダーとのちょっとした対話)を作るのに飽きたので、せめてDelphiのDLLという形で戻そうかと考えています。

 

- ブラザー!強さは何ですか?

- 強さはクラスの中にある、ブラザー!

授業より優れたものはまだ発明されていないと思います。クラス内部にはプライベート関数を、クラスと連携するパブリック関数を宣言する。迫力があっていいですね。関数や変数を継承し、階層を考える。複雑なデータ構造を作成することでデータをカプセル化する。標準テンプレートライブラリのユニバーサルアルゴリズムでデータを処理します。正直なところ、MQL4ではカプセル化が非常に貧弱です。異なる種類のデータを別々に管理する必要があり、ミスが発生します。しばしば、配列のインデックス付けに 注意しなければなりません(ひどく迷惑なエラーです)。これはMQL5で止められると思います。