構造化プログラミング

構造化プログラミングは、選択( if /then/else ) と繰り返し ( whileとfor )、ブロック構造、サブルーチンなどの構造化された制御フロー構造を広範に活用することで、コンピュータ プログラムの明瞭性、品質、開発時間を改善することを目的としたプログラミングパラダイムです。

1950年代後半にALGOL 58とALGOL 60プログラミング言語の登場とともに登場し、^[1]後者はブロック構造をサポートしました。最初は学界で、後に実務家の間で人気を博し、広く受け入れられた要因としては、現在では構造化プログラム定理として知られるものが1966年に発見されたこと、^{[2]と、オランダのコンピュータ科学者}エドガー・W・ダイクストラが1968年に発表した影響力のある「Go Toステートメントは有害である」という公開書簡が挙げられます。この公開書簡で「構造化プログラミング」という用語が生み出されました。^[3]

構造化プログラミングは、例外処理を実行する必要がある 場合など、特定のケースでより明確なプログラムを可能にする逸脱を伴う場合が最も頻繁に使用されます。

構造化プログラム定理に従うと、すべてのプログラムは 3 つの制御構造で構成されていると考えられます。

• 「シーケンス」。順番に実行される順序付けられたステートメントまたはサブルーチン。
• 「選択」。プログラムの状態に応じて、複数のステートメントのうちの 1 つが実行されます。これは通常、などのキーワードif..then..else..endifで表現されます。条件ステートメントには、少なくとも 1 つの true 条件が必要であり、各条件には最大 1 つの終了ポイントが必要です。
• 「反復」。プログラムが特定の状態に達するまで、またはコレクションのすべての要素に操作が適用されるまで、ステートメントまたはブロックが実行されます。これは通常while、、、またはなどのキーワードで表現されます。多くのrepeat場合、各ループには 1 つのエントリ ポイントのみを設定することが推奨されます (元の構造化プログラミングでは、終了ポイントも 1 つだけであり、いくつかの言語ではこれを強制しています)。fordo..until

サブルーチン。プロシージャ、関数、メソッド、サブプログラムなどの呼び出し可能なユニットは、シーケンスを単一のステートメントで参照できるようにするために使用されます。

ブロックは、ステートメントのグループを 1 つのステートメントであるかのように扱うために使用します。ブロック構造の言語には、 ALGOL 68if..fiのようにで囲まれた if ステートメント、 PL/IやPascalのようにで囲まれたコード セクション、Pythonのように空白によるインデント、 Cやそれ以降の多くの言語のように中括弧など、何らかの正式な方法で構造を囲む構文があります。 BEGIN..END{...}

構造化プログラミングはどのプログラミング言語でも行うことができますが、手続き型プログラミング言語のようなものを使用する方が望ましいです。^{[4] [5]}構造化プログラミングに最初に使用された言語には、ALGOL、Pascal、PL/I、Ada、RPLなどがありますが、それ以降の新しい手続き型プログラミング言語のほとんどには、構造化プログラミングを促進する機能が含まれており、非構造化プログラミングをより困難にする目的で意図的に機能が省略されていることもありました。 特にGOTOです。

構造化プログラミング（モジュラープログラミング^[4]とも呼ばれる）は、作成されるプログラムに論理構造を適用し、プログラムの効率を高め、理解しやすく、変更しやすいものにします。

構造化プログラム定理は、構造化プログラミングの理論的基礎を提供する。これは、プログラムを組み合わせる 3 つの方法 (順序付け、選択、反復) で、あらゆる計算可能な関数を表現できると述べている。この見解は、構造化プログラミング運動から生まれたものではない。これらの構造は、中央処理装置の命令サイクルやチューリング マシンの動作を記述するのに十分である。したがって、プロセッサは、メモリから読み取った命令が構造化プログラムの一部でなくても、この意味では常に「構造化プログラム」を実行している。ただし、著者は通常、この結果を 1966 年の Böhm と Jacopini の論文に帰しているが、これはおそらくDijkstra自身がこの論文を引用したためだろう。^[6]構造化プログラム定理は、有用な構造化プログラムの書き方や分析方法については触れていない。これらの問題は 1960 年代後半から 1970 年代前半にかけて取り組まれ、主な貢献者はDijkstra、Robert W. Floyd、Tony Hoare、Ole-Johan Dahl、David Griesでした。

