OOPと手続き型プログラミングの比較 - ページ 11 1...456789101112131415161718...48 新しいコメント Georgiy Merts 2017.08.12 10:10 #101 Реter Konow:私の考えでは、あなたの問題解決システムには欠陥があります。問題そのものが明確で正確であるべきであり、それゆえその解決策も明確でなければならない。という言葉で定義されるような曇った解答であれば（270kbのコードでどうして合理的なのか！）、作者は自分のシステムの仕組みをおおよそ理解していることになる。そして、解答の中にある構文や余分な存在の仕掛けが怖くて、最後まで理解できないのだそうです。 合理性は「予測力」にある - 作業プロトコルの大幅な変更は、作業の論理に責任を持つ専門家の規範を変更する必要はなかった。コードの修正は、端末を直接低レベルで処理する箇所のみでした。このコードは、すべてのOOPハックが「関数ハック」にうまく置き換えられることを非常によく示しています。つまり、まさに私が上で言っていたように、どちらにも書くことができるのです。 しかし、あなたのコードを見ると、もっと多くのことをメモリに保持しなければならないことがわかります。セイ、あなたのifのほとんどで、私は一瞬で「溺死」しています。しかし、もし私がこのコードを保守しなければならないとしたら、各条件の前に、このチェックは何をするのか、なぜこれらのフィールドが配列で使用されるのか、というコメントを数行挿入するでしょう。私のコードでCTradePositionIインターフェイスを宣言する前のコメントと同様です。それに、複雑な条件も、個人的には大きなストレスになります。個人的には、あなたのコードのミスが増え、それをキャッチするのが難しくなると思います。つまり、このようなコードは、正しいロジックであるにもかかわらず、私がOOPスタイルですべてを書いた場合よりもメンテナンスが難しくなるのです。 OOPスタイルでは、ウィンドウ、キャンバスのパーツ、エレメント、キャンバスのインターフェースを宣言し、それらのオブジェクトの実際のクラスを書き、適切なブロック内でそれらのインターフェースへのポインタを出し、その時点で必要とされるエンティティに特化して作業を行います - 他のすべてはその時点では使用できません。これは、何が何に属しているか、何に責任があるかを覚えておく必要がないようにするためです。いくつかの機能からなる最もシンプルなインターフェースを手に入れると、それだけで作業をしてしまい、あとは不要で手に入らないということになるのです。何も覚える必要は全くありません。 Alexey Volchanskiy 2017.08.12 10:19 #102 George Merts:まあ、散々な目に遭わされたわけですが...。インタフェースの割り当て、継承階層の構築、仮想関数の 宣言といったOOPスタイルと、すべてを1つの巨大な関数に集約する純粋な手続きスタイルの両方で、どんなタスクも解決できることは明らかです。 問題は、サポートの利便性と効率性にあります。MTの場合 - 最もOOPに適した場所は、オーダーシステムです。個人的には、「位置」と「位置成分」の仮想インターフェイスを持っています。"ポジション "は、MT4では注文のセット、MT5ではポジションのセットです。「ポジションコンポーネント」とは、個別の注文または個別の MT5 ポジション（ヘッジまたはネッティング）です。 実際のインターフェイスファイルはこちら（リタグコノウ、コードの量に比べてコメントの数が多いのがおわかりいただけると思いますが、覚えていない微妙な部分に遭遇したときに、定期的にそこに追加しています）。例えば、どの実体が「位置成分」にあたるのか、日頃から忘れてしまっています。Expert Advisorはインターフェースに従ってコンポーネントを操作するので、現実にはそのインターフェースの背後にあるものは重要ではありません。しかし、私は修正中にそれに戻る必要があります - それが、このファイルの最初のコメントが非常に頻繁に必要な理由です）。トレードコンポーネントインターフェイスのファイルは以下の通りです（上記で既にあげていますが、繰り返します）。これらのインターフェイスに従って、私はMT4とMT5の両方の注文システムをリアルとヒストリカル両方の注文に実装しています。 ポジションを要求するExpert Advisorは、このインターフェースを受け取るため、MT4とMT5の注文の違いを考慮する必要はありません。また、新しい注文タイプが追加されたり、それらを扱う順序が変更されたりしても、エキスパートアドバイザーは何も変わらず、新しい注文タイプクラスだけが追加され、このインターフェースもサポートされます。 このシステムは、ヘッジ会計が導入されたときに、非常に巧妙であることが証明された。専門家たち - 絶対にそこから変わることはない。 Reg Konow さん、MT4とMT5で注文の種類が違うのは、どのように対処しているのでしょうか？ 新しい勘定科目が導入された場合（ヘッジとネッティングに加え）、同じ場所でどのような変更が必要ですか？ 私見ですが、もしあなたが自分のコードをすべて記憶していて、1年前のコードになぜこの行が書かれたのかを簡単に理解できるのであれば、これらのOOP-enhancersは不要なジェスチャーに過ぎないと思うのです。 OOPは、コードを修正する際にすべてを覚えていない場合にこそ必要です。OOPでは、ブロックを互いに分離して、任意の瞬間に利用できるエンティティ群をプログラム内の特定の場所に限定することができます。 ジョージさんは、時々、女性のことをこんな風に書いていらっしゃいますが、掟を守ってくださいね ))) Реter Konow 2017.08.12 10:33 #103 George Merts:合理性は「予測力」にある。操作プロトコルを大幅に変更しても、その操作のロジックを担当するEAコードの変更は必要なかった。端末を直接低レベルで扱う箇所のみ、コード修正を行いました。このコードは、すべてのOOPハックが「関数ハック」にうまく置き換えられることを非常によく示しています。つまり、まさに私が上で言っていたように、どちらにも書くことができるのです。 しかし、あなたのコードを見ると、もっと多くのことをメモリに保持しなければならないことがわかります。セイ、あなたのifのほとんどで、私は一瞬で「溺死」しています。しかし、もし私がこのコードを保守しなければならないとしたら、各条件の前に、このチェックは何をするのか、なぜこれらのフィールドが配列で使用されているのか、というコメントを数行挿入するでしょう。私のコードでCTradePositionIインターフェイスを宣言する前のコメントと同様です。それに、複雑な条件も、個人的には大きなストレスになります。個人的には、あなたのコードのミスが増え、それをキャッチするのが難しくなると思います。つまり、このようなコードは、その正しさや論理性の割には、OOPスタイルですべて書いた場合よりも、私にとってはサポートが難しくなってしまうのです。 OOPスタイルでは、ウィンドウ、キャンバスのパーツ、エレメント、キャンバスのインターフェースを宣言し、それらのオブジェクトの実際のクラスを書き、適切なブロック内でそれらのインターフェースへのポインタを出し、その時点で必要とされるエンティティに特化して作業を行います - 他のすべてはその時点では使用できません。これは、何が何に属しているか、何に責任があるかを覚えておく必要がないようにするためです。いくつかの機能からなる最もシンプルなインターフェースを手に入れると、それだけで作業をしてしまい、あとは不要で手に入らないということになるのです。何も覚えなくていいんです。私のコードでは、多数のフォントとそのネストは、異なるイベントや異なる状態での異なるコントロール定義の複雑な動作に起因しています。しかし、この機能はこれらのオプションをすべてカバーし、GUI全体を完全に「機能」させるものです。任意の要素を再描画する場合、その部分の色はカーネル内の元の色 値とこの関数で決定される。 追伸：OOPか手続き型かについては、「人それぞれ」(c)です。 Georgiy Merts 2017.08.12 11:14 #104 Alexey Volchanskiy: ジョルジュさんは、時々、女性についてこんな記事を書いていらっしゃいますが、掟を守って下さいね )))コードの件ですが、お世辞でも嬉しいですね。(本当に、冗談抜きで）。そして、ヒナについて...。私はあなたのようなカサノバではありません...私は、思っていることを我慢して言わない方なので...。その点では、昔から、そして今も、快適な私生活はとても大切なのですが......。時には運が微笑むこともあり、やはり思い出に残るものがあるのは良いことです。 Alexey Volchanskiy 2017.08.12 16:42 #105 George Merts:コードの件ですが、お世辞でも嬉しいですね。(本当に、冗談抜きで）。そして、女性について...。私はあなたのようなカサノバではありません...私が我慢して、思っていることを言わないから......。その点では、昔から、そして今も、快適な私生活はとても大切なのですが......。時には運が微笑むこともあり、やはり思い出に残るものがあるのは良いことです。 ただ、女性に対する考え方が違うだけなんです。助けるべきと思う。そう、彼らは不機嫌で、自分の屁理屈を言い、情熱が気まぐれである、などなど。ただ、真に受けないようにしないと、道徳的な悲劇が起きてしまう。 Dmitry Fedoseev 2017.08.12 16:53 #106 George Merts:まあ、散々な目に遭わされたわけですが...。インタフェースの割り当て、継承階層の構築、仮想関数の 宣言といったOOPスタイルと、すべてを1つの巨大な関数に集約する純粋な手続きスタイルの両方で、どんなタスクも解決できることは明らかです。 問題は、サポートの利便性と効率性にあります。 できるのですが、操作の効率にばらつきがあります。ここではサポートの話ではなく、あまりにも相対的な話です。手続き上、最適な方法で解決できないタスクがあります。 Dmitry Fedoseev 2017.08.12 16:55 #107 Alexey Volchanskiy: 女性に対する考え方が違うだけです。助けるべきと思う。そう、彼らは不機嫌で、癖があり、気まぐれな嗜好品などだ。ただ、真に受けないようにしないと、道徳的な悲劇が起きてしまう。アレクセイ、女性の「助けてほしい」という気持ちがどれだけ果てしなく続くか、実験してみた？ヘルプの満足感に出会えたか、またその期間は？ Alexey Navoykov 2017.08.12 17:34 #108 Реter Konow: データの保存に構造体を使うこともないんですね？多次元配列は、構造体がないためにそのようなソリューションを使わなければならなかった昔のMQL4の記憶を呼び起こします。しかし、今はどうなんでしょう。例えば int Элемент = G_CORE[Окно][Деталь_полотна][_MAIN_ELEMENT]; int Состояние_детали = G_CORE[Окно][Элемент][_CURRENT_STATE]; で置き換えることができます。 int Элемент = G_CORE[Окно][Деталь_полотна].MAIN_ELEMENT; int Состояние_детали = G_CORE[Окно][Элемент].CURRENT_STATE; より短く、より安全に、より速くを実現しました。最初のケースでは、コンパイル時に渡された配列インデックスの値を制御することはできません。そして、実行時にさまざまな「配列の範囲外」をクリーンアップしなければならない--これがせいぜいのところです。さらに悪いのは、インデックスが許容範囲内であっても不正確な場合です。そのため、コンパイラをできるだけ活用し、コンパイル段階でエラーを検出し、今回のような実行時にエラーを検出しないようにすることが、良いプログラミングプラクティスと言えます。そうですね、今はどの値をどこに食べさせたらいいかを覚えるのが得意なんですね。でもこれは、このプロジェクトで常に忙しくしているからでしょう。例えば半年間、休んでみると、その違いが実感できるはずです。すでに何人かの方がおっしゃっています。それとも、私たちが皆、硬化症か何かだと思っているのですか？:)プログラマーにありがちなことですが...。だから、自分の足を撃つ確率を最小限にすることが課題なのです。私は、どこにでもあるint型ではなく、enum型を使って独自の型を作ることを強くお勧めします。また、必ずしも列挙された値を持つ必要はなく、独立した別の型であることが主であり、コンパイラによって制御され、関数の引数を入れ替えることなどはできないでしょう。 Yuriy Asaulenko 2017.08.12 17:39 #109 私は、もっぱらOOPで書いています。1900年代の頃は、Pascal 6.0、そしてBorland C++ 4.5と、なかなか手が出ませんでした。でも、使いこなせたら他には考えられない。それくらい簡単で便利なんです。 Реter Konow 2017.08.12 17:54 #110 Alexey Navoykov:データの保存に構造体を使うこともないんですね？多次元配列は、構造体がないためにそのようなソリューションを使わなければならなかった昔のMQL4の記憶を呼び起こします。しかし、今はどうなんでしょう。例えばで置き換えることができます。より短く、より安全に、より速くを実現しました。最初のケースでは、コンパイル時に渡された配列インデックスの値を制御することはできません。そして、実行時にさまざまな「配列の範囲外」をクリーンアップしなければならない--これがせいぜいのところです。さらに悪いのは、インデックスが許容範囲内であっても不正確な場合です。そのため、コンパイラをできるだけ活用し、コンパイル段階でエラーを検出し、今回のような実行時にエラーを検出しないようにすることが、良いプログラミングプラクティスと言えます。そうですね、今はどの値をどこに食べさせたらいいかを覚えるのが得意なんですね。でもこれは、このプロジェクトで常に忙しくしているからでしょう。例えば半年間、休んでみると、その違いが実感できるはずです。すでに何人かの方がおっしゃっています。それとも、私たちが皆、硬化症か何かだと思っているのですか？:)プログラマーにありがちなことですが...。だから、自分の足を撃つ確率を最小限にすることが課題なのです。私は、どこにでもあるint型ではなく、enum型を使って独自の型を作ることを強くお勧めします。また、列挙された値を持つ必要はなく、独立した別の型であることが主で、コンパイラによって制御され、関数の引数を入れ替えたりすることはできないでしょう。他のスレッドでの書き込みを読んで、あなたがプログラミングの大御所であることが分かりました。もちろん、私はそうではないし、そうであると主張するものでもない。しかし、私はそのような課題解決のスペシャリストであると自負しています。まあ、ソリューションの有効性が最も重要だということには同意できないか。 構文の過負荷やルールの複雑さは、ソリューションの効率性を保つことに貢献したことはありません。それは、コードブロックの簡潔さ、普遍性、可読性で表現されるシンプルさ、簡潔さであった。 プログラミングにおける私のルールは、ネイティブ言語と意味のある変数名や関数名を使うことを犠牲にして、コードを少なく、ルールを少なく、構文を少なく、コメントを少なくすることです。 私の最大のテーゼは、「ソリューションの中で、何かなくても済むものは、絶対にない方がいい」ということです。 ここには硬派な人は全くいないと思います))。なぜ忘れられやすいかは、与えられたコードを見れば一目瞭然です。外国語でプログラミングをするということ自体も、その一端を担っています。自国語でプログラミングすると、絶対に違和感がある。緊張や束縛ではなく、パワーや自由を感じることができるのです。外国語は努力が必要で、コードに落とし込むのに時間がかかり、頭から抜け落ちるのも早い。あくまでも「生物学的な要因」です。 したがって、私は自分の仕事を解決するために、一般的なOOPを使うのは（極めて合理的に）非効率的だと考えています。たくさんのルール、構文、そして全ては外国語。そうすると、才能が本当の意味で育たないので、結果的に貧乏くじを引くことになるのです。 1...456789101112131415161718...48 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
私の考えでは、あなたの問題解決システムには欠陥があります。問題そのものが明確で正確であるべきであり、それゆえその解決策も明確でなければならない。という言葉で定義されるような曇った解答であれば（270kbのコードでどうして合理的なのか！）、作者は自分のシステムの仕組みをおおよそ理解していることになる。そして、解答の中にある構文や余分な存在の仕掛けが怖くて、最後まで理解できないのだそうです。
合理性は「予測力」にある - 作業プロトコルの大幅な変更は、作業の論理に責任を持つ専門家の規範を変更する必要はなかった。コードの修正は、端末を直接低レベルで処理する箇所のみでした。
このコードは、すべてのOOPハックが「関数ハック」にうまく置き換えられることを非常によく示しています。つまり、まさに私が上で言っていたように、どちらにも書くことができるのです。
しかし、あなたのコードを見ると、もっと多くのことをメモリに保持しなければならないことがわかります。セイ、あなたのifのほとんどで、私は一瞬で「溺死」しています。しかし、もし私がこのコードを保守しなければならないとしたら、各条件の前に、このチェックは何をするのか、なぜこれらのフィールドが配列で使用されるのか、というコメントを数行挿入するでしょう。私のコードでCTradePositionIインターフェイスを宣言する前のコメントと同様です。それに、複雑な条件も、個人的には大きなストレスになります。
個人的には、あなたのコードのミスが増え、それをキャッチするのが難しくなると思います。つまり、このようなコードは、正しいロジックであるにもかかわらず、私がOOPスタイルですべてを書いた場合よりもメンテナンスが難しくなるのです。
OOPスタイルでは、ウィンドウ、キャンバスのパーツ、エレメント、キャンバスのインターフェースを宣言し、それらのオブジェクトの実際のクラスを書き、適切なブロック内でそれらのインターフェースへのポインタを出し、その時点で必要とされるエンティティに特化して作業を行います - 他のすべてはその時点では使用できません。これは、何が何に属しているか、何に責任があるかを覚えておく必要がないようにするためです。いくつかの機能からなる最もシンプルなインターフェースを手に入れると、それだけで作業をしてしまい、あとは不要で手に入らないということになるのです。何も覚える必要は全くありません。
まあ、散々な目に遭わされたわけですが...。
インタフェースの割り当て、継承階層の構築、仮想関数の 宣言といったOOPスタイルと、すべてを1つの巨大な関数に集約する純粋な手続きスタイルの両方で、どんなタスクも解決できることは明らかです。
問題は、サポートの利便性と効率性にあります。
MTの場合 - 最もOOPに適した場所は、オーダーシステムです。個人的には、「位置」と「位置成分」の仮想インターフェイスを持っています。"ポジション "は、MT4では注文のセット、MT5ではポジションのセットです。「ポジションコンポーネント」とは、個別の注文または個別の MT5 ポジション（ヘッジまたはネッティング）です。
実際のインターフェイスファイルはこちら（リタグコノウ、コードの量に比べてコメントの数が多いのがおわかりいただけると思いますが、覚えていない微妙な部分に遭遇したときに、定期的にそこに追加しています）。例えば、どの実体が「位置成分」にあたるのか、日頃から忘れてしまっています。Expert Advisorはインターフェースに従ってコンポーネントを操作するので、現実にはそのインターフェースの背後にあるものは重要ではありません。しかし、私は修正中にそれに戻る必要があります - それが、このファイルの最初のコメントが非常に頻繁に必要な理由です）。
トレードコンポーネントインターフェイスのファイルは以下の通りです（上記で既にあげていますが、繰り返します）。
これらのインターフェイスに従って、私はMT4とMT5の両方の注文システムをリアルとヒストリカル両方の注文に実装しています。
ポジションを要求するExpert Advisorは、このインターフェースを受け取るため、MT4とMT5の注文の違いを考慮する必要はありません。また、新しい注文タイプが追加されたり、それらを扱う順序が変更されたりしても、エキスパートアドバイザーは何も変わらず、新しい注文タイプクラスだけが追加され、このインターフェースもサポートされます。
このシステムは、ヘッジ会計が導入されたときに、非常に巧妙であることが証明された。専門家たち - 絶対にそこから変わることはない。
Reg Konow さん、MT4とMT5で注文の種類が違うのは、どのように対処しているのでしょうか？
新しい勘定科目が導入された場合（ヘッジとネッティングに加え）、同じ場所でどのような変更が必要ですか？
私見ですが、もしあなたが自分のコードをすべて記憶していて、1年前のコードになぜこの行が書かれたのかを簡単に理解できるのであれば、これらのOOP-enhancersは不要なジェスチャーに過ぎないと思うのです。
OOPは、コードを修正する際にすべてを覚えていない場合にこそ必要です。OOPでは、ブロックを互いに分離して、任意の瞬間に利用できるエンティティ群をプログラム内の特定の場所に限定することができます。
ジョージさんは、時々、女性のことをこんな風に書いていらっしゃいますが、掟を守ってくださいね )))
合理性は「予測力」にある。操作プロトコルを大幅に変更しても、その操作のロジックを担当するEAコードの変更は必要なかった。端末を直接低レベルで扱う箇所のみ、コード修正を行いました。
このコードは、すべてのOOPハックが「関数ハック」にうまく置き換えられることを非常によく示しています。つまり、まさに私が上で言っていたように、どちらにも書くことができるのです。
しかし、あなたのコードを見ると、もっと多くのことをメモリに保持しなければならないことがわかります。セイ、あなたのifのほとんどで、私は一瞬で「溺死」しています。しかし、もし私がこのコードを保守しなければならないとしたら、各条件の前に、このチェックは何をするのか、なぜこれらのフィールドが配列で使用されているのか、というコメントを数行挿入するでしょう。私のコードでCTradePositionIインターフェイスを宣言する前のコメントと同様です。それに、複雑な条件も、個人的には大きなストレスになります。
個人的には、あなたのコードのミスが増え、それをキャッチするのが難しくなると思います。つまり、このようなコードは、その正しさや論理性の割には、OOPスタイルですべて書いた場合よりも、私にとってはサポートが難しくなってしまうのです。
OOPスタイルでは、ウィンドウ、キャンバスのパーツ、エレメント、キャンバスのインターフェースを宣言し、それらのオブジェクトの実際のクラスを書き、適切なブロック内でそれらのインターフェースへのポインタを出し、その時点で必要とされるエンティティに特化して作業を行います - 他のすべてはその時点では使用できません。これは、何が何に属しているか、何に責任があるかを覚えておく必要がないようにするためです。いくつかの機能からなる最もシンプルなインターフェースを手に入れると、それだけで作業をしてしまい、あとは不要で手に入らないということになるのです。何も覚えなくていいんです。
私のコードでは、多数のフォントとそのネストは、異なるイベントや異なる状態での異なるコントロール定義の複雑な動作に起因しています。しかし、この機能はこれらのオプションをすべてカバーし、GUI全体を完全に「機能」させるものです。任意の要素を再描画する場合、その部分の色はカーネル内の元の色 値とこの関数で決定される。
追伸：OOPか手続き型かについては、「人それぞれ」(c)です。
ジョルジュさんは、時々、女性についてこんな記事を書いていらっしゃいますが、掟を守って下さいね )))
コードの件ですが、お世辞でも嬉しいですね。(本当に、冗談抜きで）。
そして、ヒナについて...。私はあなたのようなカサノバではありません...私は、思っていることを我慢して言わない方なので...。その点では、昔から、そして今も、快適な私生活はとても大切なのですが......。時には運が微笑むこともあり、やはり思い出に残るものがあるのは良いことです。
コードの件ですが、お世辞でも嬉しいですね。(本当に、冗談抜きで）。
そして、女性について...。私はあなたのようなカサノバではありません...私が我慢して、思っていることを言わないから......。その点では、昔から、そして今も、快適な私生活はとても大切なのですが......。時には運が微笑むこともあり、やはり思い出に残るものがあるのは良いことです。
ただ、女性に対する考え方が違うだけなんです。助けるべきと思う。そう、彼らは不機嫌で、自分の屁理屈を言い、情熱が気まぐれである、などなど。ただ、真に受けないようにしないと、道徳的な悲劇が起きてしまう。
まあ、散々な目に遭わされたわけですが...。
インタフェースの割り当て、継承階層の構築、仮想関数の 宣言といったOOPスタイルと、すべてを1つの巨大な関数に集約する純粋な手続きスタイルの両方で、どんなタスクも解決できることは明らかです。
問題は、サポートの利便性と効率性にあります。
できるのですが、操作の効率にばらつきがあります。ここではサポートの話ではなく、あまりにも相対的な話です。
手続き上、最適な方法で解決できないタスクがあります。
女性に対する考え方が違うだけです。助けるべきと思う。そう、彼らは不機嫌で、癖があり、気まぐれな嗜好品などだ。ただ、真に受けないようにしないと、道徳的な悲劇が起きてしまう。
アレクセイ、女性の「助けてほしい」という気持ちがどれだけ果てしなく続くか、実験してみた？ヘルプの満足感に出会えたか、またその期間は？
データの保存に構造体を使うこともないんですね？多次元配列は、構造体がないためにそのようなソリューションを使わなければならなかった昔のMQL4の記憶を呼び起こします。しかし、今はどうなんでしょう。例えば
で置き換えることができます。
より短く、より安全に、より速くを実現しました。最初のケースでは、コンパイル時に渡された配列インデックスの値を制御することはできません。そして、実行時にさまざまな「配列の範囲外」をクリーンアップしなければならない--これがせいぜいのところです。さらに悪いのは、インデックスが許容範囲内であっても不正確な場合です。そのため、コンパイラをできるだけ活用し、コンパイル段階でエラーを検出し、今回のような実行時にエラーを検出しないようにすることが、良いプログラミングプラクティスと言えます。
そうですね、今はどの値をどこに食べさせたらいいかを覚えるのが得意なんですね。でもこれは、このプロジェクトで常に忙しくしているからでしょう。例えば半年間、休んでみると、その違いが実感できるはずです。すでに何人かの方がおっしゃっています。それとも、私たちが皆、硬化症か何かだと思っているのですか？:)プログラマーにありがちなことですが...。
だから、自分の足を撃つ確率を最小限にすることが課題なのです。私は、どこにでもあるint型ではなく、enum型を使って独自の型を作ることを強くお勧めします。また、必ずしも列挙された値を持つ必要はなく、独立した別の型であることが主であり、コンパイラによって制御され、関数の引数を入れ替えることなどはできないでしょう。
私は、もっぱらOOPで書いています。
1900年代の頃は、Pascal 6.0、そしてBorland C++ 4.5と、なかなか手が出ませんでした。でも、使いこなせたら他には考えられない。それくらい簡単で便利なんです。
データの保存に構造体を使うこともないんですね？多次元配列は、構造体がないためにそのようなソリューションを使わなければならなかった昔のMQL4の記憶を呼び起こします。しかし、今はどうなんでしょう。例えば
で置き換えることができます。
より短く、より安全に、より速くを実現しました。最初のケースでは、コンパイル時に渡された配列インデックスの値を制御することはできません。そして、実行時にさまざまな「配列の範囲外」をクリーンアップしなければならない--これがせいぜいのところです。さらに悪いのは、インデックスが許容範囲内であっても不正確な場合です。そのため、コンパイラをできるだけ活用し、コンパイル段階でエラーを検出し、今回のような実行時にエラーを検出しないようにすることが、良いプログラミングプラクティスと言えます。
そうですね、今はどの値をどこに食べさせたらいいかを覚えるのが得意なんですね。でもこれは、このプロジェクトで常に忙しくしているからでしょう。例えば半年間、休んでみると、その違いが実感できるはずです。すでに何人かの方がおっしゃっています。それとも、私たちが皆、硬化症か何かだと思っているのですか？:)プログラマーにありがちなことですが...。
だから、自分の足を撃つ確率を最小限にすることが課題なのです。私は、どこにでもあるint型ではなく、enum型を使って独自の型を作ることを強くお勧めします。また、列挙された値を持つ必要はなく、独立した別の型であることが主で、コンパイラによって制御され、関数の引数を入れ替えたりすることはできないでしょう。
他のスレッドでの書き込みを読んで、あなたがプログラミングの大御所であることが分かりました。もちろん、私はそうではないし、そうであると主張するものでもない。しかし、私はそのような課題解決のスペシャリストであると自負しています。まあ、ソリューションの有効性が最も重要だということには同意できないか。
構文の過負荷やルールの複雑さは、ソリューションの効率性を保つことに貢献したことはありません。それは、コードブロックの簡潔さ、普遍性、可読性で表現されるシンプルさ、簡潔さであった。
プログラミングにおける私のルールは、ネイティブ言語と意味のある変数名や関数名を使うことを犠牲にして、コードを少なく、ルールを少なく、構文を少なく、コメントを少なくすることです。
私の最大のテーゼは、「ソリューションの中で、何かなくても済むものは、絶対にない方がいい」ということです。
ここには硬派な人は全くいないと思います))。なぜ忘れられやすいかは、与えられたコードを見れば一目瞭然です。外国語でプログラミングをするということ自体も、その一端を担っています。自国語でプログラミングすると、絶対に違和感がある。緊張や束縛ではなく、パワーや自由を感じることができるのです。外国語は努力が必要で、コードに落とし込むのに時間がかかり、頭から抜け落ちるのも早い。あくまでも「生物学的な要因」です。
したがって、私は自分の仕事を解決するために、一般的なOOPを使うのは（極めて合理的に）非効率的だと考えています。たくさんのルール、構文、そして全ては外国語。そうすると、才能が本当の意味で育たないので、結果的に貧乏くじを引くことになるのです。