フローチャートを使用した自動Pythonコード視覚化

次の図に示すような開発者ツールの実装を可能にする技術についてです。



コードの代替表現を使用した環境の一般的なビュー

ここでは、開発環境ウィンドウは2つの部分に分かれています。 左側には使い慣れたテキストエディタがあり、右側には、アルゴリズムの従来のフローチャートに可能な限り近い自動生成された図があります。 テキストが入力されると、チャートの生成と再描画が実行されます。 開発環境は、開発者のアクションの一時停止を決定し、コードが正しいままであればチャートを更新します。 その結果、プログラムテキストだけでなく、そのグラフィック表現でも機能することが可能になります。

野生のフローチャート

ブロック図は必要ですか？

ソフトウェア開発の私の経験では、フローチャートが使用され、その使用方法はタスクに依存することが示されています。 開発者には2つの典型的なシナリオがあります。

• 最初から新しいソフトウェアを作成する
• 既存のソフトウェア製品のサポートと変更

私は両方のケースでフローチャートを使用しますが、わずかに異なります。

新しいソフトウェアの場合、私は通常トップダウンのアプローチを使用します。 最初に、アーキテクチャは抽象ブロックと文字の形で描かれ、次に個々のサブシステムがより詳細に作成され、選択されたプログラミング言語のレベルに到達します。 もちろん、絶対にすべてを詳細に描くのではなく、難しい部分や特に興味のある部分だけを描いています。 MS Visioのような市場で入手可能なツールは、図を描くのに役立ちますが、抽象度が高いだけです。 理想的なツールは、もしあれば、プログラミング言語のレベルで、できれば2つの方向で役立ちます。コードによるダイアグラムの生成とその逆、ダイアグラムによるコードの生成です。

既存のプロジェクトをサポートする場合、典型的な-悲しみを引き起こす-状況は、ドキュメントが欠落している場合です。つまり、作業を理解するには、まずリバースエンジニアリングを行う必要があります。 ここでは、ボトムアップのアプローチがよく機能します。 コードを読む過程で、ある時点で、オペレーターのグループが何をするのかが理解できます。つまり、物理的に紙の上に、または投機的に-適切なテキストを含むブロックを描くことができます。 したがって、演算子のグループの代わりに1つの要素が表示されます。 最後に、コードに対応する図が表示されます。 このシナリオをサポートするツールが欲しいのですが、まだ見つかりませんでした。

完全を期すために、ソフトウェアの工業生産でダイアグラムを広く使用する大規模プロジェクトに注意を払うことは理にかなっています。 何かありますか？ この質問に対する答えはイエスです。 私が知っているこの種の最大のプロジェクトは、おそらく再利用可能な宇宙船ブランのソフトウェアです。 アメリカの再利用可能な船とは異なり、ソビエトの船は有人ではありませんでした。つまり、 DRAGON言語を使用して開発されたソフトウェアに制御の全負荷がかかったことを意味します。 DRAGONはデザインのすべての段階でグラフィック図のみを使用し、開発者は従来のテキストをまったく使用しませんでした。 このプロジェクトは、軌道への進入と船の帰還に成功したことにより、ソフトウェアの高い信頼性を証明しました。 作業の結果に関するレポートでは、開発速度が速く、エラーが少ないのは、ダイアグラムが広く使用されているためであることに注意してください。 そして今、ドラゴンは宇宙産業でソフトウェアを作成するために使用されています。 残念なことに、一部の技術上の制限により、人気のあるプログラミング言語で作成する開発者の日常業務でDRAGONのすべての成果を使用することが不可能になります。 ただし、一般的な結論を出すことができます。アルゴリズムのブロック図のような図は有用であり、かなりの利点があります。


DRAGON言語の図の例（サイトdrakon.suから）

ツールキット

記事のトピックの文脈における開発プロセスの私の理解は、テキストと同様にコードを扱う方が便利な場合と、グラフィカル表現を分析する方が便利な場合があるということです。 したがって、理想的なツールは、1つだけを優先することなく、2つのビューで機能するはずです。 このツールは、2つのビュー間のスムーズな統合も提供する必要があります。最も単純な例は、特定のコード行と対応するグラフィック要素との関係です。

