MetaEditorの使いやすさへの提案

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用にスタイルを整え、新しい名前で保存し、レビューのためにアップロードする、ということを思い出しています。そして、スタイリングをキャンセルして、執筆を続けるのです。ナンセンスじゃないですか？

カスタマイズできるスタイリストのリソースがない。誰かが合わせているわけではないんです。
しかし、なぜ十字架を背負い、自分の信仰が正しいものであると（全く論拠なく！）皆に言いに行くのでしょうか？

MetaEditorの使いやすさへの提案 - ページ 6