構造化プログラミングを早期に採用したPJ Plauger は、構造化プログラム定理に対する反応を次のように述べています。

私たち改宗者は、この興味深いニュースを、複雑なロジックを次々と繰り出し、「これは構造化できないに違いない」と言い続ける、改心していないアセンブリ言語プログラマーの鼻先でちらつかせた。Böhm と Jacopini による証明も、構造化コードを書く私たちの度重なる成功も、彼らが納得する準備が整うより 1 日も早く、彼らを納得させることはできなかった。^[7]

ドナルド・クヌースは、プログラムは証明可能性を考慮して書かれなければならないという原則を受け入れたが、GOTO文の廃止には反対し、2018年現在も^{[アップデート]}プログラムでそれを使い続けている。^[8] 1974年の論文「Goto文による構造化プログラミング」^[9]では、直接ジャンプが証明可能性を犠牲にすることなく、より明確で効率的なコードにつながると信じる例を示した。クヌースはより緩い構造的制約を提案した。プログラムのフローチャートは、すべての前方分岐を左側に、すべての後方分岐を右側に、そして分岐が互いに交差しないように描くことが可能であるべきである。コンパイラとグラフ理論に詳しい人の多くは、簡約可能なフローグラフのみを許可することを提唱している。^{[いつのように定義されるか? ] [誰が? ]}

1970年代、IBMの研究者ハーラン・ミルズが構造化プログラミング理論の解釈をニューヨークタイムズのリサーチファイルのインデックスシステムの開発に応用したことで、構造化プログラミング理論家は大きな味方を得た。このプロジェクトはエンジニアリング上大きな成功を収め、他の企業のマネージャーは構造化プログラミングの採用を支持するためにこのプロジェクトを引用したが、ダイクストラはミルズの解釈が発表された研究と異なる点を批判した。^[10]

1987 年になっても、コンピュータ サイエンスのジャーナルで構造化プログラミングの問題を提起することは可能でした。フランク ルービンは、その年に「『GOTO は有害』とみなされる」と題した公開書簡でその問題提起を行いました。^[11]その後、ダイクストラからの返答を含む多数の反論が続き、ルービンと、彼に返答した他の著者が譲歩した点を厳しく批判しました。

20 世紀の終わりまでに、ほぼすべてのコンピューター科学者は、構造化プログラミングの概念を学んで適用することが有用であると確信しました。FORTRAN 、COBOL、BASICなど、もともとプログラミング構造を欠いていた高級プログラミング言語にも、現在ではプログラミング構造が備わっています。

現在では goto は選択 (if/then/else) と繰り返し (while と for) の構造化された構造に大部分が置き換えられていますが、純粋に構造化された言語はほとんどありません。多くの言語に見られる最も一般的な逸脱は、サブルーチンから早期に終了するためにreturn ステートメントを使用することです。これにより、構造化プログラミングに必要な単一の終了ポイントではなく、複数の終了ポイントが発生します。純粋に構造化されたプログラミングでは扱いにくいケースを処理するための他の構造があります。

構造化プログラミングからの最も一般的な逸脱は、関数またはループからの早期終了returnです。関数レベルでは、これは文です。ループレベルでは、これはbreak文 (ループを終了する) またはcontinue文 (現在の反復を終了し、次の反復に進む) です。構造化プログラミングでは、追加の分岐またはテストを追加することでこれらを再現できますが、ネストされたコードからの戻りの場合、これは大幅な複雑さを追加する可能性があります。Cは、これらの構造の初期の顕著な例です。一部の新しい言語には、最も内側のループだけでなく、それ以上のループから抜け出すことができる「ラベル付きブレーク」もあります。例外でも早期終了が可能ですが、さらに影響があるため、以下で説明します。