悲しいかな、説明したものに似た完成したツールはまだ見つかっていません。 DiaやMS Visioなどのエンジニアリンググラフィックス用の優れたパッケージがあり、それらは設計された分野で非常に優れています。 いくつかの段階で役立ちますが、頻繁な変更が必要な場合は使用が非常に困難です。 UMLツールなど、設計段階を対象としたパッケージがありますが、低レベルで使用するには不便です。 さまざまなサブジェクト領域用のさまざまなコードジェネレーターがありますが、生成されたコードは、読み取りを目的とする場合、簡単に読み取り可能とは言えません。 特定のサブジェクト領域のみに焦点を当てたグラフィカルツールがありますが、汎用プロジェクトで使用することはほとんど不可能であり、そのようなツールではコードがまったく利用できないことがよくあります。

そのようなツールがない場合、それを作成できるテクノロジーの開発を開始する価値があるでしょうか？ 技術とそれを実装する実験環境についてさらに議論します。 この環境を使用すると、既存のプロジェクトをテキストとして、またプロジェクト間の自動同期を備えたグラフィックとして見ることができます。 実装はPython言語用で、主にPythonで行われます。

グラフィックプリミティブ

議論の良い出発点は、任意のPythonコードを表すために必要なグラフィカルプリミティブのセットです。 テキストからグラフィックスへの移行から始めましょう。入力にPythonコードがあり、出力に適切に相互接続されたグラフィックプリミティブのセットを使用してダイアグラムを描画する必要があります。 ここで対処する必要がある問題は次のとおりです。 入力ストリームで認識が必要な言語要素は何ですか？ 認識された要素はどのようにチャートに描かれるべきですか？

必要なすべてのプリミティブを順番に説明します。

コードブロック

明らかに、すべてのオペレーターが制御フローに直接影響するわけではありません。 このような演算子は、コードのブロックとして描画できます。

なぜ個々のオペレーターではなくブロックするのですか？ ほとんどの場合、開発者はいくつかのステートメントで構成される関連するコードを大きなフラグメントにグループ化する傾向があります。 明らかに、このようなグループ化の目的は、後続の読み取り中にコードの理解を容易にすることです。 グループ化の手段は空行です。 このようなグループ化の事実は、ダイアグラムに表示される必要があります。

プリミティブに関しては、単純な長方形が妥当と思われます。 以下の例は、1つのコードブロックと2つのブロックを次々に示していますが、演算子間の空行のコードは異なります（以下：すべての例で、最初にシリーズ2のPythonコード、次に提案されたグラフィック表現）。

c = MyClass( 154 ) c.member = f( 17 ) c.doSomething() print c 

1ブロックのコード

 c = MyClass( 154 ) c.member = f( 17 ) c.doSomething() print c 

コードの2つのブロックを1つずつ

コメント

綿密な調査の結果、開発者がどのようにコメントを配置したかに応じて、少なくとも3種類のコメントを区別できることがわかりました。 コードのブロックに対して行われたのと同様の空白行も、セマンティックフラグメントを形成するため、考慮する必要があります。 したがって、強調表示されているコメントの種類は次のとおりです。

• 独立した
• 一流
• 横

独立したコメントは、1つ以上の隣接する行を占有し、少なくとも1つの空行によって残りから分離されます。 独立したコメントの行には、コメントのみが含まれます。

主要なコメントは、1つの例外を除き、独立したコメントに似ています。 リードコメントの最後の行に続く行には、Python演算子が含まれています。 この場合、開発者はコメントと次のブロックの間に空の行を挿入しませんでした。これは、おそらくこれが意図的に行われたことを意味します。コメントは次のブロックを対象としています。

