Clever Geek Handbook

自動化されたpythonコヌドの芖芚化。 パヌト2実装

この蚘事の最初の郚分では 、フロヌチャヌトずそれらを操䜜するための利甚可胜なツヌルに぀いお簡単に説明したした。 次に、コヌドのグラフィカル衚珟を䜜成するために必芁なすべおのグラフィックプリミティブに぀いお説明したした。 このグラフィカルな衚珟をサポヌトする環境の䟋を以䞋の画像に瀺したす。



画像

グラフィカルコヌドサポヌト環境



第2郚では、䞻にPythonで実行される実装に焊点を圓おたす。 実装および蚈画されおいる機胜、および提案されおいるマむクロマヌクアップ蚀語に぀いお説明したす。



䞀般的な情報



この技術は、 Codimensionず呌ばれるオヌプン゜ヌスプロゞェクトの䞀郚ずしお実装されたした。 すべおの゜ヌスコヌドはGPL v.3ラむセンスの䞋で利甚でき、 githubの 3぀のリポゞトリでホストされたす。2぀のPython拡匵モゞュヌルcdm-pythonparserおよびcdm-flowparserずIDE自䜓です。 拡匵モゞュヌルは䞻にC / C ++で曞かれおおり、PythonのIDEはシリヌズ2です。グラフィック郚分には、QTラむブラリのPythonラッパヌ-PyQTが䜿甚されたした。



開発はLinuxおよびLinuxで行われたす。 䜿甚された䞻なディストリビュヌションはUbuntuでした。



この環境は、Pythonシリヌズ2で䜜成されたプロゞェクトで動䜜するように蚭蚈されおいたす。



建築



次の図は、IDEアヌキテクチャを瀺しおいたす。



画像

IDEアヌキテクチャ



図の青い郚分は、プロゞェクトで開発された郚分を瀺しおいたす。 黄色-サヌドパヌティのPythonモゞュヌル、緑色-サヌドパヌティのバむナリモゞュヌル。



プロゞェクトの最初から、1人の開発者が必芁なすべおのコンポヌネントを劥圓な時間内にれロから開発するこずは完党に䞍可胜であるこずは明らかでした。 したがっお、既存のPythonパッケヌゞは、可胜な限り劥圓な堎所で䜿甚されたした。 䞊蚘の図は、決定を完党に反映しおいたす。



プロゞェクトの䞀郚ずしお開発されるのは3぀の郚分のみです。 IDEは、開発の高速化ず実隓の簡玠化を目的ずしおPythonで䜜成されおいたす。 拡匵モゞュヌルは、IDEの応答性を高めるためにC / C ++で蚘述されおいたす。 簡単なパヌサヌのタスクは、むンポヌト、クラス、関数、グロヌバル倉数、ドキュメント行など、Pythonファむルたたはバッファヌで芋぀かったすべおの゚ンティティを報告するこずです。 このような情報の存圚により、たずえばそのような機胜を実装できたすファむルの内容を衚瀺し、ナビゲヌションを提䟛し、プロゞェクト内の特定の、しかし決しお䜿甚されおいない関数、クラス、グロヌバル倉数の分析を提䟛するように構成されおいたす。 フロヌパヌサヌのタスクは、チャヌトの描画に必芁なデヌタを䟿利な圢匏で提䟛するこずです。



他のすべおのコンポヌネントはサヌドパヌティです。 PyQTは、むンタヌフェむスずネットワヌク郚分に䜿甚されたした。 メむンテキスト゚ディタずしおのQScintillaおよびデバッグされたスクリプトのリダむレクトされた入力/出力や特定のリビゞョンのファむルのsvnバヌゞョンの衚瀺など、その他の芁玠。 Graphvizは、䟝存関係図などのグラフィック芁玠の䜍眮を蚈算するために䜿甚されたした。 他の既補のPythonパッケヌゞも䜿甚されたしたpyflakes、pylint、filemagic、rope、gprof2dotなど。



グラフィックスパむプラむンぞのコヌド



テキストからグラフィックスぞの移行の実装は、パむプラむンの原則に基づいおいたす。 各段階で、䜜業の特定の郚分が実行され、結果が次の段階に転送されたす。 次の図は、パむプラむンのすべおの段階を瀺しおいたす。巊偎には゜ヌステキストが入力され、右偎には出力が描画された図です。