複数の終了はさまざまな理由で発生する可能性がありますが、最も一般的な理由は、サブルーチンにそれ以上の作業がないこと (値を返す場合は計算が完了していること)、または続行を妨げる「例外的な」状況に遭遇したことであり、そのため例外処理が必要になります。

早期終了で最も一般的な問題は、クリーンアップまたは最終文が実行されないことです。たとえば、割り当てられたメモリが解放されなかったり、開いているファイルが閉じられなかったりして、メモリ リークやリソース リークが発生します。これらは各戻りサイトで実行する必要があるため、脆弱で、簡単にバグが発生する可能性があります。たとえば、後の開発で、開発者が return 文を見落とし、サブルーチンの終了時に実行する必要があるアクション ( trace文など) がすべてのケースで実行されない可能性があります。標準のPascalやSeed7などの return 文のない言語では、この問題はありません。

最近の言語のほとんどは、このようなリークを防ぐための言語レベルのサポートを提供しています。 ^[12]詳細については、リソース管理を参照してください。最も一般的な方法は、アンワインド保護です。アンワインド保護は、実行がブロックを終了するときに特定のコードが実行されることを保証します。これは、クリーンアップブロックとを持つ構造化された代替手段ですgoto。これは、例外処理として最もよく知られており、例外処理try...finally,の一部と見なされています。例外なしで複数のステートメントを導入する場合は、奇妙に見えるかもしれません。リソース管理をカプセル化するさまざまな手法が存在します。主に C++ で見られる別のアプローチは、リソース取得は初期化であるです。これは、関数終了時に通常のスタックアンワインド（変数の割り当て解除）を使用して、ローカル変数のデストラクタを呼び出してリソースを割り当て解除します。 returntry...finally,

Kent Beck、Martin Fowlerおよび共著者は、リファクタリングに関する本の中で、ネストされた条件文は、ガード句によって述語が付けられた複数の出口を使用する特定のタイプのより平坦な構造よりも理解しにくい可能性があると主張しています。彼らの 2009 年の本では、「1 つの出口ポイントは実際には有用なルールではありません。明確さが重要な原則です。メソッドが 1 つの出口ポイントでより明確になる場合は、1 つの出口ポイントを使用します。そうでない場合は使用しないでください」と明確に述べています。彼らは、ネストされた条件文のみで構成される関数を、ガードされた return (または throw) ステートメントのシーケンスと、それに続くガードされていない単一のブロックに変換するクックブック ソリューションを提供しています。ガードされたステートメントは、あまり一般的でないケース (またはエラー) に対処することになっています。^[13] Herb SutterとAndrei Alexandrescuも、2004 年の C++ のヒントの本で、単一の出口ポイントは時代遅れの要件であると主張しています。^[14]