サイドコメントは、オペレーターの右側にあります。 ここにはいくつかの重要な詳細があります。 多くの場合、コードのブロックは数行かかりますが、開発者はそれらの一部のみにサイドコメントを付けることができます。 グラフィックを選択するときは、この状況を考慮する必要があります。 別の詳細は、コードブロックの最後の行に関するものです。開発者は、コメントを1行以上必要とする場合があります。 そのような場合もスケジュールで考慮する必要があります。

理論的には、もう1つのタイプを区別できます-最終コメント。 コードブロックの最終行と最終コメントの最初の行の間に空行がないという違いはありますが、先頭のコメントと似ています。 ただし、このような場合は、一般的な慣行よりもまれです。 開発者は、テキストでは低く、高くはないものについてコメントする可能性が高くなります。 したがって、最終コメントを別のエンティティとして分離しないことが決定されました。

認識可能なタイプのコメントに適切なグラフィックを選択できるようになりました。

独立したコメント

 a = 154 # Line 1 # Line 2 b = a 

独立したコメント

この例では、独立したコメントは2行で構成されています。 明らかに、コメントは2つのコードブロックの間にあり、ダイアグラム上のこの位置はブロックを結ぶ線に対応しています。 この場合に適したグラフィックは、ノートに似たコメントの長方形で、ブロック間の線につながる水平コネクタがあるようです。

主要なコメント

 # Line 1 # Line 2 a = 154 b = a 

一流のコメント

このリードコメントはブロック用であるため、ブロックの上にコメントの四角形を描画し、必要なブロックにつながるコネクタを追加できます。

サイドコメント

 a = 154 b = a # No comment for the first line c = b + 1 # Comment for c # A tail -----^ 

尾付きのサイドコメント

サイドコメンタリーの場合、いくつかの点に注意が必要です。 まず、コード行とコメントの間には視覚的な対応があります。 上記の例では、最初の行にコメントはありません。そのような状況は、スケジュールで考慮する必要があります。 言い換えると、コメントの長方形の行は、テキスト内での整列とまったく同じように垂直方向に整列する必要があります。 第二に、コードの最後の行のコメントが複数行になる場合があります。 このような「尾」の兆候は次のように解釈されます。

• 末尾のコメント行は前の行の直後に続きます（空行はありません）
• 文字＃は前の行と同じ位置にあります

輸入品

インポートは依存関係をもたらします。 また、複雑なプロジェクトの依存関係を管理することは、しばしば困難な作業です。 したがって、インポート用のグラフィックスは、チャートをすばやく確認する場合でも注意を引く必要があります。 これに基づいて、次の例に示すように、左側にアイコンが表示された長方形が選択されます。

 import sys # Leading comment for import from os.path import sep, \ isdir # Side comment from x import ( y, # side for y name ) # side for name 

インポートの例

この例では、2番目と3番目のインポートが複数の行を占めており、その一部にはサイドコメントが付いています。

Ifステートメント

条件ブロックがチャート上でどのように表示されるかについて説明しましょう。 アルゴリズムの従来のフローチャートは菱形を提供します。 菱形は、それに記載されている条件が短い場合に最適です。 ただし、実際には、条件は長い場合が多く、時には複数の行を使用するため、条件全体を適切なサイズの菱形に収めることが難しくなります。 ひし形が大きくなりすぎて貴重な縦方向のスペースを大量に占有するか、フォントを小さくしすぎるか、ソーステキストの略語に頼る必要があります。 提案された妥協案の解決策は次のとおりです。左側と右側は菱形で、上下はスペースを節約するために水平になります。 つまり、グラフィックスは部分的に従来の菱形に似ています。 このようなグラフィックプリミティブは、条件の複雑さに応じて簡単にスケーリングできます。

次のディスカッションアイテムは、yesおよびnoブランチを描画する方法です。 可能なオプションの1つは、条件ブロックの左右に分岐を描くことです。 残念ながら、このアプローチは、完全なダイアグラムを読むのが難しく、美しく見えない状況につながる可能性があります。 問題は、ブランチが任意の複雑さになり、ブランチの幅が広くなり、条件ブロックが水平方向にシフトすることです。 その結果、表示には垂直スクロールと水平スクロールの両方が必要になりますが、可能であれば回避する必要があります。