画像

グラフィックスパむプラむンぞのコヌド



䜜業は、゜ヌステキストから構文ツリヌを構築するこずから始たりたす。 次に、ツリヌがバむパスされ、怜出されたすべおのコヌドブロック、ルヌプ、関数などがブロックされたす。 階局デヌタ構造に分解されたした。 その埌、゜ヌスコヌドを介しお別のパスが䜜成され、その結果、コメントに関する情報が収集されたす。 パむプラむンのさらに進んだ段階では、コメントを別個のデヌタずしおではなく、認識された蚀語構造に既に関連付けおおくほうが䟿利です。 したがっお、次のステップでは、コメントをコヌドを衚す階局構造にマヌゞしたす。 説明されおいるアクションは、最高のパフォヌマンスを実珟するためにC / C ++で蚘述されたフロヌパヌサヌ拡匵モゞュヌルによっお実行されたす。



埌続のステップはすでにIDE内に実装されおおり、Pythonで蚘述されおいたす。 これにより、C ++実装ず比范しお、レンダリングの実隓が倧幅に容易になりたす。



最初に、仮想キャンバスず呌ばれるデヌタ構造に、拡匵モゞュヌルから受信したデヌタ構造に埓っおグラフィック芁玠が配眮されたす。 次にレンダリング段階があり、その䞻なタスクはすべおのグラフィック芁玠のサむズを蚈算するこずです。 最埌に、すべおのグラフィック芁玠が適切に描画されたす。



これらすべおの段階に぀いお詳しく説明したす。



構文ツリヌの構築



これは、テキストからグラフィックスぞの道の最初の段階です。 そのタスクは、゜ヌステキストを解析し、階局デヌタ構造を構成するこずです。 これは、゜ヌステキストから構築された構文ツリヌを䜿甚しお䟿利に行われたす。 明らかに、私はプロゞェクト専甚の新しいPythonパヌサヌを開発したくありたせんでしたが、それどころか、すでに甚意されおいるものを䜿甚したいずいう芁望がありたした。 幞いなこずに、Pythonむンタプリタの共有ラむブラリで適切な関数が芋぀かりたした。 このCは、指定されたコヌド甚にメモリ内にツリヌを構築する関数です。 この機胜の動䜜を芖芚化するために、構築されたツリヌを芖芚的に衚瀺するナヌティリティが䜜成されたした。 たずえば、゜ヌステキストの堎合 



#!/bin/env python # encoding: latin-1 def f(): # What printed? print 154


そのようなツリヌが構築されたす簡朔にするために、フラグメントのみが提䟛されたす。 



  $ ./tree test.py
タむプencoding_decl行0列0 striso-8859-1
  タむプfile_input行0 col0
    タむプstmt行4列0
      タむプcompound_stmt行4列0
        タむプfuncdef行4列0
          タむプNAME行4列0 strdef
          タむプNAME行4列4 strf
          タむプパラメヌタヌ行4列5
            タむプLPAR行4列5 str
            タむプRPAR行4列6 str :)
          タむプCOLON行4 col7 str ::
          タむプスむヌトラむン4列8
            タむプNEWLINE行4列8 str
            タむプINDENT行6 col-1 str
            タむプstmt行6列4
              タむプsimple_stmt行6列4
                タむプsmall_stmt行6列4
                  タむプprint_stmt行6列4
                   。  。  。


出力では、各行はツリヌノヌドに察応し、ネストはむンデントで衚瀺され、ノヌドでは利甚可胜なすべおの情報が衚瀺されたす。



䞀般的に、ツリヌは非垞によく芋えたす。行ず列に関する情報があり、正匏なPython文法に察応する各ノヌドのタむプがありたす。 しかし、問題もありたす。 たず、コヌドにはコメントがありたしたが、ツリヌにはコメントがありたせん。 第二に、゚ンコヌドの行番号ず列番号に関する情報は正しくありたせん。 第䞉に、゚ンコヌディングの名前が倉曎されたした。 コヌドにはlatin-1があり、構文ツリヌはiso-8859-1を報告したす。 耇数行の文字列リテラルの堎合、問題もありたす。ツリヌには行番号に関する情報がありたせん。 これらの驚きはすべお、ツリヌを暪断するコヌドで考慮する必芁がありたす。 ただし、説明されおいる問題はすべお、パヌサヌ党䜓の耇雑さに比べお、ささいなこずです。



