>>767-768
>ばかばかしい

ID:SNA+12OI は、御大か
巡回ご苦労様です

まったくね
アホが、”ばかばかしい”話をしている

笑える
”フローチャートは構造化されてないので”・・とは、これいかにｗ
”フローチャート”自身は、構造化も非構造化も関係ないですよ！（下記）

(参考)
https://ja.wikipedia.org/wiki/%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
構造化プログラミング（英: structured programming）は、コンピュータプログラムの処理手順の明瞭化、平易化、判読性向上を目的にしたプログラミング手法である。
#ダイクストラの構造化プログラミングは、プログラム正当性検証技術の確立を原点にして構想された数々のプログラム開発理論の複合体である。詳しくは当該の節を参照。

https://upload.wikimedia.org/wikipedia/commons/e/ec/Structured_program_patterns.png
（図解 順次、選択、反復の描写図（青はNSダイアグラム、緑はフローチャート））

制御構造の導入は1960年公開の「ALGOL60」まで遡れるが、当時広く使われていたFORTRANやCOBOLでの正式導入は1977年以降だったので、多くの開発現場では馴染みのないものであった

1966年にコラド・ベームらが「順次・選択・反復」のフロー万能性を数学的に証明したが、それはあくまで論理的研究だった。それを参考にしたとされるダイクストラの1968年の投書「goto文は有害」はいわゆるgoto文論争を引き起こした

構造化設計
→詳細は「段階的詳細化法」を参照
上述の制御構文をコーディング視点の下流工程テクニックとすると、構造化設計（structured design）はプログラムデザイン視点の上流工程テクニックであり、こちらも構造化プログラミングと呼ばれるものである。構造化設計では、サブルーチン（subroutine）をまとめたサブルーチン複合体と、データ要素をまとめたデータ構造（data structure）が主要な役割を果たしている