もう1つの考慮事項は、時間の経過とともにコードを読みやすく、理解しやすいようにコードを設計することです。 プログラムのすべての主要なアクションが1つの垂直に配置され、避けられないエラー処理、まれなケースや特別なケースなどを確実に行えるようになれば幸いです。 少し横にあります。 その後、元の作者がこれを処理すれば、コードの目的をより早く理解できるようになります。 このスタイルの開発をサポートするために、この方法でチャートにブランチを配置することを提案します。ブランチの1つは垂直を形成するための条件ブロックのすぐ下にあり、もう1つはブロックの右側にあります。

 if 154 > 153: print "Well, yes" else: pass 

ifステートメントの簡単な例

もちろん、著者はコメント付きのifステートメントに関連するコードのさまざまな部分を提供できます。 より複雑なコード例と提案されているグラフィックスを検討してください。

 # Leading for 'if' if ( 154 > 153 and # Side 1 1 > 0 ): # Side 2 print "Well, yes" # Leading for 'else' else: pass 

コメント付きのifステートメント

この例では、条件に関するサイドコメントがあります。 コードブロックと同様に、条件のサイドコメントは一部の行に対してのみ指定できるため、コメントの四角形は条件の右側に配置し、それに応じて垂直方向に配置する必要があります。 残念ながら、コメントコネクタと条件分岐の交差を完全に回避することはできませんでしたが、問題を緩和する状況もあります：条件の横方向のコメントは実際にはめったに表示されず、プログラマはしばしば先頭のコメントを使用します。

最後の興味深い点は、他の人のリードコメントについてです。 チャートには他に選択されたプリミティブはありません;実行ブランチの線はそれに対応します。 したがって、チャート上では、このようなコメント（めったに使用されない）は、独立したコメントのように見え始めます。 これについて特にひどいものは何もありません-グラフィックスは今でも正確に何が起こっているかを伝えます。

機能

Pythonファイルには、ネストされた関数の定義だけでなく、関数の多くの定義を含めることができます。 どのフローチャートも適切なものを提供していないため、新しいものを提案する必要があります。

関数のグラフについて考えるときに頭に浮かぶアイデアの1つは、スコープに関するものです。 スコープは、定義された境界を持つ空間の役割を果たします。 どの関数にも、明らかに、開始および終了する非常に具体的なポイントがあります。 これは、関数のグラフィックスが閉じた領域に似ている可能性があることを意味し、その内部には関数本体のグラフィック表現が含まれています。 少し一歩進んで、慣れていないPythonコードを見ると、コンテキストがすぐに明確にならないことがよくあることを思い出すことができます。特定のコード行は、ネストされた関数内、クラス内、条件付き構造内に配置できます。 範囲の境界線を概説したアイデアは、実行されるアクションのコンテキストをすばやく理解することを潜在的に可能にします。

最初に、提案されているグラフィックスの簡単な例を見てみましょう。

 def f( x ): print "Function f( x )" 

機能用グラフィックス

関数のスコープは、角の丸い長方形で囲まれ、関数の強調表示された色で塗りつぶされます。 四角形のヘッダーには、関数の名前とその引数が含まれています。 ヘッダーは、本体と水平線で区切られています。 スコープの詳細を表示するために、左上隅にバッジが追加されました。これは、これが関数であることを明示的に示しています。

ここで、関数の先頭にコメントがあり、ドキュメント行があり、パラメーターが複数行を占めており、コメントアウトされている、より複雑な例を考えてみましょう。

 # Leading comment def g( x, # x - first argument y ): # y - second argument """ Docstring """ print "Function g( x, y )" 

コメントとドキュメントを含む機能

リードコメントのグラフィックは明らかですが、引数のサイドコメントは問題です。 サイドコメントの行は引数のリストと垂直に整列する必要があるという事実により、コメントヘッダーを関数ヘッダーに直接配置することが最も論理的であることが判明しました。 提案されたソリューションが私にとって完璧だとは言えませんが、それは正しいPythonコードのすべてのケースをカバーし、曖昧さを許しません。