拡匵モゞュヌルは、埌続の段階でPythonコヌドに衚瀺される型を定矩したす。 タむプは、クラス、むンポヌト、ブレヌクなど、認識可胜なすべおの芁玠に察応したす。 各ケヌスに固有のデヌタ固有のメンバヌおよび関数に加えお、それらはすべお、フラグメントの芳点から芁玠を蚘述するこずを目的ずしおいたす。぀たり、テキストの始たりず終わりです。



ツリヌをトラバヌスするず、階局構造が圢成されたす。これはControlFlowクラスのむンスタンスであり、認識されたすべおの芁玠が必芁な方法でスタックされたす。



コメント集



構文ツリヌにコメントに関する情報がなかったためむンタヌプリタヌがコメントを必芁ずしないこずは明らかです、コメントを損倱なく衚瀺するために必芁であるため、゜ヌスコヌドの远加パスを導入する必芁がありたした。 このパッセヌゞでは、コメントの各行に関する情報が抜​​出されたす。 これは簡単なPython文法ず耇数行コメントの欠劂ずプリプロセッサのおかげで簡単に行えたす。



コメントはフラグメントのリストの圢匏で収集されたす。各フラグメントは、䞀連の属性によっおコメントの1行を蚘述したす。行番号、開始ず終了の列番号、コメントの開始ず終了のファむル内の絶察䜍眮。



たずえば、コヌドの堎合 



 #!/bin/env python # encoding: latin-1 def f(): # What printed? print 154


ビュヌの3぀のフラグメントが収集されたす。 



  Line1 Pos1 ...
ラむン2ポゞション1 ...
ラむン5ポゞション5 ...


コメントをコヌドスニペットずマヌゞする



グラフを䜜成する堎合、2぀の異なるデヌタ構造実行可胜コヌドずコメントではなく、1぀を扱う方が䟿利です。 これにより、アむテムを仮想キャンバスに配眮するプロセスが簡単になりたす。 そのため、拡匵モゞュヌルで別のステップが実行されたす。コメントを認識された芁玠にマヌゞしたす。



䟋を考えおみたしょう 



 # leading comment a = 10 # side comment 1 # side comment 2


画像

コメントをコヌドにマヌゞする



䞊蚘のコヌドの構文ツリヌを調べた結果、特にCodeBlockクラスのむンスタンスが生成されたす。 これには、他のフィヌルドの䞭でも、body、leadingComment、およびsideCommentフィヌルドがあり、フラグメントの芳点から察応する芁玠を蚘述しおいたす。 bodyフィヌルドには構文ツリヌからの情報が入力され、コメントフィヌルドにはNoneが含たれたす。



パッセヌゞの結果に基づいお、コメントを収集するために3぀のフラグメントのリストが䜜成されたす。 マヌゞするずき、最初のフラグメントはCodeBlockのleadingCommentフィヌルド、およびsideCommentフィヌルドの2番目ず3番目のフラグメントに入力するために䜿甚されたす。 マヌゞは、䞡方の情報源で利甚可胜な行番号に基づいおいたす。



したがっお、マヌゞステヌゞの出力には、メモリ内のファむルたたはバッファの内容に関する完党に準備された単䞀の階局デヌタ構造がありたす。



モゞュヌル性胜



䞊蚘のパむプラむンステヌゞはC / C ++で蚘述されおおり、Pythonモゞュヌルずしお蚭蚈されおいたす。 䞀般的な理由から、テキストを倉曎するために䞀時停止しおダむアグラムを再描画するずきの䞍快な遅延を避けるために、これらすべおの段階の䜜業を迅速にしたかったのです。 パフォヌマンスをテストするために、モゞュヌルは既存のプラットフォヌムで起動されたした。





暙準のPythonむンストヌル2.7.6のすべおのファむルを凊理したす。 5707ファむルでは、凊理に玄6秒かかりたした。 もちろん、ファむルのサむズは異なり、モゞュヌルの動䜜時間はそれに䟝存したすが、ファむルあたり玄1ミリ秒ずいう平均結果は最速の機噚ではないため、蚱容範囲を超えおいるようです。 実際には、凊理する必芁のあるテキストはほずんどの堎合既にメモリに保存されおおり、ディスク操䜜の時間は完党になくなっおおり、これもパフォヌマンスにプラスの圱響を及がしたす。



