「手続き型プログラミング」の版間の差分

削除された内容 追加された内容
Slappi (会話 | 投稿記録)
編集の要約なし
5行目:
'''手続き型プログラミング'''({{lang-en-short|''Procedural programming''}})は、手続き(''procedure'')の定義と呼び出しによるプログラムの構造化を重視している[[プログラミングパラダイム|パラダイム]]名義であり、同時にそれと[[ステートメント]]基本文を採用した初期の[[高水準言語]]の仕様を指している用語でもある。[[命令型プログラミング]]と同義で使われることも多い。[[モジュール|モジュール方式]]や[[オブジェクト指向プログラミング|オブジェクト指向]]が導入されていない[[FORTRAN]]、[[COBOL]]、[[ALGOL]]、[[BASIC]]、[[Pascal]]、[[C言語]]といった初期の[[高水準言語]]のプログラミング様式を漠然と表現しているパラダイムでもある。
 
手続きは言語によってサブルーチン、関数、サブプログラムとも呼ばれており、一定の命令コードのまとまりを任意の手続き名に結び付けたコードユニットである。手続きは入力されたパラメータ引数によってそのプロセスを多相化し、処理結果となるリターン値を出力する事ができる。入出力値無しの手続きも定義できる。手続きは一般的に[[非決定性有限オチュリングン]]の性質準拠し沿っているので、入力値による処理内容とそこからの出力値は、その手続き枠外の外部環境状態によっても変化する。この遷移図の可変性を指して手続き的(''procedural'')とも言われる。
 
== 特徴 ==
28行目:
手続き型プログラミングと[[構造化プログラミング]]は、同じテーマでよく用いられる言葉である。構造化プログラミングの定義はやや曖昧であるが、コード記述視点とプログラム設計視点の二つから解釈される。前者のコード記述視点では、順接・分岐・反復の三つの[[制御構造|制御構文]]を用いて[[goto文]]を極力用いないソースコード記述を重視したプログラミングスタイルになる。[[構造化定理]]がよく引き合いに出されて、それに[[サブルーチン]]による適切なプログラム分割が加えられることもある。
 
後者のプログラム設計視点では、プログラム全体の適切な[[モジュール]]分割を図り、各モジュールの[[凝集度]]およびモジュール間の[[結合度]]の適切な設定を重視したプログラミングパラダイムになる。プログラム全体をモジュールの組み合わせとそれらの連携で構築しようとする考え方である。このモジュールによるプログラムの構造化は、1970年前後から盛んに研究され始めて「structured design(SD)」「structured analysis(SA)」「[[ジャクソンの構造化プログラミング|Jackson structured programming]](JSP)」「[[構造化分析設計技法|structured analysis and design technique]](SADT)」「[[SSADM|structured systems analysis and design method]](SSADM)」「modern structured analysis」といった数々の[[ソフトウェア工学]]技法が発表されている。グレンフォード・マイヤーズ、ラリー・コンスタンティン、マイケル・ジャクソン、[[エドワード・ヨードン]]、[[トム・デマルコ]]などが有名である。
 
=== 命令型プログラミング ===
手続き型プログラミングは[[命令型プログラミング]]の分類に属している。これが意味する主なプログラム上の枠組みは、(A)手続きはパラメータ無しでもよくリターン値がなくてもよい、(B)手続き内ではグローバル変数とローカル静的変数と外部環境データが自由に変更される、(C)手続きは外部データおよび外部環境状態の影響を無制限に受けるので同じパラメータに対する処理内容とそのリターン値は一定ではない、の三点になる。
 
また、手続き型プログラミングと命令型プログラミングは、[[オートマトン|オートマタ理論]]の[[非決定性有限オチュリングン]]見地視点からの同じ意味で用いられていることも多い。手続き的(''procedural'')の用法としてはこちらの方が標準であり、命令型(''imperative'')の同義語になっている。この「手続き的」の意味も上述の(A)(B)(C)と同じであり、プロセスが顕在的な(''declarative'')パラメータ以外の潜在的な外部情報要素にも影響されてそのリターンが[[参照透過性|参照不透過]]になるという特性を示している。
 
== 歴史 ==
手続き(''procedure'')の考え方自体はコンピュータ黎明期の[[機械語]]コードの時代から存在している。手続きの実装方式は、アセンブラなどの[[低水準言語]]で用いられる[[ニーモニック・コード|ニーモニックコード]]のCALL命令とRET命令が原点である。PUSH命令による引数の[[スタック|スタックメモリ]]への積み込みと、スタックポインタレジスタの減算による自動変数領域の確保、ベースポインタレジスタによる引数と自動変数の参照といった[[スタックフレーム]]の機能もアセンブラ由来のものである。CALL命令のジャンプ先アドレスに付けられたラベルは手続き名と同義になった。その仕組みは1950年代半ばから登場した[[高水準言語]]にもそのまま受け継がれた。ラベルは形式化されたパラメータリスト付きのプロシージャネームになり、スタックフレーム処理も自動化され、命令コード行のまとまりはソースコード上で明確に区分けされたコードブロックとして表現された。こうして手続き(プロシージャ)は低水準言語から高水準言語への移行期に言わばごく自然に誕生している。
 
なお、史上初の高水準言語として1954年に公開されたFORTRANは、CALL命令とRET命令を備えていなかったので手続きの形式も持っていなかった。初代FORTRANのプログラムはPROGRAMという定義文で括られた一つのメインルーチンで記述されていた。故にこれは非手続き型言語とも言える。プログラム規模の急速な拡大ですぐにサブルーチン構造も必要になり、1958年に発表されたFORTRANⅡではCALL命令とRET命令が追加された。メインルーチンから分けられたサブルーチンは「External Procedure(外部手続き、邦訳は外部副プログラム)」と定義され、その呼び出しを多用するプログラム記述がなされるようになった。また、コンピュータプログラマが操作するプログラミング言語を手続き型言語とし、コンピュータオペレータが操作する[[問い合わせ言語]]や[[シェルスクリプトジョブ制御言語]]を非手続き型言語とする分類用法もあった。後者は基本的に一行から数行程度のコード入力で処理実行するからである。
 
== 他のパラダイムとの対比 ==