なぜこのようなコードが多いのでしょうか? - ページ 3 1234 新しいコメント GreenMoney 2013.08.28 18:35 #21 RaptorUK:しかし、それは、もし彼らが構文や論理の助けを求めているのなら、そのコードは「...構文的にも論理的にも正しい;」ということにはならないのでは?はい、その通りです。しかし、より効果的な(あるいはより効果的でない)コーディングスタイル/プラクティスを議論する文脈では、最も重要な 点は、使用するコーディングスタイルに関係なく、コードが構文的および論理的に正しいということなのです。別の言い方をすれば、スタイルは構文的・論理的に正しいコードに道を譲らなければならないということでしょう。主な問題は、コードが見栄えが良いか、読みやすいかではなく、むしろ、そのコードが書かれたタスクを実行するために構文的・論理的に正しいかです :) また、//コメントについても同意します。コードの様々な部分の詳細について、元のプログラマの頭をリフレッシュさせ、完成後や実装後のコードの理解を助けるために、 // コメントは多いに越したことはないのです。 Simon Gniadkowski 2013.08.28 18:49 #22 Thirteen: はい、おっしゃるとおりです。 しかし、効果的なコーディングスタイル/プラクティスを議論する文脈では、最も重要な側面は、使用するコーディングスタイルにかかわらず、コードが構文的および論理的に正しいということです。 別の言い方をすれば、スタイルは構文的、論理的に正しいコードに道を譲らなければならないということです。主な問題は、コードがよく見えるか、読みやすいかではなく、むしろ、そのコードが書かれたタスクを実行するために構文的、論理的に正しいかです。) ああ、なるほど、言いたいことはわかりました ... 美しく表現されたコードでも、動かなければ意味がありません ... でも、もしかしたら修正するのは簡単かもしれませんね? GreenMoney 2013.08.28 19:12 #23 RaptorUK: ああ、なるほど、そういうことだったんですね。 そうですね。言い換えれば、コーディングスタイルやプレゼンテーションの方法は、プログラマが選択するものであり、目的(目的は構文的・論理的に正しいコード)に対する手段なのです :) プログラマが(その後、そのコードを書いていない他の人が)簡単に読んで理解できるコードであれば、構文的・論理的エラーを発見し修正することはずっと簡単です。 Ian Venner 2013.08.29 04:44 #24 私は、自分のコードが完成して作業しているときは閉じますが、共有したり議論したりする必要があるときは、数行のスペースを空けて開き直したりするのは簡単です。私は、コーディングフォーマットは、欠落しているブレースを簡単に識別できること、複数の枝を持つ複雑なif elseツリーがある場合、if elseペアを簡単に識別できることをサポートするべきだと思います。私はK&Rスタイルを採用したことがないので、K&Rスタイルのコーダーが どのように行っているかを見てみたいです。 ydrol 2013.08.29 05:15 #25 SDC:私は、自分のコードが完成して動作しているときは閉じますが、それを共有したり議論したりする必要があるときは、数行のスペースで簡単に開き直せます。なぜクローズアップするのか?私は、コードを閉じてしまうことの意味がよくわかりません。共有したり議論したりするために開く必要があるのなら、それは何を意味するのでしょうか? SDC: 私は、コーディングフォーマットは、欠落しているブレースを簡単に識別できること、複数の枝を持つ複雑なif elseツリーがある場合に、if elseペアを簡単に識別できることをサポートするべきだと思います。私はK&R方式を採用したことがないので、K&R方式のコーダーがどのように行っているかを見てみたいです。K&Rスタイルの場合、下のブレースはコンディションのマッチングに合わせます。私自身は 1.一貫したインデント 2.1文節の場合は、 ブレースとインデント、またはブレースなしの条件文に続くようにする。 if (flag) { i++; } OR if (flag) i++; 3.3. 中括弧のマッチングが可能なプログラマーズエディタを使用する。 中括弧のマッチングは問題ありません。Linuxカーネルは ほとんどこのスタイルで書かれていますし、Javaの標準でもあります。でも、K&Rスタイルでは、条件の後に余分な空行を挿入してコードをすっきりさせることが多かったので、Allmanスタイルの魅力はわかります。うーん、改心したかも(笑)。 Ian Venner 2013.08.29 13:18 #26 ydrol: なぜクローズアップするのか?私は、潰れたコードの意味がよくわかりません。もし、共有/議論するためにそれを開く必要がある場合、それは何を意味するのでしょうか? K&Rスタイルの場合、ボトムブレースはコンディションマッチングで揃えます。私自身は 1.一貫したインデント 2.1文節の場合は、 ブレースとインデント、またはブレースなしの条件文に続くようにする。 3.3. 中括弧のマッチングが可能なプログラマーズエディタを使用する。 中括弧のマッチングは問題ありません。Linuxカーネルはほとんどこのスタイルで書かれていますし、Javaの標準でもあります。でも、K&Rスタイルでは、条件の後に余分な空行を挿入してコードをすっきりさせることが多かったので、Allmanスタイルの魅力はわかります。うーん、改心したかも(笑)。 私はただ、画面スペースを取らないように閉じているだけです。画面に収まる範囲で同時に見たいんだ。ブレースマッチャーは必要なくて、ブレースの後ろにカーソルを置いて、矢印キーで行の上に垂直に動かすと、他のブレースに触れたときにそのブレースがペアになるようにフォーマットしています。 このコードでは、3番目のelseが最初のifとペアになり、2番目のelseが2番目のifとペアになり、最初のelseが3番目のifとペアになることが簡単に分かります。同様に、どのifがelseを持たないかは、elseの後ろのクラスタで、それぞれのifブレースが対応する閉じブレースと垂直に並ぶので、簡単にわかります。私が好きだからといって、他の人もこの方法でコードを書けとは 言いませんが、私にとってはコンパクトで論理的な方法なのです。 if(downtrend) {if(High[i] < LineDownBuffer[i+1]) {if(DeMarkerHighBuffer[i] > LineDownBuffer[i+1]) {LineDownBuffer[i] = LineDownBuffer[i+1]; }else {if(DeMarkerHighBuffer[i] < LineDownBuffer[i+1]) {LineDownBuffer[i] = DeMarkerHighBuffer[i]; }}}else {if(High[i] > LineDownBuffer[i+1]) {LineDownBuffer[i] = LineDownBuffer[i+1]; LineUpBuffer[i] = DeMarkerLowBuffer[i]; downtrend = false; uptrend = true; }}}else Ubzen 2013.08.29 14:18 #27 SDC: 私は、自分のコードが完成して作業しているときは閉じますが、共有したり議論したりする必要があるときは、数行のスペースを空けて開き直せばいいのです。私は、コーディングフォーマットは、欠落しているブレースを簡単に識別できること、複数の枝を持つ複雑なif elseツリーが ある場合、if elseペアを簡単に識別できることをサポートすべきだと思います。私はK&Rスタイルを採用したことがないので、K&Rスタイルのコーダーがどのように行っているかを見てみたいです。k&rを使用するすべてのコーダーのために答えることはできません。正直なところ、あなたのフォーマットを見れば見るほど、私はそれが好きになりました。もし私がオールマン・スタイルを採用していたら、間違いなくあなたの修正版を使うことになるでしょうね。中括弧を互いの下に並べることで、開閉中括弧が1行を占めるのを防いでいます。また、タブやインデントのサイズを気にすることなく、コンパクトモード(画面上でコードのほとんどを見ることができる)で、ifの時にiの下にカーソルを走らせれば、足りない中括弧を見つけることができます。そう、これはとてもクールなことなのです。ただ、初見では、慣れていないせいか、混乱しているように見えました。そして、これが問題の核心です。 アメリカのコーダーの多くは[KnR & Allman]を採用しているようですが、ヨーロッパではWhitesmithsの スタイルが人気なようです。WhitesmithはMt4のDefaultスタイルでもあります。どのスタイルも間違ってはいないのですが、誰かを助けるときには、自分のK&Rスタイルを無視して、もっとWhitesmithを考えるように自分に言い聞かせる必要があります。それか、コードフォーマッターを使うか。 なぜ「複雑なif else木」を書きたがるのか、私には理解できません。誰かが複雑なif_nestの中にすべてのWhite_Spaceとフォーマットを残すと、ページを横切って蛇|スパゲッティ|ジグザグをデザインしようとしたように見えます。最初のifは1行目から300行目までで、そのうちの約150か50行が中括弧によって保持されています。複雑なif elseツリー」の代わりに、なぜ関数を作らないのでしょう。そして、if( false ){ return; }で実際に1行目を終了させればいいのです。 Ian Venner 2013.08.29 14:41 #28 ubzenさん、ありがとうございます。私はif elseをよく使います。おそらく、最初にコーディングを始めたとき、誰かがif elseはコードを速くすると言ったので、そのようにする習慣がついたのでしょう。 Simon Gniadkowski 2013.08.29 15:24 #29 SDC: ubzenさん、ありがとうございます。私はif elseをよく使います。おそらく、最初にコーディングを始めたときに、誰かがif elseはコードを速くすると言ったので、そのようにする習慣がついたのでしょう。 他意はありません こういうときこそ、みんなが従うような正式な標準があるといいんだけどね ... ... そうすれば、みんな同じことをやっていて、あなたのコードが好きになるでしょう。 そして、あなたが尋ねる前に、いいえ、私は私のホワイトスミス・スタイルに固執するつもりです ... 少なくとも、私はそれをどう呼ぶか知っています、ありがとうubzen Ubzen 2013.08.29 16:00 #30 SDCと RaptorUKを 歓迎します。コーディングはWinning_EAよりもずっと議論しやすいトピックになりますね。) 1234 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
しかし、それは、もし彼らが構文や論理の助けを求めているのなら、そのコードは「...構文的にも論理的にも正しい;」ということにはならないのでは?
はい、その通りです。しかし、より効果的な(あるいはより効果的でない)コーディングスタイル/プラクティスを議論する文脈では、最も重要な 点は、使用するコーディングスタイルに関係なく、コードが構文的および論理的に正しいということなのです。別の言い方をすれば、スタイルは構文的・論理的に正しいコードに道を譲らなければならないということでしょう。主な問題は、コードが見栄えが良いか、読みやすいかではなく、むしろ、そのコードが書かれたタスクを実行するために構文的・論理的に正しいかです :)
また、//コメントについても同意します。コードの様々な部分の詳細について、元のプログラマの頭をリフレッシュさせ、完成後や実装後のコードの理解を助けるために、 // コメントは多いに越したことはないのです。
はい、おっしゃるとおりです。 しかし、効果的なコーディングスタイル/プラクティスを議論する文脈では、最も重要な側面は、使用するコーディングスタイルにかかわらず、コードが構文的および論理的に正しいということです。 別の言い方をすれば、スタイルは構文的、論理的に正しいコードに道を譲らなければならないということです。主な問題は、コードがよく見えるか、読みやすいかではなく、むしろ、そのコードが書かれたタスクを実行するために構文的、論理的に正しいかです。)
ああ、なるほど、そういうことだったんですね。
私は、自分のコードが完成して作業しているときは閉じますが、共有したり議論したりする必要があるときは、数行のスペースを空けて開き直したりするのは簡単です。私は、コーディングフォーマットは、欠落しているブレースを簡単に識別できること、複数の枝を持つ複雑なif elseツリーがある場合、if elseペアを簡単に識別できることをサポートするべきだと思います。私はK&Rスタイルを採用したことがないので、K&Rスタイルのコーダーが どのように行っているかを見てみたいです。
私は、自分のコードが完成して動作しているときは閉じますが、それを共有したり議論したりする必要があるときは、数行のスペースで簡単に開き直せます。
なぜクローズアップするのか?私は、コードを閉じてしまうことの意味がよくわかりません。共有したり議論したりするために開く必要があるのなら、それは何を意味するのでしょうか?
私は、コーディングフォーマットは、欠落しているブレースを簡単に識別できること、複数の枝を持つ複雑なif elseツリーがある場合に、if elseペアを簡単に識別できることをサポートするべきだと思います。私はK&R方式を採用したことがないので、K&R方式のコーダーがどのように行っているかを見てみたいです。
K&Rスタイルの場合、下のブレースはコンディションのマッチングに合わせます。私自身は
1.一貫したインデント
2.1文節の場合は、 ブレースとインデント、またはブレースなしの条件文に続くようにする。
3.3. 中括弧のマッチングが可能なプログラマーズエディタを使用する。
中括弧のマッチングは問題ありません。Linuxカーネルは ほとんどこのスタイルで書かれていますし、Javaの標準でもあります。でも、K&Rスタイルでは、条件の後に余分な空行を挿入してコードをすっきりさせることが多かったので、Allmanスタイルの魅力はわかります。うーん、改心したかも(笑)。
なぜクローズアップするのか?私は、潰れたコードの意味がよくわかりません。もし、共有/議論するためにそれを開く必要がある場合、それは何を意味するのでしょうか?
K&Rスタイルの場合、ボトムブレースはコンディションマッチングで揃えます。私自身は
1.一貫したインデント
2.1文節の場合は、 ブレースとインデント、またはブレースなしの条件文に続くようにする。
3.3. 中括弧のマッチングが可能なプログラマーズエディタを使用する。
中括弧のマッチングは問題ありません。Linuxカーネルはほとんどこのスタイルで書かれていますし、Javaの標準でもあります。でも、K&Rスタイルでは、条件の後に余分な空行を挿入してコードをすっきりさせることが多かったので、Allmanスタイルの魅力はわかります。うーん、改心したかも(笑)。
私はただ、画面スペースを取らないように閉じているだけです。画面に収まる範囲で同時に見たいんだ。ブレースマッチャーは必要なくて、ブレースの後ろにカーソルを置いて、矢印キーで行の上に垂直に動かすと、他のブレースに触れたときにそのブレースがペアになるようにフォーマットしています。
このコードでは、3番目のelseが最初のifとペアになり、2番目のelseが2番目のifとペアになり、最初のelseが3番目のifとペアになることが簡単に分かります。同様に、どのifがelseを持たないかは、elseの後ろのクラスタで、それぞれのifブレースが対応する閉じブレースと垂直に並ぶので、簡単にわかります。私が好きだからといって、他の人もこの方法でコードを書けとは 言いませんが、私にとってはコンパクトで論理的な方法なのです。
k&rを使用するすべてのコーダーのために答えることはできません。正直なところ、あなたのフォーマットを見れば見るほど、私はそれが好きになりました。もし私がオールマン・スタイルを採用していたら、間違いなくあなたの修正版を使うことになるでしょうね。中括弧を互いの下に並べることで、開閉中括弧が1行を占めるのを防いでいます。また、タブやインデントのサイズを気にすることなく、コンパクトモード(画面上でコードのほとんどを見ることができる)で、ifの時にiの下にカーソルを走らせれば、足りない中括弧を見つけることができます。そう、これはとてもクールなことなのです。ただ、初見では、慣れていないせいか、混乱しているように見えました。そして、これが問題の核心です。
アメリカのコーダーの多くは[KnR & Allman]を採用しているようですが、ヨーロッパではWhitesmithsの スタイルが人気なようです。WhitesmithはMt4のDefaultスタイルでもあります。どのスタイルも間違ってはいないのですが、誰かを助けるときには、自分のK&Rスタイルを無視して、もっとWhitesmithを考えるように自分に言い聞かせる必要があります。それか、コードフォーマッターを使うか。
なぜ「複雑なif else木」を書きたがるのか、私には理解できません。誰かが複雑なif_nestの中にすべてのWhite_Spaceとフォーマットを残すと、ページを横切って蛇|スパゲッティ|ジグザグをデザインしようとしたように見えます。最初のifは1行目から300行目までで、そのうちの約150か50行が中括弧によって保持されています。複雑なif elseツリー」の代わりに、なぜ関数を作らないのでしょう。そして、if( false ){ return; }で実際に1行目を終了させればいいのです。
ubzenさん、ありがとうございます。私はif elseをよく使います。おそらく、最初にコーディングを始めたとき、誰かがif elseはコードを速くすると言ったので、そのようにする習慣がついたのでしょう。
ubzenさん、ありがとうございます。私はif elseをよく使います。おそらく、最初にコーディングを始めたときに、誰かがif elseはコードを速くすると言ったので、そのようにする習慣がついたのでしょう。
他意はありません![](https://c.mql5.com/mql4/forum/2013/08/wink_16.gif)
こういうときこそ、みんなが従うような正式な標準があるといいんだけどね ... ... そうすれば、みんな同じことをやっていて、あなたのコードが好きになるでしょう。 そして、あなたが尋ねる前に、いいえ、私は私のホワイトスミス・スタイルに固執するつもりです ... 少なくとも、私はそれをどう呼ぶか知っています、ありがとうubzen