2004 年の教科書で、デイビッド・ワットは「単一エントリのマルチエグジット制御フローが望ましい場合が多い」と書いている。ワットは、テネントのシーケンサーのフレームワーク概念を使用して、現代のプログラミング言語に見られる制御フロー構造を統一的に説明し、マルチエグジット制御フローのコンテキストで特定のタイプのシーケンサーが他のタイプよりも好ましい理由を説明しようとしている。ワットは、制限のない goto (ジャンプ シーケンサー) は、ジャンプの宛先がプログラムの読者にとって自明ではなく、読者がジャンプのターゲットである実際のラベルまたはアドレスを見つけて調べるまでは不明であるため、良くないと書いている。対照的に、ワットは、リターン シーケンサーの概念的な意図は、宛先を調べなくても、それ自体のコンテキストから明らかであると主張している。ワットは、エスケープ シーケンサーと呼ばれるシーケンサーのクラスは、「テキストで囲まれたコマンドまたはプロシージャの実行を終了するシーケンサー」として定義され、ループからのブレーク (マルチレベル ブレークを含む) と return ステートメントの両方を含むと書いている。ワットはまた、ジャンプ シーケンサー (goto) は C 言語のような言語ではある程度制限されており、ターゲットはローカル ブロック内または外側のブロック内である必要がありますが、その制限だけでは C 言語の goto の意図を自己記述的にするには不十分であり、依然として「スパゲッティ コード」が生成されると指摘しています。ワットはまた、例外シーケンサーがエスケープ シーケンサーやジャンプ シーケンサーとどのように異なるかを調べています。これについては、この記事の次のセクションで説明します。^[15]

上記とは対照的に、ベルトラン・マイヤーは2009年の教科書で、やのような命令は「羊の皮をかぶった古いものにすぎない」breakと書き、その使用を強く勧めなかった。^[16]continuegoto

ソフトウェア開発者の Jim Bonang 氏は、アリアン 501 号の惨事のコーディング エラーに基づいて、関数からスローされる例外はすべて単一出口パラダイムに違反していると主張し、すべての手続き間例外を禁止すべきだと提案しています。Bonang 氏は、単一出口に準拠するすべての C++ は次のように記述すべきだと提案しています。

