サンセット番組？ - ページ 17

[Реter Konow]

Alexandr Andreev:

もちろん、回路図を知らないよりは、回路図を知っている方がコードの解析はしやすい。

技術的には、コードビジュアライザーのようなものがあると便利なのですが......。特に、一方が他方を打ち消すのではなく、補うものであれば、なおさらです。

私もそう思います。

[Konstantin Nikitin]

だから、集団農場は馬がよく働くが、いい手入れをしないと意味がないという結論に達した。

[Alexandr Andreev]

でも、使い勝手はしっかり工夫しないといけませんね。そして、最もよく必要とされるものを理解すること。すなわち、多くの添付ファイル、リロードを持つオブジェクトの20の継承（深さ）があることができるので、すべての相互関係の全体の混乱を表示することは意味がありません。しかし、このオブジェクトが親構造体で言及されている場所や、解析対象のコードにオブジェクトの外部詳細初期化を記述している場合に初期化される場所を確認する。あるいは、特定の関数の リロードで新しい中間エンティティをすばやく作成し、親のものでミスをしなかったことを理解する。通常、このタスクは検索やコンパイラによって処理されますが

[Aliaksandr Hryshyn]

Alexandr Andreev:

もちろん、回路図を知らないよりは、回路図を知っている方がコードの解析はしやすい。

技術的には、コードビジュアライザーのようなものがあると便利なのですが......。特に、一方が他方を打ち消すのではなく、補い合うものであれば、なおさらです。

しかし、自給自足できる本格的なコードビジュアライザーを作ってみてはどうでしょうか。

コード表現のためのグラフィカルな言語を考案し、その中で良いナビゲーションを考え、表示する情報の優先順位を決める（重要な情報ほど表示に手間がかからず、逆に重要でない情報は表示されない）。また、コードの 徹底的な分析も必要です。

確かに簡単ではないでしょう。なるほど、実装に至る可能性が低いことは分かっているのですが......。

[Aleksey Mavrin]

Aliaksandr Hryshyn:

自己完結する本格的なコードビジュアライザーを作ってみてはいかがでしょうか。

コードを表示するためのグラフィカルな言語を考え、その中で良いナビゲーションを考え、表示する情報の優先順位を決める（重要な情報ほど表示に手間がかからず、重要でないものは逆に手間がかかる）。また、コードの徹底的な分析も必要です。

確かに簡単ではないでしょう。なるほど、実装に至る可能性が低いことは分かっているのですが......。

石油精製用の3D設計の ようなプログラムもあります。配管の接続図があるそうです。経験豊富なプロセスエンジニアにとっては、1枚の「見える」図面よりも、山積みになった図面の方が読みやすいのだが、しばらくすると慣れてしまう。つまり、複雑なコードは、可視化した場合、やはり理解するのが難しいということです。すべてのルールを守れば、コードの原型を読むのはとても簡単です。

[Alexandr Andreev]

Aliaksandr Hryshyn:

自己完結する本格的なコードビジュアライザーを作ってみてはいかがでしょうか。

コード表現のためのグラフィカルな言語を考え、その中で良いナビゲーションを考え、表示する情報の優先順位を決める（重要な情報ほど表示に手間がかからず、重要でないものは逆に手間がかかる）。また、コードの徹底的な分析も必要です。

簡単なことではないでしょう。まあ、実現する可能性が低いことは分かっているのですが......。

自分のコードとビジュアルデザインで自分の設定を作ることも、他人の既成のビジュアルデザインテンプレートを使うこともできる中で、数行書くのは怠慢というものです)))。

プログラミングで、私が最初に使う場所は、関数のリロードでしょう。しかし、コード上ではとにかくすべてが非常に簡潔で、新しい名前を書き、どこから継承したかを書き（通常はテンプレート）、何と何を置き換えたかを書く。以上です。

これらのクセは、あっという間に膨大なライブラリになり、全部覚えるのは大変だと思います。

