
コードまたはテキストの折りたたみ、またはあまり一般的ではないがホロフレーズ[1]は、一部のグラフィカル ユーザー インターフェイスの機能であり、ユーザーがドキュメントの一部を選択的に非表示 (「折りたたむ」) または表示 (「展開する」) できるようにします。これにより、ユーザーは大量のテキストを管理しながら、現在関心のあるサブセクションのみを表示できます。これは通常、ネストされた要素で構成される自然なツリー構造を持つドキュメントで使用されます。これらの機能の他の名前には、展開と折りたたみ、コードの非表示、アウトラインなどがあります。Microsoft Wordでは、この機能は「折りたたみ可能なアウトライン」と呼ばれています。
多くのユーザー インターフェイスでは、サイドバーにコードを折りたたむための開示ウィジェットが用意されており、たとえば、横向き (折りたたまれている場合) または下向き (展開されている場合) の三角形、[-]または折りたたみ可能な (展開されている) テキスト用のボックスと[+]展開可能な (折りたたまれている) テキスト用のボックスで示されます。
コードの折りたたみは、テキスト エディター、ソース コード エディター、およびIDEで使用されます。折りたたみ構造は通常、コンピューター言語で定義されたプログラムの構文ツリーに従います。また、インデントのレベルによって定義されることもあれば、インバンド マーカー (ソース コードの一部として保存) またはアウトオブバンドを使用して明示的に指定されることもあります。
テキストの折りたたみは、通常のテキストで使用される同様の機能で、ネストされた要素は段落、セクション、またはアウトライン レベルで構成されます。この機能を提供するプログラムには、折りたたみエディター、アウトライナー、一部のワード プロセッサなどがあります。
データ折りたたみは一部の16進エディタに見られ、バイナリファイルを構造化したり、アクセスできないデータセクションを非表示にするために使用されます。[2]
折りたたみは、データの比較でも頻繁に使用され、あるバージョンまたは別のバージョンを選択したり、差異のみを選択したりします。
歴史
エディタにおけるコード折りたたみの最も古い例は、 NLSです。[3]おそらく最初に広く利用された折りたたみエディタは、IBM 370メインフレーム用の 1974 年の構造化プログラミング機能 (SPF) エディタで、インデントに基づいて行を非表示にすることができました。これは、文字マップされた 3270 端末に表示されました。[4]これは、 COBOLのような冗長な言語に非常に便利でした。これは、対話型システム生産性機能 ( ISPF ) に発展しました。
使用
コード折りたたみにはさまざまな使用パターンがあり、主にコードを整理したり、あまり役に立たない情報を隠してより重要な情報に集中できるようにしたりします。一般的なパターンは次のとおりです。[5]
アウトライン
最も基本的な方法として、アプリケーションはコード折りたたみを使用してソース コードのアウトラインを作成し、各ブロックを 1 行に折りたたみます。これは、関数やクラスなどの最上位ブロックのみ、ネストされた関数やメソッドなどのネストされたブロック、またはすべてのブロック、特に制御フロー ブロックにすることができます。これにより、他のコードに気を取られることなく、コードの概要を把握し、簡単にナビゲートして並べ替え、必要に応じて詳細にドリルダウンすることができます。表示の点では、すべての関数のリスト (本体なし) をすばやく表示できます。ナビゲーションの点では、長い関数をページングして過ぎたり、ターゲットを検索したりする必要がなくなり、次の関数に直接移動できます。
定型コードを隠す
一部の言語やライブラリでは、膨大な定型コードが必要になります。その結果、コードが非常に長くなり、要点がわかりにくくなることがあります。さらに、定型コードの中で重要なコードが失われる可能性もあります。
たとえば、Java では、ゲッターとセッターを持つ単一のプライベート フィールドには、それぞれが別々の行にある場合、少なくとも 3 行が必要です。
プライベートString name = null ;パブリックString getName ( ) { return name ; }パブリックvoid setName ( String name ) { this.name = name ; }
これは、従来の関数の改行と関数間のスペース(末尾の改行を含む)を含めて 10 行に拡張されます。
プライベート文字列名= null ;
パブリック文字列getName () {戻り値 name ; }
public void setName ( String name ) { this . name = name ; }
Javadoc を使用したドキュメントでは、これが 20 行に拡張されます。
/**
* プロパティ <code>name</code> は読み取り/書き込み可能です。
*/
private String name = null ;
/**
* プロパティ <code>name</code> の取得
*/
public String getName () { return name ; }
/**
* プロパティ <code>name</code> の設定メソッド。
* @param name
*/
public void setName ( String name ) { this . name = name ; }
このようなフィールドが多数ある場合、その結果は「興味深い」コンテンツがほとんどない数百行のコードになりがちですが、コードの折りたたみにより、これをフィールドごとに 1 行に、またはすべてのフィールドで 1 行に減らすことができます。さらに、すべてのルーチン フィールドが折りたたまれ、非ルーチン フィールド (getter または setter がプライベート フィールドを返したり割り当てたりするだけではないフィールド) が折りたたまれない場合、実質的なコードを確認しやすくなります。
メタデータの折りたたみ
メタデータは長くなる可能性があり、一般的にはそれが記述するデータよりも重要度は低くなります。メタデータを折りたたむことで、メタデータではなくデータに主眼を置くことができます。たとえば、C#の長い属性リストは、次のように手動で折りたたむことができます。[6]
#region 属性
[Browsable(false)]
[MergableProperty(false)]
[DefaultValue(null)]
[PersistenceMode(PersistenceMode.InnerProperty)]
[TemplateContainer(typeof(MyType))]
[TemplateInstance(TemplateInstance.Single)] #endregion public ITemplate ContentTemplate { get ; set ; }
結果のコードは次のように表示されます。
属性
public ITemplate ContentTemplate { get ; set ; }
コメントを折りたたむ
コメントは人間が読めるメタデータの形式であり、長いコメントはコードの流れを乱す可能性があります。これは、1 行を説明する段落など、コードの短いセクションに対する長いコメント、またはJavadocや XML ドキュメントなどのドキュメント ジェネレーターに対するコメントのいずれの場合にも当てはまります。コードの折りたたみにより、長いコメントを使用できますが、必要な場合にのみ表示できます。Python の docstring など、長いコメントに 1 つの要約行がある場合、セクションが折りたたまれているときにも要約を表示できるため、要約/詳細ビューが可能になります。
構造化プログラミングにおける構造またはサンドイッチコードの表示
構造化プログラミングはネストされたコード ブロックで構成されており、長いコード ブロック (長い switch ステートメントなど) は全体の構造をわかりにくくする可能性があります。コードを折りたたむと、全体の構造を確認し、特定のレベルまで展開することができます。さらに、一部の用途、特に厳密な構造化プログラミング (単一関数終了) では、展開されたコードを見るとわかりにくいコード パターンがあります。たとえば、構造化プログラミングのリソース管理では、通常、リソースを取得し、次にリソースを使用するコード ブロックが続き、最後にリソースを解放します。取得と解放のペアは、間に長いコード ブロックがある場合にはわかりにくいですが、介在するブロックが折りたたまれている場合は簡単にわかります。同様に、のような条件付きコードではif...then...else、セカンダリ ブロックが条件ステートメントから離れている場合があります。
グループ化コード
折りたたみグループは、明示的なグループ化(モジュールをセクションに分割したり、クラス メンバーを関連グループに分割するコメント ブロックに類似)または暗黙的なグループ化(アクセス レベル別にクラス メンバーを自動的にグループ化するなど)によってコードをグループ化するために使用できます。
レガシーコードの非表示
レガシー コード、つまり開発者が特定の時点で表示または変更したくないコードは折りたたむことができるため、プログラマーは検討中のコードに集中できます。
ソース内のデータテーブルを非表示にする
コンベンション
コードの折りたたみをサポートするには、テキスト エディターはテキスト ファイル内の「折りたたみポイント」を識別するメカニズムを提供する必要があります。一部のテキスト エディターはこのメカニズムを自動的に提供しますが、他のテキスト エディターは、ユーザーが上書きまたは拡張できるデフォルトを提供します。
さまざまなメカニズムがあり、大まかに自動と手動に分けられますが、プログラマーによる指定は必要ですか? 折りたたみポイントは通常、次のメカニズムの 1 つ以上で決定されます。それぞれに独自の利点と難点があり、基本的にテキスト エディター ソフトウェアを作成する開発者がどのメカニズムを実装するかを決定します。複数の折りたたみメカニズムをサポートするテキスト エディターでは、通常、編集するファイルに最も適したメカニズムをユーザーが選択できます。
構文依存
構文依存の折りたたみポイントは、編集中のファイルの内容に依存して、特定の折りたたみ領域の開始位置と終了位置を指定します。構文ベースの折りたたみポイントは、通常、使用中のマークアップ言語またはプログラミング言語の標準サブ機能の一部またはすべてに基づいて定義されます。これらは自動であり、コード構造と一致するため望ましいものですが、実装にかなりの作業が必要になり、ファイルを編集するときに計算に時間がかかる場合があります。
インデントベース
インデント ベースの折り返しポイントは、通常、テキスト内のタブやスペースなどの印刷されない空白の位置と順序によって指定されます。インデントは、構造化プログラミング言語の インデント スタイルでネスト レベルをほぼ常に反映するため、これは構文ベースの折り返しの単純な形式として最もよく使用されます。
この規則は、オフサイドルールを持つ構文に特に適しているため、構造はインデントとほぼ一致します。例としては、Pythonやテキストファイルなど、それ自体がルールとしてインデントを必要とするものがあります。ただし、これらの場合でも、行継続など、構造はインデントと完全には一致しないため、構文に依存した折りたたみが好まれます。
トークンベース
トークンベースの折り返しポイントは、折り返しポイントの境界を識別する以外の目的を持たない特別な区切り{{{文字を使用して指定されます。この規則は、空白の代わりに印刷可能な文字が使用されるインデントベースの折り返しポイントと比較できます。最も一般的な区切りトークンは、折り返しセクションの開始と}}}終了です。
もう 1 つの注目すべきトークンは、 Microsoft Visual Studio Code Editor#regionで使用される(C# ディレクティブ) と#Region(Visual Basic ディレクティブ)です。これらは構文的にはコンパイラ ディレクティブとして扱われますが、コンパイルには影響しません。
トークンベースの折りたたみは手動の方法であるため、構文解析からは推測できない「特定のタスクに関連する機能」などの任意の基準に基づいてコードをグループ化することができます。
トークンベースのフォールディングでは、インバンド シグナリングが必要です。フォールディング トークンは基本的に構造化されたコメントであり、他の方法とは異なり、ソース コード内に存在し、他のプログラマーに表示されます。これにより、トークンを共有できますが、特定のファイルで作業しているすべてのプログラマーがトークンを使用 (または保存) する必要があり、摩擦やメンテナンスの負担が発生する可能性があります。
ユーザー指定
ユーザー指定の折りたたみにより、ユーザーは汎用的な選択方法を使用してテキストのセクションを折りたたむことができますが、ソース コード (帯域外) は変更されず、エディターでのみ指定されます。たとえば、プログラマーはテキストのいくつかの行を選択し、それらを折りたたむように指定できます。折りたたまれたテキストは匿名または名前付きであり、編集セッション間で保持されるか、破棄されます。トークンベースの折りたたみとは異なり、これはソース テキストを変更しません。したがって、ファイルの他のエディターと共有されず、コードにも表示されません。
例
次のドキュメントには折りたたみトークン ( {{{ ... }}}) が含まれています。
見出し1
{{{
体
}}}
見出し2
{{{
体
}}}
見出し3
{{{
体
}}}
折りたたみエディターにロードすると、アウトライン構造が表示されます。
見出し1
{{{...
見出し2
{{{...
見出し3
{{{...
通常、{{{マークをクリックすると適切な本文が表示されます。
コード折りたたみ機能を備えたソフトウェア
最も初期の折りたたみエディタの 1 つは、1977 年にMike CowlishawによってVM/CMSオペレーティング システム用に作成されたSTETです。STET は、行のブロックに基づいてファイルを折りたたむテキスト エディタ (ドキュメント、プログラムなど用) です。任意の行のブロックを折りたたんで名前行に置き換えることができます (名前行はブロックの一部になる可能性があり、そのブロック自体も折りたたむことができます)。
折りたたみエディタは、 1983年頃にOccam IDE に登場し、Inmos Transputer Development System (TDS) [7] 、[8]と呼ばれていました。"f"エディタ(以下のリスト)は、おそらくこの作業からの最も完全な遺産です。
Macintoshコンピュータには、歴史的に「展開三角形」を介してコードの一部を「折りたたむ」ソースコードエディタがいくつかありました。UserLand Software の製品である Frontier は、この機能を備えたスクリプト環境です。[9]
折りたたみ機能は多くの最新のテキスト エディターで提供されており、構文ベースまたはセマンティクス ベースの折りたたみは現在、多くのソフトウェア開発環境のコンポーネントになっています。エディターには次のものがあります。
その他の編集者
- aoeui、Dvorakに最適化されたエディタ
- Author-it エンタープライズ オーサリングおよびコンポーネント コンテンツ管理ソフトウェア
- f (別名 xf、Winf、Winf32)
- 折りたたみテキストエディタ
- GFAベーシック
- GridinSoft メモ帳
- IntelliJ IDEA (およびその他のJetBrains IDE)
- 基調
- コモド編集
- クライト
- レオ
- LEXX/LPEX(OEDの編集者)[10]
- モノ開発
- ノートタブプロ
- パドレ
- RJ テキストエディタ
- スマルトロン
- ヘスリング編集者
- ビジュアルスタジオ
- WinShell (バージョン 3.30 以降)
- XEDIT (ただし、折りたたみはスクリプトによって行われます)
- ゼウス
参照
- 折りたたみをサポートするその他のエディターについては、テキストエディターの比較記事のプログラミング機能セクションを参照してください。
- アコーディオン(GUI)は、テキストではなく階層リストに適用される同様のUIテクニックです。
注記
- ^ http://flight-manual.atom.io/using-atom/sections/folding/
- ^ トークンベースの折りたたみは、folding マイナー モードによって実装されます。プログラム ソースをセクションに分割するには、 outlineおよびalloutマイナー モードを使用することもできます。
- ^ Universal code folding ノートで提案されているように、Emacs の機能を使用して、インデント レベルに基づいて行を非表示にすることができます。
set-selective-display - ^ 構文依存の折り畳みは、特別な専用のoutline構文のoutlineおよびalloutモード、一部のプログラミング言語のhideshowマイナー モード、さらに、 semantic (CEDET のコンポーネント) でサポートされている構文のsemantic-tag-foldingマイナー モードとコマンド、 JavaDocまたはDoxygenコメントのdoc-mode、対応する言語固有のモードのTeX-fold-mode、コマンド、
nxml-outlnライブラリ、および場合によっては特定の構文の他のモードでサポートされています。 場合によっては、標準の単純なoutlineマイナー モードを使用して、構文ベースの折り畳みをシミュレートします。適切にインデントされた Emacs Lisp ソース コードでの使用、適切にインデントされた HTML での使用 (ページの終わり近くを参照) を参照してください。いくつかの折り畳みメカニズムは、fold-dwimインターフェイスによって統合されています。CategoryHideStuff も参照してください。
senator-fold-tagsgml-fold-element - ^ Emacs でのユーザー選択領域の折りたたみは、
hide-region-hideコマンドによって実装されます。 - ^ この
set_selective_display関数は、指定された量を超えてインデントされた行を非表示にするために使用できます。 - ^ STET は折りたたみをサポートした最初のテキストエディタだったかもしれない[引用が必要]
参考文献
- ^ Simon Gauvin、Omid Banyasad、「ビジュアル データフロー プログラミング言語の制御構造に適用された透明性、ホロフレーズ、自動レイアウト」、2006 ACM ソフトウェア視覚化シンポジウムの議事録、p. 67–75
- ^ 「HxD - フリーウェアの 16 進エディターおよびディスクエディター」mh-nexus . 2007 年 4 月 30 日閲覧。
- ^ Marcel (2012年7月9日)、「The Mother of All Demos, presentation by Douglas Engelbart (1968)」、YouTube 、 2019年12月29日閲覧
- ^ Saint-flour, Gilbert (1998年6月25日). 「ISPFの歴史」. Planet MVS . 2015年10月27日閲覧。
- ^ アトウッド 2008年。
- ^ Rob (2014 年 3 月 19 日)。「これは興味深いですね。私は #region を使って不要な部分 (XML ドキュメントなど、長い属性リストなど) を隠して、重要なコードを見やすくすることが多いのですが…」。コード折りたたみの問題。コーディングホラーディスカッション。2020 年 8 月 6 日のオリジナルからアーカイブ。
- ^ 北米トランスピュータ ユーザー グループ。カンファレンス (第 2 回 : 1989 年 : ノースカロライナ州ダーラム) (1990)。トランスピュータの研究と応用、2 : NATUG-2、第 2 回北米トランスピュータ ユーザー グループ カンファレンスの議事録、1989 年 10 月 18 ~ 19 日、ノースカロライナ州ダーラム。ボード、ジョン A.、デューク大学。アムステルダム: IOS プレス。p. 85。ISBN 9051990278. OCLC 35478471.
{{cite book}}: CS1 maint: 数値名: 著者リスト (リンク) - ^ Cormie, David (1986). 「INMOS テクニカルノート 03 - TDS を使い始める」(PDF) . transputer.net . 2019 年 7 月 19 日閲覧。
- ^ 「Outliners.com」。2006年12月23日時点のオリジナルよりアーカイブ。2006年12月27日閲覧。
- ^ LEXX – プログラム可能な構造化エディタIBM Journal of Research and Development、Vol 31、No. 1、1987、IBM 再版注文番号 G322-0151
- Atwood, Jeff (2008 年 7 月 6 日)。「コード折りたたみの問題」。Coding Horror – コード折りたたみの批判、使用に関する詳細なコメント。
{{cite web}}: CS1 メンテナンス: 追記 (リンク)
外部リンク
- 折りたたみエディターとは何か?エディターの作者による解説
fe。 - occamで使用される折りたたみエディターの説明。