bool MyCheck1 () throw () { bool success = false ; try { // 例外をスローする可能性のある操作を実行します。if ( ! MyCheck2 ()) { throw SomeInternalException (); } // 上記と同様のその他のコード。success = true ; } catch (...) { // すべての例外がキャッチされ、ログに記録されます。} return success ; }   
     
   
    
      
       
    
    
      
     
    
  
   

ピーター・リッチーも、原則として関数内の のthrow直前の 1 つの権利でもreturn単一出口原則に違反すると指摘しているが、ダイクストラの規則は例外処理がプログラミング言語のパラダイムとなる前に書かれたものであるため、単一の戻りポイントに加えて任意の数のスローポイントを許可することを提案している。彼は、単一出口を作成するために例外をラップするソリューションはネストの深さが高く、したがって理解するのがより困難であると指摘し、そのようなソリューションを例外をサポートするプログラミング言語に適用することを提案する人々をカーゴカルトの考え方に従事していると非難している。^[17]

David Watt 氏は、シーケンサーのフレームワークにおける例外処理も分析しています (この記事の前のセクションの早期終了で紹介されています)。Watt 氏は、異常な状況 (通常は算術オーバーフローやファイルが見つからないなどの入出力エラーで例えられます) は、「低レベルのプログラム ユニットで検出されるが、ハンドラーは高レベルのプログラム ユニットに配置する方が自然である」タイプのエラーであると指摘しています。たとえば、プログラムにはファイルを読み取るための呼び出しが複数含まれている可能性がありますが、ファイルが見つからない場合に実行するアクションは、プログラムにとっての当該ファイルの意味 (目的) によって異なるため、この異常な状況の処理ルーチンを低レベルのシステム コードに配置することはできません。さらに、ワッツは、単一出口構造化プログラミングや (複数出口の) 戻りシーケンサーのように、呼び出し元でステータス フラグ テストを導入すると、「アプリケーション コードがステータス フラグのテストで乱雑になる傾向がある」ことや、「プログラマーがステータス フラグのテストを忘れたり怠慢に省略したりする可能性がある」ことにも言及しています。実際、ステータス フラグによって表される異常な状況は、デフォルトでは無視されます。ステータス フラグ テストとは対照的に、例外はデフォルトの動作が逆であり、プログラマーが何らかの方法で明示的に例外を処理しない限り、プログラムが終了すると指摘しています。例外を意図的に無視するコードを追加するなどです。これらの議論に基づいて、ワッツは、ジャンプ シーケンサーまたはエスケープ シーケンサー (前のセクションで説明) は、上記のセマンティクスを備えた専用の例外シーケンサーほど適切ではないと結論付けています。^[18]

ラウデンとランバートの教科書では、例外処理はwhileループなどの構造化プログラミング構造とは異なると強調されている。その理由は、制御の移行が「実際の移行が行われるプログラムとは異なるポイントで設定されるからである。移行が実際に行われるポイントでは、制御が実際に移行されるという構文上の兆候がない可能性がある」からである。^[19]コンピュータサイエンスの教授であるアルビンド・クマール・バンサルは、例外処理を実装する言語では、for例外がない場合には単一出口特性を持つ のような制御構造であっても、例外がある場合はその特性を持たなくなると指摘している。これは、例外によって制御構造のどの部分でも早期に終了する可能性があるためである。たとえば、 が でinit()例外をスローするとfor (init(); check(); increm())、check() 後の通常の終了ポイントに到達しない。^{[20]ウェストリー・ワイマーと}ジョージ・ネキュラは、他の研究者による複数の先行研究 (1999～2004 年) と自身の研究結果を引用し、例外の重大な問題は「プログラマが推論するのが難しい隠れた制御フロー パスが作成される」ことだと書いている。^[21]

コードを単一の終了ポイントに制限する必要性は、OpenMPなどの並列コンピューティングに重点を置いたいくつかの現代のプログラミング環境に現れています。OpenMPのさまざまな並列構造、たとえばは、並列構造の内部から外部への早期終了を許可していません。この制限には、からC++例外までのあらゆる種類の終了が含まれますが、ジャンプターゲットも並列構造内にある場合は、これらすべてが並列構造内で許可されます。^[22]parallel dobreak

より稀に、サブプログラムが複数エントリを許可することがあります。これは、コルーチン(またはジェネレータ/セミコルーチン)への再エントリのみが最も一般的であり、サブプログラムは制御 (および場合によっては値) を譲りますが、その後、中断したところから再開できます。このようなプログラミングの一般的な用途は多数あり、特にストリーム(特に入力/出力)、ステート マシン、および並行性でよく使用されます。コード実行の観点からは、コルーチンからの譲歩はサブルーチンからの戻りよりも構造化プログラミングに近いです。サブプログラムは実際には終了しておらず、再度呼び出されると続行されるためです。これは早期終了ではありません。ただし、コルーチンでは、サブルーチンの単一の呼び出しスタックではなく、複数のサブプログラムが実行状態を持つため、異なる形式の複雑さが生じます。

サブプログラムがサブプログラム内の任意の位置へのエントリを許可することは非常にまれです。この場合、プログラムの状態 (変数値など) は初期化されていないかあいまいであり、これは goto と非常によく似ています。

一部のプログラム、特にパーサーや通信プロトコルには、簡単には基本構造に還元できないような複数の状態が連続しており、一部のプログラマーは新しい状態へのジャンプで状態の変更を実装しています。このタイプの状態切り替えは、Linux カーネルでよく使用されます。^{[引用が必要]}

ただし、各状態変更を個別のサブプログラムにして、アクティブな状態を示す変数を使用することで、これらのシステムを構築することができます (トランポリンを参照)。または、トランポリンを使わずにコルーチンを介して実装することもできます。

• ドラコン
• 最小限の評価
• ナッシ・シュナイダーマン図
• 構造図
• 構造化された同時実行
• スイッチ文

ウィキブックのコンピュータプログラミングには、制御に関するページがあります。

• BPStruct - 並行システム（プログラム、プロセス モデル）を構造化するツール
• J. Darlinton、M. Ghanem、HW To (1993)、「構造化並列プログラミング」、超並列コンピュータのプログラミング モデル。IEEE Computer Society Press。1993 : 160–169、CiteSeerX  10.1.1.37.4610