MetaEditorの使いやすさへの提案 - ページ 6 12345678 新しいコメント Rashid Umarov 2017.09.28 14:57 #51 Комбинатор:)) まあ、あなたは失礼なことをする方法を知っている、私はすでに理解しているが、私はあなたの視点の実証と私の反論を見たことがない。ベリンスキーは確かに、公共の場でそんな表現はしないでしょう。だから、苦情は受け付けない。 そして、当局への言及が与えることのできない「嘔吐反射」に対する正当化もない。 Alexey Volchanskiy 2017.09.28 15:04 #52 Alexey Viktorov:これはレプリロイドコードです。パラメータと文字を区切るカンマの後のスペースについて話していたのですが 読みやすくなったこれよりもだから、逆に例を挙げたのです ))以下は、私のコードの例で、ライブから直接です。 void SetThresholds(double &thresholdOpen[], double &thresholdClose[]) { int signalIdx = 0; ///////////////// !!!!!!!!!!!!!!!! пока задано жестко CSignalFilter *signal = (CSignalFilter*)m_SignalArr.At(signalIdx); if (CheckPointer(signal) != POINTER_INVALID) { signal.SetThresholds(thresholdOpen, thresholdClose); } } *** Stanislav Korotky 2017.09.28 15:05 #53 すでに以前の機会に述べたことだが、新しい視聴者のためにもう一度言っておこう。客観的に見ると、スタイルにはデファクトスタンダードが存在します。現在(そして過去10年)、C++/Javaのような構文を持つ言語には、主に2つのものしかありません。これらのスタイルは、Combinatorが声優を務めた。ソフトウェア業界の大半の企業で使用されている。これらは、実績があり、試行錯誤され、論理的で理解しやすく、プロのコーダーの 大多数にとってなじみのあるものです。メリットもなく、欠点ばかりが目立つ他のものを普及させようとしても、それは失敗です。この欠点を認めないのは、頑固以外の何物でもない。客観的である。MQ自体がこのスタイルを使いこなし、ハマっているのは明らかですが、これもバグとしか言いようがないですね。このように、ソフトウェアが既知のバグの修正を拒むことがある。「この誤った動作にひっかかったサードパーティ製品がすでにたくさんある」と言うのである。実際、このようなケースでは、後方互換性のために古い動作を維持しつつ、いわゆる「プロトコルアップグレード」またはフォークで修正を行うことができる解決策を探す必要があるのです。スタイルの文脈では、クローン可能なスタイラスという シンプルなソリューションがあります。これまでにも100回くらいはできたはずです。ところで、MQスタイルでは、括弧の配置だけでなく、コメントのスタイルにも問題があり、定義上、コードを上書きすることはできないので、現在ではMQスタイルで観察されている。 Alexey Viktorov 2017.09.28 15:06 #54 Alexey Volchanskiy: だから、逆に例を挙げたんです ))以下は、私のコードの例で、ライブから直接です。***では、あのスマートさは何だったのか? fxsaber 2017.09.28 15:43 #55 Stanislav Korotky: Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий Вот это стиль! :) Sergey Kravchuk, 2009.11.24 11:27 Вот кусочек кода из MACD Sample.mq5 по-ихнему и по-моему: Styler5 -|- Мой стиль ------- -|- --------- bool CSampleExpert:: LongModified() -|- bool CSampleExpert:: LongModified() { -|- { bool res=false; -|- bool res = false; //--- check for trailing stop -|- //--- check for trailing stop if( InpTrailingStop>0) -|- if ( InpTrailingStop > 0) { -|- { if( m_symbol.Bid()- m_position. Price -|- if ( m_symbol.Bid() - m_position. Pric { -|- { if( m_position. StopLoss()< m_symb -|- if ( m_position. StopLoss() < m_symb { -|- { double sl= m_symbol.Bid()- m_a -|- double sl = m_symbol.Bid() - m_a double tp= m_position. TakePro -|- double tp = m_position. TakeProfi //--- modify position -|- //--- modify position if( m_trade. PositionModify( Sy -|- if ( m_trade. PositionModify( Symbo printf("Long position by -|- printf(" Long position by % s to else -|- else { -|- { printf("Error modifying p -|- printf(" Error modifying positi printf("Modify parameters -|- printf(" Modify parameters : SL } -|- } //--- modified and must exit -|- //--- modified and must exit fro res=true; -|- res = true; } -|- } } -|- } } -|- } //--- -|- //--- return( res); -|- return( res); } -|- }文体を覚えるところはないが、右のバージョンは自分で書いたような「我流」である。左側は、なぜかずっと読みにくい。習慣の問題なのか、よくわかりません。ウラジーミル・カルプトフ フォーラム、コドベースは同じデザインのコードで埋め尽くされているはずです。絶対にダメです!出版にあたり、メソッド名/フィールド名のスタイルを変更することが求められた時期がありました。例えば、this.iの代わりにthis.m_iと記述する。クラス名の条件も同じで、Cから始まること。幸いなことに、常識が通用し、そのような要求はなくなりました。 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム MetaEditorの使いやすさについてのご提案です。 コンビナート 2017.09.28 15:00 オルマン式を使っています。void f() { // some code if (condition) { // some code } }せめてK&Rだけでも。void f() { // some code if (condition) { // some code } }この2つのスタイルが他を圧倒的に引き離している。どちらもコードのネストが明確に読み取れるようになっています。ブロックがどこに属しているかがわかり、フォーマット上の問題はありません。あなたのスタイルはアンダーGNU、上記で声をあげたデメリット。GNUは少なくとも、中括弧からと中括弧までのインデントが同じです。ずっとオルマン式を使っていたことが判明!?K&R - なぜかイライラする。オリンピックのトップリーダーはこのスタイルがとても好きなようだが。 トレーディング、自動売買システム、ストラテジーテストに関するフォーラム MetaEditorの使いやすさについてのご提案です。 コンビナート 2017.09.28 15:15 ついでに言うと、MEで もう一つ厄介なのは、レジスター依存のオートコンプリート です。優れたエディタでは、大文字と小文字を区別しないので、生活が楽になります。 全く同感です。 TheXpert 2017.09.28 15:51 #56 Rashid Umarov:好きなように扱っていいんだよ。私は、万人に喜んでもらえるような100円札ではありません。重要なのは、私が意見を言ったことで、それが聞き入れられ、考慮される可能性があることです。 Alexey Volchanskiy 2017.09.28 16:16 #57 Stanislav Korotky:すでに以前の機会に述べたことだが、新しい視聴者のためにもう一度言っておこう。客観的に見ると、スタイルにはデファクトスタンダードが存在します。現在(そして過去10年)、C++/Javaのような構文を持つ言語には、主に2つのものしかありません。これらのスタイルは、Combinatorが声優を務めた。ソフトウェア業界の大半の企業で使用されている。これらは、実績があり、試行錯誤され、論理的で理解しやすく、プロのコーダーの 大多数にとってなじみのあるものです。メリットもなく、欠点ばかりが目立つ他のものを普及させようとしても、それは失敗です。この欠点を認めないのは、頑固以外の何物でもない。客観的である。MQ自体がこのスタイルを使いこなし、ハマっているのは明らかですが、これもバグとしか言いようがないですね。このように、ソフトウェアが既知のバグの修正を拒否し、「この誤った動作にひっかかったサードパーティ製品がすでにたくさんある」と言うことがあります。現実には、このような場合、後方互換性のために古い動作を残し、いわゆる「プロトコルアップグレード」またはフォークで修正を行うことができる解決策を探す必要があるのです。スタイルの文脈では、クローン可能なスタイラスという シンプルなソリューションがあります。もう100回くらいやってもいいくらいです。ところで、MQスタイルの問題は、ブラケットだけでなく、コメントのスタイルを 懸念- 彼らは定義によって、現在観察されているコードを、優先することは できません。コメントについて付け加えると、どんなオートドキュメントシステムで処理しようとしても、失望することになるでしょう。 Alexey Volchanskiy 2017.09.28 16:19 #58 Alexey Viktorov:では、あのスマートさは何だったのか?br-r-r-r、私はスペースとカンマのないコードの例をあげました。はアンダースコアを削除してください。 Alexey Viktorov 2017.09.28 16:35 #59 Alexey Volchanskiy: br-r-r-r、私はスペースとカンマのないコードの例をあげました。アンダースコアを取り除く スペースがないコードの例を出したのは誰ですか? Andrey Khatimlianskii 2017.09.29 10:19 #60 Rashid Umarov:自分で「吐く」ことを許しているんですね。ロシュ ギャグの何が問題なんだ?私も、MQスタイルは、そう言って嫌味を言っているのでしょうか?コドベースを好きなようにフォーマットして、コードを読み込むときに自動的に行うこともでき、コーダーに負担をかけません。私は、コードを書き、MQ用にスタイルを整え、新しい名前で保存し、レビューのためにアップロードする、ということを思い出しています。そして、スタイリングをキャンセルして、執筆を続けるのです。ナンセンスじゃないですか?カスタマイズできるスタイリストの リソースがない。誰かが合わせているわけではないんです。 しかし、なぜ十字架を背負い、自分の信仰が正しいものであると(全く論拠なく!)皆に言いに行くのでしょうか? 12345678 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
)) まあ、あなたは失礼なことをする方法を知っている、私はすでに理解しているが、私はあなたの視点の実証と私の反論を見たことがない。
ベリンスキーは確かに、公共の場でそんな表現はしないでしょう。だから、苦情は受け付けない。
そして、当局への言及が与えることのできない「嘔吐反射」に対する正当化もない。
これはレプリロイドコードです。
パラメータと文字を区切るカンマの後のスペースについて話していたのですが
読みやすくなった
これよりも
だから、逆に例を挙げたのです ))
以下は、私のコードの例で、ライブから直接です。
***
すでに以前の機会に述べたことだが、新しい視聴者のためにもう一度言っておこう。
客観的に見ると、スタイルにはデファクトスタンダードが存在します。現在(そして過去10年)、C++/Javaのような構文を持つ言語には、主に2つのものしかありません。これらのスタイルは、Combinatorが声優を務めた。ソフトウェア業界の大半の企業で使用されている。これらは、実績があり、試行錯誤され、論理的で理解しやすく、プロのコーダーの 大多数にとってなじみのあるものです。
メリットもなく、欠点ばかりが目立つ他のものを普及させようとしても、それは失敗です。この欠点を認めないのは、頑固以外の何物でもない。客観的である。MQ自体がこのスタイルを使いこなし、ハマっているのは明らかですが、これもバグとしか言いようがないですね。このように、ソフトウェアが既知のバグの修正を拒むことがある。「この誤った動作にひっかかったサードパーティ製品がすでにたくさんある」と言うのである。実際、このようなケースでは、後方互換性のために古い動作を維持しつつ、いわゆる「プロトコルアップグレード」またはフォークで修正を行うことができる解決策を探す必要があるのです。スタイルの文脈では、クローン可能なスタイラスという シンプルなソリューションがあります。これまでにも100回くらいはできたはずです。
ところで、MQスタイルでは、括弧の配置だけでなく、コメントのスタイルにも問題があり、定義上、コードを上書きすることはできないので、現在ではMQスタイルで観察されている。
だから、逆に例を挙げたんです ))
以下は、私のコードの例で、ライブから直接です。
***
では、あのスマートさは何だったのか?
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Вот это стиль! :)
Sergey Kravchuk, 2009.11.24 11:27
Вот кусочек кода из MACD Sample.mq5 по-ихнему и по-моему:
文体を覚えるところはないが、右のバージョンは自分で書いたような「我流」である。左側は、なぜかずっと読みにくい。習慣の問題なのか、よくわかりません。
フォーラム、コドベースは同じデザインのコードで埋め尽くされているはずです。
絶対にダメです!出版にあたり、メソッド名/フィールド名のスタイルを変更することが求められた時期がありました。例えば、this.iの代わりにthis.m_iと記述する。クラス名の条件も同じで、Cから始まること。幸いなことに、常識が通用し、そのような要求はなくなりました。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
MetaEditorの使いやすさについてのご提案です。
コンビナート 2017.09.28 15:00
オルマン式を使っています。
せめてK&Rだけでも。
この2つのスタイルが他を圧倒的に引き離している。どちらもコードのネストが明確に読み取れるようになっています。ブロックがどこに属しているかがわかり、フォーマット上の問題はありません。
あなたのスタイルはアンダーGNU、上記で声をあげたデメリット。GNUは少なくとも、中括弧からと中括弧までのインデントが同じです。
ずっとオルマン式を使っていたことが判明!?K&R - なぜかイライラする。オリンピックのトップリーダーはこのスタイルがとても好きなようだが。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
MetaEditorの使いやすさについてのご提案です。
コンビナート 2017.09.28 15:15
ついでに言うと、MEで もう一つ厄介なのは、レジスター依存のオートコンプリート です。
優れたエディタでは、大文字と小文字を区別しないので、生活が楽になります。
好きなように扱っていいんだよ。私は、万人に喜んでもらえるような100円札ではありません。
重要なのは、私が意見を言ったことで、それが聞き入れられ、考慮される可能性があることです。
すでに以前の機会に述べたことだが、新しい視聴者のためにもう一度言っておこう。
客観的に見ると、スタイルにはデファクトスタンダードが存在します。現在(そして過去10年)、C++/Javaのような構文を持つ言語には、主に2つのものしかありません。これらのスタイルは、Combinatorが声優を務めた。ソフトウェア業界の大半の企業で使用されている。これらは、実績があり、試行錯誤され、論理的で理解しやすく、プロのコーダーの 大多数にとってなじみのあるものです。
メリットもなく、欠点ばかりが目立つ他のものを普及させようとしても、それは失敗です。この欠点を認めないのは、頑固以外の何物でもない。客観的である。MQ自体がこのスタイルを使いこなし、ハマっているのは明らかですが、これもバグとしか言いようがないですね。このように、ソフトウェアが既知のバグの修正を拒否し、「この誤った動作にひっかかったサードパーティ製品がすでにたくさんある」と言うことがあります。現実には、このような場合、後方互換性のために古い動作を残し、いわゆる「プロトコルアップグレード」またはフォークで修正を行うことができる解決策を探す必要があるのです。スタイルの文脈では、クローン可能なスタイラスという シンプルなソリューションがあります。もう100回くらいやってもいいくらいです。
ところで、MQスタイルの問題は、ブラケットだけでなく、コメントのスタイルを 懸念- 彼らは定義によって、現在観察されているコードを、優先することは できません。
コメントについて付け加えると、どんなオートドキュメントシステムで処理しようとしても、失望することになるでしょう。
では、あのスマートさは何だったのか?
br-r-r-r、私はスペースとカンマのないコードの例をあげました。
はアンダースコアを削除してください。
br-r-r-r、私はスペースとカンマのないコードの例をあげました。
アンダースコアを取り除く
自分で「吐く」ことを許しているんですね。
ロシュ ギャグの何が問題なんだ?私も、MQスタイルは、そう言って嫌味を言っているのでしょうか?
コドベースを好きなようにフォーマットして、コードを読み込むときに自動的に行うこともでき、コーダーに負担をかけません。私は、コードを書き、MQ用にスタイルを整え、新しい名前で保存し、レビューのためにアップロードする、ということを思い出しています。そして、スタイリングをキャンセルして、執筆を続けるのです。ナンセンスじゃないですか?
カスタマイズできるスタイリストの リソースがない。誰かが合わせているわけではないんです。
しかし、なぜ十字架を背負い、自分の信仰が正しいものであると(全く論拠なく!)皆に言いに行くのでしょうか?