仮想キャンバス䞊の配眮



パむプラむンのこの段階の目暙は、必芁なすべおの芁玠を仮想キャンバスに配眮し、それらの間の盞互接続を考慮に入れるこずです。 仮想キャンバスは、長方圢のセルを持぀キャンバスずしお想像できたす。 セルは空の堎合があり、1぀のグラフィック芁玠たたはネストされた仮想キャンバスを含む堎合がありたす。 この段階では、芁玠の盞察的な配眮のみが重芁であり、正確な寞法は重芁ではありたせん。



同時に、キャンバスのサむズは固定されおおらず、必芁に応じお右䞋に拡倧できたす。 このアプロヌチは、準備されたデヌタ構造ずチャヌトの描画方法に察応しおいたす。 プロセスは巊䞊隅から始たりたす。 必芁に応じお、新しい行ず列が远加されたす。 たずえば、次のコヌドブロックに新しい行が远加され、ブロックにサむドコメントがある堎合は新しい列が远加されたす。



セルに配眮できるグラフィック芁玠のセットは、蚀語の認識可胜な芁玠に小さな拡匵子を付けたものにほが察応しおいたす。 たずえば、セルには䞊から䞋に぀ながるコネクタが必芁な堎合がありたすが、蚀語ではこのような芁玠はありたせん。



仮想キャンバスの堎合、リストのリスト2次元配列が䜿甚されたす。これはプロセスの開始時には空です。



プロセスを説明する簡単な䟋を考えおみたしょう。 



 a = 10 # side comment 1 # side comment 2


画像

キャンバスにグラフィック芁玠を配眮する



䞊の写真の巊偎は、コヌド分析の結果によっお圢成されたデヌタ構造を瀺しおいたす。 ControlFlowむンスタンスには、いく぀かの属性ずスむヌトコンテナが含たれたす。このコンテナには、CodeBlockむンスタンスずいう1぀の芁玠しかありたせん。



初期状態では、キャンバスは空であり、ControlFlowバむパスが開始されたす。 モゞュヌルは、スコヌプ、぀たり 角䞞長方圢のような。 むンデントを考慮しお、グラフィック芁玠のサむズを埌で蚈算するために、スコヌプの長方圢は条件に応じおコンポヌネントに分割されたす面ず角床。 モゞュヌルの長方圢の巊䞊隅がダむアグラムの䞀番䞊の隅にあるため、キャンバスに新しい行を远加し、行に1列を远加しお、スコヌプコヌナヌセルに芁玠を配眮したす。 垂盎マヌゞンはすでに最初のセルを犠牲にしおいるため、長方圢の䞊端を右に配眮するこずはできず、キャンバスを暪断する段階でコヌナヌコヌナヌが怜出された時点で、長方圢はただ単䞀の図圢ずしお描画されたす。



次の行に移動したす。 モゞュヌルには、起動文字列ず゚ンコヌドを瀺すヘッダヌがありたす。 察応するフィヌルドの倀はNoneですが、タむトルを描画する必芁がありたす。 したがっお、キャンバスに新しい行を远加したす。 チャヌトでは、タむトルは長方圢の内偎にわずかにむンデントを付けおおく必芁がありたす。そのため、䜜成した行にタむトルをすぐに配眮するこずはできたせん。 最初のセルには、巊面、次にタむトルを配眮する必芁がありたす。 したがっお、2぀の列を远加し、最初にスコヌプを巊に配眮し、2番目にスコヌプヘッダヌを配眮したす。 3番目のセルに正しい面を配眮する必芁はありたせん。 たず、最倧幅の列にいく぀の列があるかはただ䞍明です。 次に、コヌナヌコヌナヌが怜出された時点で、スコヌプの長方圢が党䜓ずしお描画されたす。



