構造のルール プログラムの構成方法を学び、可能性、エラー、解決策などを探る。

[Vladimir Gomonov]

特にプロジェクトが 大きくなると、プログラム構造が不格好になり、開発が途方もなく困難になることがよくあります。 ここでは、プロジェクトの構造化に関するあらゆる問題を議論することを提案します。

最もシンプルなプログラムから複雑なソフトウェアパッケージまで。

--

プロはぜひこのスレッドを応援してください。

テーマの大きさとその「宗教性」(*)、その結果として起こりうる枝葉の混乱や対立は理解しています。

しかし、私は、誰もが恩恵を受けることができるように、サポートをお願いします。賢明な（可能性の高い）アイデアは、しばしばゴミの山から見つかるもので、人はただ気づくことができ、やがて「手に入れる」ことができるようになります。

----

(*) ここでいう「宗教的なもの」とは、プログラマがしばしば習慣や伝統、文学的な資料に基づいてプログラム構造を構築し、常識や自分や他の人（たとえば将来の共同執筆者）にとって本当に便利なものを期待することは全くないという事実を理解することである。

[Rustamzhan Salidzhanov]

先着順です :)まずは、あなたにとってそれがどのようなものなのか、教えてください。

[Vladimir Gomonov]

バグ、バグ、質問」スレッドより。

A100 2013.07.22 14:00 # 

MetaDriver。

構造のルールコンテンツは二の次、構造は一の次。

私の「パネル」は、イベント→ハンドリングという最もシンプルな構造になっています。

イベントも、ボタン押下、リスト選択、カレンダー選択、マウス操作など、シンプルなものばかりです。

あるプログラムのイベント処理をどのように整理（構造化）すれば、そのプログラム（プログラム）をさらに発展させることができ、同時に、すでに行われたことの手直しを最小限に抑えられるか、というのが、設計を始める際の典型的な問題です。

オプションのご相談は？

[Mykola Demko]

MetaDriver:
バグ、バグ、質問」ブランチから。

設計の初歩で非常に典型的な問題、つまり、プログラムのイベントの処理をどのように整理（構造化）すれば、そのプログラム（プログラム）をさらに発展させることができ、同時に、すでに行われたことを最小限にやり直すことができるかということである。

オプションのご相談は？

たとえば、こんな文献はありませんか？

一般に、設計上の問題は、CADや TRIZと 重なる。

私は紙に描くので、その方が都合がいいのですが、明確な構造ができるまで50枚くらいかかることもあります。spets.editorで確かにできますが、私のためにそれらの各々は、（限られた）不快、空想の飛行を実現することは不可能、要するに、仕事を遅らせる。

[A100]

最もシンプルなオプションがある

int main()
{
        while ( !IsStopped() )
        {
                switch ( GetEvent() ) {
                case TIMER   :
                case BUTTON  :
                case LISTVIEW:
                case CALENDAR:
                case CLOSE   :
                case ERROR   :
                default      :
                }
        }
}

[Alexandr Bryzgalov]

MetaDriver:

構造とは何か？

ZS: 私はこのように教わりました。

1.関数でできることは、すべて関数の中にある。

2.ゴトは罪である

3.すべての条件が最低限であり、1つの条件に重複がないこと。

4.3.インデント

5.自分の後に他の人が読めるような書き方をしなければならない。

6. 明確で意味のある変数名

7.コメント、でもやりすぎは禁物

こんな感じですが、こんな感じではありません： http://korzh.net/2011-03-pravila-xoroshego-tona-v-programmirovanii.html

[Alexandr Bryzgalov]

Urain:

たとえば、こんな文献はありませんか？

一般に、設計上の問題は、CADや TRIZと 重なる。

紙に描いた方が便利なので、時には50枚ほど使って、明確な構造が浮かび上がってくるようにします。もちろん、専用のエディタを使うこともできますが、どれも私にとっては不便（限定的）であり、思い切ったことが実現できない、要するに作業のスピードが落ちてしまうのです。

CADは全く同じではありませんが、コンピュータ支援設計のことです。

プログラムを書く前に、紙にアウトラインを作る、簡易アルゴ言語を教わったが、慣れない。

[Vladimir Gomonov]

FAQ:
先着順です :)まずは、あなたにとってそれがどのようなものなのか、教えてください。

まあ、そうだろうなとは思っていたのですが...。))

OK、（構成上）特に隠すことはない、ディスカッションは怖くない。

しかし、すぐに決めつけたり、急いで批判したりすることはお勧めしません。私は自分の判断に「模範的な」、あるいはどんな種類の調和も想定していません。その質量において、それらは特に根拠がなく、同じ「宗教」要因-習慣、「本の真実」、フォーラムの記事、標準的な端末配信のサンプル、その他頭の中に自然に集約されたゴミ-によって生成されています。 いくつかの発見はありますが、それほど深刻なものではありません。

まず始めに、混乱が少なくなるように、便利な用語をいくつか提案したいと思います（たくさんあると思いますが）。

1) 物理的なプロジェクトの 構造： ファイルやフォルダーなど、プロジェクトの "外 "から見えるものの構成。

2) 論理的なプロジェクト構造：変数、関数、クラス、プロトコルなど、すべての「内部」ソフトウェアの組織化。

-----------------

私のmql-projectの物理的な構造は、非常にシンプルで原始的なものです。私は意識的にそうすることで、混乱を減らし、起こりうる混乱の結果を最小限に抑えようとしているのです。

原則として（中規模なものは）.mqhファイルのセット（適切なフォルダに配置）＋mq5ファイル1つです。

// システムがマルチスレッドである場合（例えば、最も単純なケースでは、Expert Advisor +指標） - mq5-files の数は、プロジェクト内のプログラムの数に対応します。

私は、(.ex5)ライブラリは使わないようにしています。 // 非常に議論のある決定ですが、ランタイムの問題を最小限にするためにそうしています。

--

論理的なプロジェクト構造についてのコメントは、ひとまず控えさせていただきます。このテーマは非常に大きいので、息抜きが必要です...。:)

[Mykola Demko]

sanyooooook:

CADはちょっと違いますが、コンピュータ支援設計のことです。

プログラムを書く前に、簡略化したアルゴ言語をスケッチすることを教わったが、慣れることはなかった。

問題の全体像を可視化し、問題を構成する主要なオブジェクトを特定するようにしています。

そして、オブジェクトを構成要素に分解し、構成要素の交わりを探すと、祖先オブジェクトが現れます。

そういうものなんです。

もし、プロジェクトの中で、すでに遭遇したことのあるエンティティを見つけたら、古い検証済みのコードを使うようにしています。

デザインのことなら、ケンカをやめてMQスタイルを採用すれば、スタイラーの ボタンを1回クリックするだけで、すべてのスタイルが統一され、誰もが理解できるようになるのです。

[A100]

MetaDriver:

libs (.ex5) は使わないようにしています。 // 非常に議論のある解決策ですが、ランタイムの問題を最小限にするためにそうしています。

ライブラリを使わないということは、.dllを使わないということであり、後者を使えば、MQL4とMQL5で同時に使えるので、コード量も節約できる

[Alexandr Bryzgalov]

Urain:

タスクの全体像をイメージし、そのタスクを構成する主要なオブジェクトを特定するようにしています。

そして、オブジェクトを構成要素に分割し、構成要素の交点を探すと、祖先オブジェクトが現れるのです。

そういうものなんです。

以前見たことのあるオブジェクトの実体をプロジェクトで見つけたら、古い検証済みのコードを入れるようにしています。

あなたはオブジェクト指向で考え、私は機能指向で考える )