なぜこのようなコードが多いのでしょうか？ - ページ 3

新しいコメント
 
RaptorUK:

しかし、それは、もし彼らが構文や論理の助けを求めているのなら、そのコードは「...構文的にも論理的にも正しい;」ということにはならないのでは？

はい、その通りです。しかし、より効果的な（あるいはより効果的でない）コーディングスタイル/プラクティスを議論する文脈では、最も重要な 点は、使用するコーディングスタイルに関係なく、コードが構文的および論理的に正しいということなのです。別の言い方をすれば、スタイルは構文的・論理的に正しいコードに道を譲らなければならないということでしょう。主な問題は、コードが見栄えが良いか、読みやすいかではなく、むしろ、そのコードが書かれたタスクを実行するために構文的・論理的に正しいかです :)

また、//コメントについても同意します。コードの様々な部分の詳細について、元のプログラマの頭をリフレッシュさせ、完成後や実装後のコードの理解を助けるために、 // コメントは多いに越したことはないのです。

 
Thirteen:

はい、おっしゃるとおりです。 しかし、効果的なコーディングスタイル/プラクティスを議論する文脈では、最も重要な側面は、使用するコーディングスタイルにかかわらず、コードが構文的および論理的に正しいということです。 別の言い方をすれば、スタイルは構文的、論理的に正しいコードに道を譲らなければならないということです。主な問題は、コードがよく見えるか、読みやすいかではなく、むしろ、そのコードが書かれたタスクを実行するために構文的、論理的に正しいかです。）

ああ、なるほど、言いたいことはわかりました ... 美しく表現されたコードでも、動かなければ意味がありません ... でも、もしかしたら修正するのは簡単かもしれませんね？
 
RaptorUK:
ああ、なるほど、そういうことだったんですね。
そうですね。言い換えれば、コーディングスタイルやプレゼンテーションの方法は、プログラマが選択するものであり、目的（目的は構文的・論理的に正しいコード）に対する手段なのです :) プログラマが（その後、そのコードを書いていない他の人が）簡単に読んで理解できるコードであれば、構文的・論理的エラーを発見し修正することはずっと簡単です。
 

私は、自分のコードが完成して作業しているときは閉じますが、共有したり議論したりする必要があるときは、数行のスペースを空けて開き直したりするのは簡単です。私は、コーディングフォーマットは、欠落しているブレースを簡単に識別できること、複数の枝を持つ複雑なif elseツリーがある場合、if elseペアを簡単に識別できることをサポートするべきだと思います。私はK&Rスタイルを採用したことがないので、K&Rスタイルのコーダーが どのように行っているかを見てみたいです。

 
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スタイルの魅力はわかります。うーん、改心したかも(笑)。

 
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
 
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行目を終了させればいいのです。

 

ubzenさん、ありがとうございます。私はif elseをよく使います。おそらく、最初にコーディングを始めたとき、誰かがif elseはコードを速くすると言ったので、そのようにする習慣がついたのでしょう。

 
SDC:

ubzenさん、ありがとうございます。私はif elseをよく使います。おそらく、最初にコーディングを始めたときに、誰かがif elseはコードを速くすると言ったので、そのようにする習慣がついたのでしょう。

他意はありません


こういうときこそ、みんなが従うような正式な標準があるといいんだけどね ... ... そうすれば、みんな同じことをやっていて、あなたのコードが好きになるでしょう。 そして、あなたが尋ねる前に、いいえ、私は私のホワイトスミス・スタイルに固執するつもりです ... 少なくとも、私はそれをどう呼ぶか知っています、ありがとうubzen

 
SDCと RaptorUKを 歓迎します。コーディングはWinning_EAよりもずっと議論しやすいトピックになりますね。）
1234
新しいコメント