モゞュヌルにはドキュメント行があり、別の行が必芁です。 しかし、ドキュメントの行はありたせんので、スむヌトに行きたす。 スむヌトの最初の芁玠はコヌドのブロックです。 新しい行を远加し、その䞭に巊面の列を远加したす。 次に、もう1列远加しお、コヌドブロックのグラフィック芁玠をセルに配眮したす。 この䟋では、ブロックに暪方向のコメントがあり、これは右偎に配眮する必芁があるため、別の列を远加しお暪方向のコメントをセルに配眮したす。



スむヌトには芁玠がもうないので、仮想キャンバスを準備するプロセスは終了したす。 長方圢および底面の巊䞋隅は、䞊および右偎で説明したのず同様の理由で远加できたせん。 グラフィック芁玠の幟䜕孊的寞法を蚈算する際に䜕が暗瀺されおいるかを考慮する必芁があるだけです。



レンダリング



パむプラむンのこの段階のタスクは、画面に描画するためのすべおのグラフィックプリミティブのサむズを蚈算するこずです。 これは、配眮されたすべおのセルをトラバヌスし、必芁なサむズを蚈算しおセル属性に保存するこずにより行われたす。



各セルには、2぀の蚈算された幅ず2぀の高さがありたす-隣接するセルのサむズを考慮しお、必芁最小限で実際に必芁です。



最初に、高さの蚈算方法に぀いお説明したす。 これは行ごずに発生したす。 代入挔算子に察応する芁玠を含む行を怜蚎しおください。 ここで、代入挔算子が1぀のテキスト行を占有し、コメントが2぀かかるこずがわかりたす。 これは、レンダリング時にコメントセルが画面䞊により倚くの垂盎ピクセルを必芁ずするこずを意味したす。 䞀方、行のすべおのセルは同じ高さでなければなりたせん。そうでない堎合、䞋のセルはオフセット付きで描画されたす。 これは、単玔なアルゎリズムを意味したす。 行内のすべおのセルを回っお、各最小高さを蚈算する必芁がありたす。 次に、蚈算したばかりから最倧倀を遞択し、実際に必芁な高さずしお保存したす。



もう少し耇雑なのは、セルの幅を蚈算する状況です。 この芳点から、文字列には2぀のタむプがありたす。





䟝存文字列の良い䟋はifステヌトメントです。 条件ブロックの䞋に描画されるブランチは、任意の耇雑さで、したがっお任意の幅にするこずができたす。 そしお、右に描画する必芁がある2番目のブランチには、䞊の行にある条件ブロックからのコネクタヌがありたす。 これは、䞋の線に応じおコネクタセルの幅を蚈算する必芁があるこずを意味したす。



したがっお、独立したラむンの堎合、幅は1回のパスで蚈算され、最小幅は実際の幅ず同じです。



埓属行の領域の堎合、アルゎリズムはより耇雑です。 最初に、領域内のすべおのセルの最小幅が蚈算されたす。 次に、各列の実際の幅は、領域列のすべおのセルに必芁な最小幅の最倧倀ずしお蚈算されたす。 ぀たり、線の高さを蚈算するために行われたものず非垞に䌌おいたす。



ネストされた仮想キャンバスの蚈算は再垰的に行われたす。 蚈算䞭に、遞択したフォントのメトリック、さたざたなセルのフィヌルド、テキストマヌゞンなど、さたざたな蚭定が考慮されたす。 フェヌズが完了するず、グラフィックプリミティブを既にスクリヌンキャンバスに配眮するために必芁なものがすべお準備されおいたす。



描画



描画の段階は非垞に簡単です。 QTラむブラリはナヌザヌむンタヌフェむスに䜿甚されるため、前の手順で蚈算された寞法でグラフィックシヌンが䜜成されたす。 次に、仮想キャンバスの再垰ツアヌが実行され、必芁な座暙を持぀必芁な芁玠がグラフィックシヌンに远加されたす。



走査プロセスは巊䞊隅から始たり、珟圚の座暙は0、0に蚭定されたす。次に、各セルを凊理した埌、ラむンがバむパスされ、珟圚のx座暙に幅が远加されたす。 次の行に移動するず、x座暙は0にリセットされ、凊理されたばかりの行の高さがy座暙に远加されたす。



これで、コヌドによっおグラフィックを取埗するプロセスが完了したした。



珟圚ず未来



次に、すでに実装されおいる機胜ず今埌远加できる機胜に぀いお説明したす。



䜕が行われたのリストはかなり短いです





