برنامه‌نویسی ساخت‌یافته
برنامه‌نویسی ساخت‌یافته (به انگلیسی: Structured programming) یک پارادایم برنامه‌نویسی است که طبق آن برنامه‌نویس قدم‌ها و روال‌هایی را که لازم است تا برنامه به جواب برسد را مشخص می‌کند. در این روش از برنامه‌نویسی، انجام یک روال به روال‌های کوچک‌تر تقسیم می‌شود و به این ترتیب یک برنامه با شکسته شدن به ریز برنامه‌های کوچک‌تر سعی می‌کند تا عملکرد مد نظر را پیاده‌سازی کند.
رویه‌ها (به انگلیسی: routines)، زیر رویه‌ها (به انگلیسی: subroutines)، ساختار بلوک (به انگلیسی: block structures) و حلقه‌های for و while در کنار سادگی آزمودن کدها و صرف نظر کردن از Goto که برنامه را به یک کلاف سردرگم (به اصطلاح برنامه‌نویسی: spaghetti code) تبدیل می‌کرد، موجب شدند تا دنبال کردن برنامه و نگهداری از آن تا حد زیادی بهبود یابد.
این پارادایم در دههٔ ۱۹۶۰ توسط بوهن (به انگلیسی: Böhm) و جاکوپینی (به انگلیسی: Jacopini) پدید آمد و در سال ۱۹۶۸ پدیدهٔ معروفی به نام Goto از سوی ادسخر دیکسترا زیان‌آور تشخیص داده شد و این پدیدهٔ تازه به صورت تئوری در قالب برنامه‌نویسی ساخت‌یافته ارائه شد و پس از آن توسط زبان الگول (به انگلیسی: ALGOL) به کمک ساختارهای کنترلی پشتیبانی گردید.
مثال
به عنوان مثال برای نوشتن برنامه‌ای که قراراست اطلاعات نمرات یک محصل را بگیرد و کارنامهٔ آن را چاپ کند، زیر روال‌های زیر لازم است:
- زیر روالی برای خواندن اطلاعات ورودی
- زیر روالی برای جمع‌آوری اطلاعات ورودی و محاسبهٔ معدل
- زیر روالی برای چاپ اطلاعات به صورت یک جدول
- زیر روالی برای اتصال به چاپگر و چاپ گزارش
هر زیر روال آنقدر کوچک می‌شود که برنامه‌نویس بتواند راحت‌تر کار کردن آن را درک کند (هر زیر روال معمولاً ۳۰ خط برنامه‌نویسی است). به این ترتیب برنامه‌نویس با نوشتن هر زیر روال بخشی از برنامه را تولید می‌کند و برنامه‌نویسان مختلف می‌توانند بر روی زیر روال‌های مختلف کار کنند تا در نهایت به اضافه نمودن آن‌ها به یکدیگر برنامهٔ نهایی ساخته شود.
در زبان‌های ساختار یافته توابع کتابخانه‌ای فراوانی وجود دارند که سعی می‌کنند به برنامه‌نویس در برخی از روال‌ها کمک کنند؛ مثلاً برای چاپ در مثال فوق، توابع کتابخانه‌ای برای سهولت انجام کار در این زیر روال، در زبان پاسکال، وجود دارد.
برخی از زبان‌های ساخت یافته:
منابع
- ↑ Böhm, Jacopini. "Flow diagrams, turing machines and languages with only two formation rules" Comm. ACM , 9(5):366-371, May 1966
- ↑ Edsger W. Dijkstra (1968). "Go To Statement Considered Harmful". Communications of the ACM (PDF). 11 (3): 147–148. doi:10.1145/362929.362947.
The unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. … The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one's program.
;