文書化のために、スコープヘッダーは、関数プロトタイプセクションのすぐ後に続く別の水平セクションで展開されます。

Returnステートメント

従来のフローチャートは、小さな機能拡張で活用できる優れた返却スケジュールを提供します。 簡単な例を挙げます。

 def f( x ): return x * 154 

シンプルなリターン

改善点は、左矢印アイコンの追加です。 returnステートメントは制御フローに強い影響を与えるため、アイコンはコードをすばやく表示するときに追加のアテンショングラブの目的を果たします。

もちろん、returnステートメントは複数行にまたがる場合があり、コメントが含まれる場合があります。 以下はそのような場合の例です。

 def f( x ): # Return leading return ( x * 154 + # Side 1 X / 154 ) # Side 2 

コメント付きの複数行リターン

クラス

スコープの概念が関数に使用された後、クラスへの適用可能性は論理的ではないようです。 クラスのグラフィックスは、異なる背景色とバッジを除いて同じにすることができます。 以下の例は、コメントとdocstringを持つクラスを示しています。

 # Leading class C( ClassA, # Side ClassB ): "Docstring" def __init__( self ): ClassA.__init__( self ) self.__x = 0 

クラスの例

デコレータ

関数およびクラスのコンテキストでは、デコレーターをPythonに表示できます。 実際、デコレータはラッピング関数です。つまり、視覚化のために、同じスコープの考え方を使用できます。 簡単に識別できるように、独自の背景色を選択して、バッジに@記号を挿入できます。

 # Decorator leading # comment @decor( x, y ) # decorator # side comment def f(): print "Function f()" 

コメント付きデコレータ

サイクル

Pythonは、forとwhileの2種類のループをサポートしています。 どちらのタイプにも条件があり、breakステートメントとcontinueステートメントが内部で発生する可能性があります。 サイクルのスケジュールの決定は容易ではなく、次の考慮事項に基づいていました。

従来のフローチャートでは、ifステートメントに既に使用されているグラフィックスを使用しますが、ifグラフィックスに適した代替手段がないため、このソリューションは有効なままにしておくのが最適です。

一方、スコープのようなループには、非常に明確な開始点と終了点があります。 ループ条件はスコープのタイトルに適しています;スコープの内容はループ本体の役割を果たします。 もう1つの考慮事項は、スコープを使用する場合、閉じた幾何学的図形があるため、同じ垂直にプログラムのメインアクションを表示するというアイデアがより明確に表現されることです。 さらに、従来のブロック図の場合のコネクタは「トップダウン」の原則を満たしていません-サイクルからの出口は最初の状態の右側にあります。 従来のグラフィックスのもう1つの問題は、Pythonサイクルに表示される可能性のあるelseパーツの処理方法が完全に不明確であることです。

最後の考慮事項は、breakステートメントとcontinueステートメントに関するものです。 スコープを使用する場合、ブレークとコンティニューが続くポイントは完全に明白になります-長方形の下端と上端。 従来のブロック図の場合、コネクタを描画する必要がありますが、複雑な分岐コードの場合は（可能な場合）描画するのが困難であるため、図が明白で他のコネクタとの交点はありません。

ループのスコープのアイデアを使用して、先頭およびサイドコメントの問題もすでに解決されています。

 for x in [ 1, 17, 42, 154 ]: print x 

forループ

より複雑なケースでは、ループにコメントとelseブロックが含まれる場合があります。 以下の例を検討してください。

 x = 0 # While loop leading comment while x < 154: # while side # comment x += 1 # else leading comment else: # else side comment pass 

elseブロックとコメントを含むwhileループ

elseブロックは、ループのスコープの右側に別のスコープとして描画されます。 スコープは、それらの間の密接な関連を強調するために、破線で互いに接続されています。 コメントはおなじみの方法で表示されます。 そして、elseブロックの可視性バッジは、境界線からヘッダーに移動します。 そうでない場合、タイトルは完全に空になり、それほどエレガントに見えません。

ステートメントを中断して続行する