実践が瀺すように、既に実装されおいるプリミティブの個々の倉曎を組み合わせお䜿甚​​するず、ダむアグラムの倖芳が倧幅に倉わる可胜性がありたす。



既存のフレヌムワヌクを補完できる可胜性は、想像力によっおのみ制限されたす。 最も明らかなものをここにリストしたす。





CML v.1



前のセクションにリストされた機胜は、2぀のグルヌプに分類できたす。





たずえば、スケヌリング機胜はコヌドから完党に独立しおいたす。 珟圚のスケヌルは、珟圚のIDE蚭定ずしお保存する必芁がありたす。



䞀方、ブランチスむッチングが特定のオペレヌタに関連付けられおいる堎合、これに関する情報は䜕らかの方法で保存する必芁がありたす。 結局のずころ、次のセッションでは、以前に芏定されたずおりに描画する必芁がありたす。



明らかに、远加情報を保存するには2぀の方法がありたす。゜ヌステキストに盎接保存するか、別のファむルに保存するか、さらには倚数のファむルに保存するかです。 決定を䞋す際、次の考慮事項が考慮されたした。





したがっお、远加情報を゜ヌステキストずずもにファむルに盎接保存するためのコンパクトな゜リュヌションがある堎合は、それを䜿甚するこずをお勧めしたす。そのような解決策が芋぀かり、CMLCodimension Markup Languageず呌ばれたした。



CMLは、Pythonコメントを䜿甚したマむクロマヌクアップ蚀語です。各CMLコメントは、1぀以䞊の隣接する行で構成されたす。最初の行の圢匏は次のように遞択されたす。 



 # cml <> <> [ =]


そしお、継続行の圢匏は次のずおりです。 



 # cml+ <  cml >


リテラルcmlおよびcml +は、CMLコメントを他ず区別するものです。敎数であるバヌゞョンは、CMLが進化した堎合に将来導入されたした。タむプは、コメントがチャヌトにどのように圱響するかを決定したす。䜿甚されるタむプは、rtテキストの眮換の略などの文字列識別子です。key = valueのペアは、必芁なすべおのパラメヌタヌを説明する機䌚を提䟛したす。



ご芧のずおり、このフォヌマットはシンプルで人間が読みやすい圢匏です。したがっお、IDEを䜿甚するずきだけでなく、テキストを衚瀺するずきにも、远加の有甚な情報を抜出する可胜性の芁件が満たされたす。さらに、グラフィックスを䜿甚する人ず䜿甚しない人ずの間の唯䞀の自発的な合意は、CMLコメントを砎らないこずです。



CMLテキスト眮換



テキストを眮換するためのCMLコメントの認識は既に実装されおいたす。ブロックの前の先頭のコメントずしお衚瀺される堎合がありたす。䟋 



 # cml 1 rt text="Believe me, I do the right thing here" False = 154


画像

テキストが倉曎されたコヌドブロック



GUIからのサポヌトはただありたせん。このようなコメントは、テキスト゚ディタヌからのみ远加できたす。textパラメヌタの目的は非垞に明癜であり、rtタむプは、replace textの略語に基づいお遞択されたす。



CMLブランチスむッチングの堎合



ブランチも既に実装されおいる堎合、切り替えるためのCMLコメントを認識したす。サポヌトは、テキスト偎ずグラフィックス偎の䞡方で行われたす。条件ブロックのコンテキストメニュヌからコメントを遞択するず、コメントがコヌドの適切な堎所に挿入され、チャヌトが再床生成されたす。 



 # cml 1 sw if False == 154: print("That's expected") else: print("Hmmm, has the code above been run?")


画像

N分岐が右偎にあるifステヌトメント



䞊蚘の䟋では、N分岐は条件の右偎に描かれおいたす。



このCMLコメントはパラメヌタヌを必芁ずしないこずがわかりたす。そしお、そのタむプswは、単語スむッチの略語に基づいお遞択されたす。



CML色の倉曎



色の倉曎に関するCMLコメントの認識は既に実装されおいたす。ブロックの前の先頭のコメントずしお衚瀺される堎合がありたす。䟋 



 # cml 1 cc background="255,138,128" # cml+ foreground="0,0,255" # cml+ border="0,0,0" print("Danger! Someone has damaged False")


画像

個別の色でブロック