[Aleksey Nikolayev]

Реter Konow:
はい、でもその方向性は正しいです。 コーディングは、脳の潜在能力を活用するための狭いチャンネルです。コードで記述されたパターンは、同じパターンを目で認識するよりも何百倍も長く理解されるのです。波の回転を想像してください。波の回転は一周するごとに遅くなり、傾きの角度が少しずつ大きくなります。この過程を数式でコードで記述し、カメラで撮影する。プログラマーがこれが同じものだと気づくまでの時間を測ってください。

アプローチの仕方は人それぞれです。個人的には、Donald Knuthの文学的プログラミング（ロシア語ではなぜか「文学的」と訳されている）のアプローチと、それが例えばR言語（R Markdown）で実装されている方法の方がずっと好きです（ほんの少し迷惑なだけですが）。

スピナーについて書くのは間違いです）力学の未解決問題で、運動に関する一般式は（摩擦を無視しても）存在しないのです。

[TheXpert]

Aleksey Nikolayev:

スピナーのことを書くのは間違っている）力学の未解決問題で、（摩擦を無視しても）運動の一般式は存在しないのだ。

そして、ケルトの石もボリュートです )

[Реter Konow]

Aleksey Nikolayev:

...

スピナーのことを書くのは間違っている）力学の未解決問題で、（摩擦を無視しても）運動の一般式は存在しないのだ。

なんとなく、考えていなかったんです。)

[Aliaksandr Hryshyn]

Aleksey Mavrin:
石油精製用の3D設計などのソフトウェアがあります。配管の接続図があるそうです。経験豊富なプロセスエンジニアにとって、一枚の「見える」図面よりも、山積みになった図面を読む方が簡単で、その後、慣れていくのだそうです。つまり、複雑なコードは、可視化した場合、やはり理解するのが難しいということです。すべてのルールを守れば、コードの原型を読むのはとても簡単です。

下の2つのコード表示がなぜ違って認識されるのか、不思議に思いますよね。

//+------------------------------------------------------------------+
//| Initialization of the indicators                                 |
//+------------------------------------------------------------------+
bool CSampleExpert::InitIndicators(void)
  {
//--- create MACD indicator
   if(m_handle_macd==INVALID_HANDLE)
      if((m_handle_macd=iMACD(NULL,0,12,26,9,PRICE_CLOSE))==INVALID_HANDLE)
        {
         printf("Error creating MACD indicator");
         return(false);
        }
//--- create EMA indicator and add it to collection
   if(m_handle_ema==INVALID_HANDLE)
      if((m_handle_ema=iMA(NULL,0,InpMATrendPeriod,0,MODE_EMA,PRICE_CLOSE))==INVALID_HANDLE)
        {
         printf("Error creating EMA indicator");
         return(false);
        }
//--- succeed
   return(true);
  }

次に、グラフィックの「ティンセル」を外します。カラーをマイナス、インデントをマイナス（相対的な位置関係）。

//インジケーターの初期化

bool CSampleExpert::InitIndicators(void)

{

//MACDインジケータを作成します。

if(m_handle_macd==INVALID_HANDLE)

if((m_handle_macd=iMACD(NULL,0,12,26,9,PRICE_CLOSE))==INVALID_HANDLE)

{

printf("Error creating MACD indicator");

return(false)です。

}

//EMAインジケータを作成し、コレクションに追加します。

if(m_handle_ema==INVALID_HANDLE)

if((m_handle_ema=iMA(NULL,0,InpMATrendPeriod,0,MODE_EMA,PRICE_CLOSE))==INVALID_HANDLE)

{

printf("Error creating EMA indicator");

return(false)です。

}

//成功

return(true)です。

}

読みやすさの悪化が目立つ。このことは、グラフィカルな表現が可読性を顕著に向上させることを示唆している。ダイアグラムに特化した話ではなく、いろいろな選択肢が考えられます。