従来のフローチャートは、中断して続行するためのグラフィックを提供しません。 コネクタはそれらに対応しており、解決が困難ないくつかの問題につながります。 まず、両方のオペレーターが先頭とサイドのコメントを持つことができ、コネクターの場合、オペレーターへの所属が明らかであるようにコメントを表示する方法が完全に不明確です。 第二に、コネクタは明確な配線の問題につながります。 ループの本体は複雑になる可能性があり、多くのbreakおよびcontinueステートメントが含まれます。 そのような場合、最小限のねじれがあり、他のコネクタとの交差がないような配線を実現することは（可能な場合）困難です。

これらの問題に関連して、休憩と継続の新しいスケジュールを導入することが決定されました。 演算子が実際に特定のポイントへの遷移を表すことを強調するために、ラベルに似ていて出力コネクタのないグラフィックが選択されました。 Pythonでプログラミングしている人は、おそらく移行がどこにつながるかを知っているので、出力コネクタは冗長に見えます。

 while True: if True: continue else: break 

休憩と継続の簡単な例

もちろん、オペレータはコメントを持っているかもしれません。 以下の例は、それらがどのようにレンダリングされるかを示し、対応する演算子のメンバーシップを一意に識別します。

 while True: if True: # Leading 1 continue # Side 1 else: # Leading 2 break # Side 2 

コメント付きのステートメントを中断して続行する

試してみてください

これはおそらくPythonで最も複雑な設計です。 tryブロックに加えて、多くの例外ブロックとオプションのelseブロックとfinallyブロックがあります。 これらの各ブロックには独自のボディがあるため、各ブロックに可視領域のグラフィックスを使用することにしました。

 try: a = x / y except ZeroDivisionError: print "?" else: print "a = ", a finally: print "finally" 

例-例外-else-最終的に

exceptブロックはエラーを処理するように設計されています。つまり、実行のメインラインの外側にあります。 したがって、それらはtryブロックの右側にあります。 tryブロックとexceptブロックの密接な関係をさらに強調するために、それらの間に破線が描かれています。 除外ブロックが複数ある場合、ダイアグラムは右側に「成長」し、除外ブロックが1つずつ配置されます。

elseブロックとfinallyブロックは、プログラム実行のメインラインに属する可能性が高いため、図ではtryブロックの後に続きます。

明らかに、説明されている各要素には、他の言語演算子と同じ方法で描画できる先頭コメントとサイドコメントの両方を含めることができます。

ステートメント付き

withステートメントは実行コンテキストを定義するため、スコープの概念が最適です。

 # Leading with open( "my-data.txt" ) as f: # Side data = f.read() print data 

ステートメント付き

レイズ演算子

例外の生成が制御フローに強い影響を及ぼすことは間違いありません。 したがって、レイズ演算子のグラフィックは、一見しただけでも注意を引き付けるようなものでなければなりません。 考慮する必要があるもう1つの考慮事項は、raiseステートメントにreturnステートメントと共通のプロパティがあることです。両方とも現在のスコープを終了します。 これに基づいて、左の部分にある変更されたアイコンを使用して、レイズに同じグラフィックを使用することが決定されました。レイズには目を引く赤い矢印が表示されます。

いつものように、raiseステートメントは複数の行にまたがることができ、先頭とサイドのコメントを持つことができます。

 # Leading raise Exception( "first line " # Side 1 "Second line" ) # Side 2 

レイズ演算子

アサート

assert文は条件付きで例外をスローします。つまり、raise文と同じように制御フローに影響を与える可能性があります。 これに基づいて、assertのグラフでは、アイコンをraiseのような赤い矢印のままにしておきたいが、例外をスローする従来性を強調したかった。

 assert x == 97 # Leading assert type( x ) is IntType, \ "x is not an integer" # Side 

2つのアサートステートメントの例

例外の条件は、左側の菱形で示されており、既によく知られている赤い矢印が描かれています。 もちろん、assertステートメントには先頭とサイドのコメントを含めることができます。 このケースは、上記の例の2番目の演算子に対して示されています。