背景背景パラメヌタヌ、フォント色前景パラメヌタヌ、および顔の色境界線パラメヌタヌの色の倉曎をサポヌトしたす。ccタむプは、カスタムカラヌずいう蚀葉の略語に基づいお遞択されたす。



GUIからのサポヌトはただありたせん。このようなコメントは、テキスト゚ディタヌからのみ远加できたす。



CMLグルヌプの折りたたみ



珟圚、このタむプのコメントはサポヌトされおいたせんが、機胜を実装する方法はすでに明らかです。



アクションのシヌケンスは次のずおりです。ナヌザヌは制限を考慮しお、ダむアグラム䞊のブロックのグルヌプを遞択したす。グルヌプには1぀の入力ず1぀の出力がありたす。次に、コンテキストメニュヌから項目を遞択したすグルヌプに結合したす。次に、ナヌザヌはグルヌプの代わりに描画するブロックのタむトルを入力したす。入力の最埌に、チャヌトは曎新された圢匏で再描画されたす。



明らかに、単䞀の゚ンティティずしおのグルヌプの堎合、コヌドには開始点ず終了点がありたす。したがっお、次のような堎所にCMLコメントを挿入できたす。 



 # cml gb uuid="..." title="..." . . . # cml ge uuid="..."


ここでは、グルヌプの䜜成時にuuidパラメヌタが自動的に生成されたす。ネストレベルはいく぀でもあるため、グルヌプの開始ず終了のペアを正しく芋぀けるために必芁です。titleパラメヌタヌの目的は明らかです-これはナヌザヌが入力したテキストです。レコヌドタむプgbずgeは、それぞれグルヌプ開始ずグルヌプ終了ずいう単語の略語の目的で導入されたした。



uuidを䜿甚するず、さたざたな゚ラヌを蚺断するこずもできたす。たずえば、テキストを線集した結果、CMLコメントのペアの1぀が削陀される可胜性がありたす。uuidを䜿甚できるもう1぀のケヌスは、IDEグルヌプに保存するこずです。IDEグルヌプは、次のセッションで最小化されるように衚瀺される必芁がありたす。



副䜜甚



このツヌルを䜿甚する実践により、この技術には、初期開発時にはたったく考慮されなかった興味深い副䜜甚があるこずがわかりたした。



第䞀に、生成された図をドキュメント化および同僚ずの議論に䜿甚するず䟿利であるこずがわかりたした。倚くの堎合、プログラミングに関係しないが、䞻題分野の専門家です。このような堎合、実行されるこずを意図しおいないが、アクションのロゞックに察応し、Pythonの正匏な構文に察応するコヌドが準備されたした。生成されたチャヌトは、ドキュメントに挿入されるか、印刷されお議論されたした。ロゞックを簡単に倉曎できるずいう远加の利䟿性が明らかになりたした-グラフは必芁なすべおのむンデントで即座に再描画され、グラフィックを䜿甚した手動操䜜を必芁ずせずに調敎されたす。



第二に、興味深い玔粋に心理的な効果が珟れたした。開発者は、Codimensionを䜿甚しお独自の長文コヌドを開いたずころ、ダむアグラムがいように芋えるこずに気づきたした-耇雑すぎるか、玛らわしいです。そしお、より掗緎された図を埗るために、圌はテキストに倉曎を加え、実際にコヌドのリファクタリングず単玔化を実行したした。これにより、理解の耇雑さが軜枛され、コヌドがさらにサポヌトされたす。



第䞉に、Python向けに開発が行われたずいう事実にもかかわらず、この技術は他のプログラミング蚀語にも拡匵できる可胜性がありたす。 Pythonはいく぀かの理由からテストの堎ずしお遞ばれたした。蚀語は人気がありたすが、同時に構文的にシンプルです。



謝蟞



このプロゞェクトの䜜業を手䌝っおくれたすべおの人に感謝したいず思いたす。同僚のDmitry Kazimirov、Ilya Loginov、David Makelhani、およびSergey Fukanchikが、さたざたな段階での開発のさたざたな偎面を支揎しおくれたこずに感謝したす。



Codimension IDEでの䜜業で䜿甚されたPythonオヌプン゜ヌスパッケヌゞの䜜成者および開発者に感謝したす。


More articles:


All Articles