sys.exit（）

厳密に言えば、sys.exit（）呼び出しは言語の一部ではありませんが、制御フローに直接影響します。したがって、sys.exit（）を認識して適切に表示するというアイデアは魅力的です。

この呼び出しの興味深い機能は、構文的には、インポートの作成方法によって異なるように見える場合があることです。以下の例は、提案されたスケジュールとさまざまなインポートオプションを示しています。

 if True: import sys sys.exit( 1 ) from sys import exit exit( 2 ) else: from sys import exit as f f( 3 ) from sys import * # Leading exit( 4 ) # side 

例sys.exit（）

もちろん、eval（）を介してsys.exit（）を呼び出すこともできます。そのようなオプションを認識することは困難ですが、それらはまれであり、従来のオプションでさえもすでに十分にカバーされています。

sys.exit（）を呼び出すと、プログラムがスケジュールより早く終了します。つまり、すべての中間レベルを過ぎて戻ることに似ています。したがって、グラフィックはリターンオペレーターから借用され、アイコンは反射エッセンスに置き換えられています。

ファイル

グラフィックを必要とする最後の要素は、別個のファイルです。pythonファイルには、チャートに表示する必要があるいくつかの属性があります。

• ドキュメントライン
• エンコード
• 開始手順

当然、ファイルは他のすべての要素が配置されるスコープを形成します。以下の例は、ファイルのグラフ上の上記の要素の配置を示しています。

 #!/usr/bin/env python # encoding: utf-8 """ A file docstring may occupy a few lines """ print "Hello flowcharts" 

Pythonファイル

概念実証：Codimension Python IDE

言語のどの要素を認識する必要があるのか​​、そしてそれらをグラフィカルな表現でどのように表示するのかがよくわかったので、ツールの作成を開始できます。明らかに、ここでの重要な質問は次のとおりです。テキストとグラフィックスはどのように相互作用するべきですか？考えられる1つの方法は、テキストを完全に破棄し、グラフィックスのみを使用することです。このアプローチはすぐに拒否されました。状況によっては、テキストまたはグラフィックスが明確に勝つことができると確信しています。

したがって、ツールは、いずれかを犠牲にすることなく、プログラムの両方のタイプのプレゼンテーションをサポートする必要があります。典型的なPython IDEでは、テキストエディターが中心的な役割を果たします。このスペースをテキストとグラフィックスの間で均等に分けることは論理的なようです。

新しいプロジェクトを開始する前に、既存のオープンソースIDEの分析を実行して、コードのグラフィカルな表現をサポートするアドオンを開発しました。残念ながら、適切なものは見つかりませんでした。そのため、Codimension Python IDEと呼ばれる新しいパイロットプロジェクトが開始されました。


Codimension Python IDE

の一般的なビューCodimension IDEの開発はゼロから始まりませんでした。いくつかのアイデアとコードの一部は、別のオープンソースPython IDEであるeric 4から借用されました。

現在、Codimensionは、任意のPython（シリーズ2）コードのグラフィカルな表現の自動レンダリングを実装しています。環境はコードの一時停止を決定し、テキストの右側にダイアグラムを再描画します。ある時点でコードが構文的に正しくなくなると、チャートは更新されず、テキストに関連するチャートステータスインジケーターの色が赤に変わります。

また、マウスカーソルの下にあるスコープまでのパスの表示も実装します。図内の要素をダブルクリックすると、テキスト内の対応するフラグメントに移動します。逆に、入力フォーカスがテキスト部分にあるときに押されるキーの組み合わせは、対応するグラフィック要素の遷移と強調表示につながります。チャートを一般的な形式のSVG、PNG、およびPDFにエクスポートする機能がサポートされています。もちろん、すべてのIDE機能がここにリストされているわけではなく、グラフィカルプレゼンテーションの新機能の計画はさらに多くあります。

第2部では、グラフィックコンポーネントに重点を置いたCodimension IDEの実装について説明します。まだ実現されていない新機能、図をマークアップするためのマイクロ言語などについて説明します。

UPD：パート2の公開