البرمجة الهيكلية

تُقدّم نظرية البرنامج المُهيكل الأساس النظري للبرمجة المُهيكلة. وتنص على أن ثلاث طرق لدمج البرامج - التسلسل، والاختيار، والتكرار - كافية للتعبير عن أي دالة قابلة للحساب . لم تنشأ هذه الملاحظة مع حركة البرمجة المُهيكلة؛ فهذه الهياكل كافية لوصف دورة تعليمات وحدة المعالجة المركزية ، وكذلك تشغيل آلة تورينج . لذلك، يُنفّذ المعالج دائمًا "برنامجًا مُهيكلًا" بهذا المعنى، حتى لو لم تكن التعليمات التي يقرأها من الذاكرة جزءًا من برنامج مُهيكل. ومع ذلك، يُنسب المؤلفون عادةً هذه النتيجة إلى ورقة بحثية نُشرت عام 1966 من قِبل بوم وجاكوبيني، ربما لأن ديكسترا نفسه استشهد بهذه الورقة. ^{[ 5 ]} لا تتناول نظرية البرنامج المُهيكل كيفية كتابة وتحليل برنامج مُهيكل مفيد. تمت معالجة هذه القضايا خلال أواخر الستينيات وأوائل السبعينيات، بمساهمات كبيرة من ديجكسترا ، وروبرت دبليو فلويد ، وتوني هوار ، وأولي يوهان دال ، وديفيد جريس .

وصف بي جيه بلاوجر ، أحد أوائل من تبنوا البرمجة الهيكلية، رد فعله على نظرية البرمجة الهيكلية:

لوّح المتحولون منّا بهذه المعلومة المثيرة للاهتمام أمام أعين مبرمجي لغة التجميع الذين لم يتخلوا عن مبادئهم، والذين استمروا في طرح عبارات منطقية معقدة قائلين: "أراهن أنكم لا تستطيعون هيكلة هذا". لم ينجح لا برهان بوم وجاكوبيني ولا نجاحاتنا المتكررة في كتابة التعليمات البرمجية المهيكلة في إقناعهم قبل أن يكونوا مستعدين لذلك. ^{[ 6 ]}

قبل دونالد كنوث مبدأ ضرورة كتابة البرامج مع مراعاة إمكانية إثباتها، لكنه اختلف مع إلغاء عبارة GOTO، واعتبارًا من عام 2018استمر في استخدامها في برامجه. ^{[ 7 ]} في ورقته البحثية عام 1974 بعنوان "البرمجة المهيكلة باستخدام عبارات Goto"، ^{[ 8 ]} قدم أمثلةً اعتقد فيها أن القفزة المباشرة تؤدي إلى كود أكثر وضوحًا وكفاءةً دون التضحية بإمكانية الإثبات. اقترح كنوت قيدًا هيكليًا أقل صرامة: ينبغي أن يكون من الممكن رسم مخطط تدفق البرنامج بحيث تكون جميع الفروع الأمامية على اليسار، وجميع الفروع الخلفية على اليمين، ولا تتقاطع أي فروع مع بعضها البعض. وقد دعا بعض الخبراء في المترجمات ونظرية الرسوم البيانية إلى السماح فقط بمخططات التدفق القابلة للاختزال .

اكتسب منظرو البرمجة الهيكلية حليفًا قويًا في سبعينيات القرن الماضي بعد أن طبّق الباحث هارلان ميلز من شركة IBM تفسيره لنظرية البرمجة الهيكلية على تطوير نظام فهرسة لملف أبحاث صحيفة نيويورك تايمز . حقق المشروع نجاحًا هندسيًا باهرًا، واستشهد به مديرو الشركات الأخرى لدعم تبني البرمجة الهيكلية، على الرغم من أن ديكسترا انتقد أوجه الاختلاف بين تفسير ميلز والأبحاث المنشورة. ^{[ 9 ]}

حتى عام 1987، كان لا يزال من الممكن طرح مسألة البرمجة الهيكلية في إحدى مجلات علوم الحاسوب. وقد فعل فرانك روبين ذلك في ذلك العام برسالة مفتوحة بعنوان "استخدام عبارة GOTO يُعتبر ضارًا". ^{[ 10 ]} وتلت ذلك اعتراضات عديدة، من بينها ردٌّ من ديكسترا انتقد فيه روبين بشدة، وكذلك التنازلات التي قدمها كتّاب آخرون عند الرد عليه.

بحلول نهاية القرن العشرين، اقتنع جميع علماء الحاسوب تقريباً بأهمية تعلم وتطبيق مفاهيم البرمجة الهيكلية. أما لغات البرمجة عالية المستوى التي كانت تفتقر في الأصل إلى هياكل البرمجة، مثل فورتران وكوبول وبيسيك ، فقد أصبحت الآن تتضمنها.

تُتيح معظم لغات البرمجة عبارة إرجاع تسمح بنقاط خروج متعددة ومبكرة من الدالة . وبما أن الدالة عبارة عن كتلة برمجية، فإن هذه الميزة تُخالف نقطة الخروج الوحيدة الموصوفة في النظرية.

تُتيح العديد من لغات البرمجة إمكانية الخروج المبكر من كتلة برمجية (بخلاف استخدام عبارة return). على سبيل المثال، قد يدعم بناء حلقة تكرارية عبارة break التي تُنهي كتلة الحلقة قبل نهايتها. وكما تُبيّن النظرية، يُمكن الاستغناء عن منطق الخروج المبكر هذا بإضافة فروع أو اختبارات، ولكن هذا قد يُضيف تعقيدًا كبيرًا. تُعدّ لغة C مثالًا مبكرًا وبارزًا على هذه البنى. كما تحتوي بعض اللغات الحديثة على "عبارات break مُصنّفة"، والتي تُتيح الخروج من أكثر من مجرد الحلقة الداخلية.

قد تنشأ الحاجة إلى مخارج متعددة لأسباب متنوعة، وغالبًا ما يكون ذلك إما لأن الدالة لم يعد لديها المزيد من العمل للقيام به (إذا كانت تُرجع قيمة، فقد أكملت الحساب)، أو أنها واجهت ظروفًا "استثنائية" تمنعها من الاستمرار، وبالتالي تحتاج إلى معالجة الاستثناءات.

من مشاكل الخروج المبكر احتمال عدم تنفيذ تعليمات التنظيف. على سبيل المثال، قد لا يتم تحرير الذاكرة المخصصة، أو قد لا يتم إغلاق الملفات المفتوحة، مما يؤدي إلى تسرب الذاكرة والموارد . يجب إجراء التنظيف عند كل نقطة إرجاع، وهو أمر هشّ وقد يؤدي بسهولة إلى ظهور أخطاء. على سبيل المثال، في مراحل التطوير اللاحقة، قد يتجاهل المطور عبارة الإرجاع، وقد لا يتم تنفيذ إجراء يُفترض تنفيذه في نهاية الدالة (مثل عبارة التتبع ) في جميع الحالات. أما اللغات التي لا تحتوي على عبارة إرجاع، مثل باسكال ، وليسب ، وأو كاميل ، فلا تعاني من هذه المشكلة.

توفر معظم لغات البرمجة الحديثة دعمًا على مستوى اللغة لمنع مثل هذه التسريبات ^{[ 11 ]} (انظر إدارة الموارد ). وكبديل منظم لاستخدام عبارة goto وكتلة التنظيف، تضمن حماية فك الالتفاف تنفيذ جزء معين من التعليمات البرمجية عند الخروج من كتلة التنفيذ؛ وغالبًا ما يتم تطبيقها بالتزامن مع معالجة الاستثناءات باستخدام عبارة try-finally. أما في لغة C++، فيُستخدم أسلوب بديل يتمثل في الحصول على الموارد عند التهيئة ، والذي يعتمد على فك الالتفاف العادي للمكدس (إلغاء تخصيص المتغيرات) عند الخروج من الدالة لاستدعاء دوال التدمير على المتغيرات المحلية لإلغاء تخصيص الموارد.

جادل كينت بيك ومارتن فاولر وزملاؤهما في كتبهم عن إعادة هيكلة البرامج بأن العبارات الشرطية المتداخلة قد تكون أصعب فهمًا من نوع معين من البنية المسطحة التي تستخدم مخارج متعددة مشروطة بعبارات حماية . وينص كتابهم الصادر عام 2009 صراحةً على أن "نقطة خروج واحدة ليست قاعدة مفيدة حقًا. الوضوح هو المبدأ الأساسي: إذا كانت الدالة أوضح بنقطة خروج واحدة، فاستخدمها؛ وإلا فلا تستخدمها". ويقدمون حلاً عمليًا لتحويل دالة تتكون فقط من عبارات شرطية متداخلة إلى سلسلة من عبارات الإرجاع (أو الاستثناء) المحمية، متبوعة بكتلة واحدة غير محمية، والتي يُفترض أن تحتوي على شيفرة الحالة الشائعة، بينما يُفترض أن تتعامل العبارات المحمية مع الحالات الأقل شيوعًا (أو مع الأخطاء). ^{[ 12 ]} كما يجادل هيرب سوتر وأندريه ألكسندرسكو في كتابهما عن نصائح لغة C++ الصادر عام 2004 بأن نقطة الخروج الواحدة أصبحت مطلبًا عفا عليه الزمن. ^{[ 13 ]}

في كتابه الدراسي الصادر عام ٢٠٠٤، يذكر ديفيد وات أن "تدفقات التحكم ذات المدخل الواحد والمخارج المتعددة مرغوبة في كثير من الأحيان". وباستخدام مفهوم " المُسلسل" الذي وضعه تيننت ، يصف وات بشكل موحد بنيات تدفق التحكم الموجودة في لغات البرمجة المعاصرة، ويحاول شرح سبب تفضيل أنواع معينة من المُسلسلات على غيرها في سياق تدفقات التحكم متعددة المخارج. ويشير وات إلى أن عبارات "goto" غير المقيدة (مُسلسلات القفز) غير مرغوبة لأن وجهة القفزة لا تكون واضحة لقارئ البرنامج حتى يعثر على العنوان أو التسمية الفعلية التي تمثل هدف القفزة ويفحصها. في المقابل، يرى وات أن الغرض المفاهيمي لمُسلسل الإرجاع واضح من سياقه، دون الحاجة إلى فحص وجهته. ويذكر وات أن فئة من المُسلسلات تُعرف باسم مُسلسلات الهروب ، والتي تُعرَّف بأنها "مُسلسل يُنهي تنفيذ أمر أو إجراء مُحاط بنص"، تشمل كلاً من الخروج من الحلقات (بما في ذلك الخروج متعدد المستويات) وعبارات الإرجاع. يشير وات أيضًا إلى أنه على الرغم من تقييد استخدام تسلسلات القفز (goto) في لغات مثل C، حيث يجب أن يكون الهدف داخل الكتلة المحلية أو كتلة خارجية محيطة بها، فإن هذا التقييد وحده لا يكفي لجعل الغرض من استخدام goto في C واضحًا بذاته، وبالتالي لا يزال من الممكن أن ينتج عنه " كود معقد ". كما يتناول وات كيفية اختلاف تسلسلات الاستثناءات عن تسلسلات الهروب والقفز؛ وسيتم شرح ذلك في القسم التالي من هذه المقالة. ^{[ 14 ]}

على النقيض مما سبق، كتب برتراند ماير في كتابه المدرسي الصادر عام 2009 أن تعليمات مثل "break" و"continue" ليست سوى حيل قديمة مُقنّعة، ونصح بشدة بعدم استخدامها. ^{[ 15 ]}

يشير بيتر ريتشي إلى أنه من حيث المبدأ، حتى مجرد رمية استثناء واحدة قبل نقطة العودة تُعدّ انتهاكًا لمبدأ الخروج الأحادي، لكنه يجادل بأن قواعد ديكسترا كُتبت في زمنٍ لم تكن فيه معالجة الاستثناءات نموذجًا سائدًا في لغات البرمجة، لذا فهو يقترح السماح بأي عدد من نقاط الرمي بالإضافة إلى نقطة عودة واحدة. ويشير إلى أن الحلول التي تُغلّف الاستثناءات بهدف إنشاء خروج واحد تتميز بعمق تداخل أكبر، وبالتالي يصعب فهمها، بل ويتهم أولئك الذين يقترحون تطبيق مثل هذه الحلول على لغات البرمجة التي تدعم الاستثناءات بالانخراط في تفكيرٍ أعمى . ^{[ 16 ]}

يُحلل ديفيد وات أيضًا معالجة الاستثناءات في إطار عمل المُسلسلات (التي تم تقديمها في هذا المقال في القسم السابق حول الخروج المبكر ). ويشير وات إلى أن الحالة الشاذة (والتي تتمثل عادةً في تجاوزات العمليات الحسابية أو فشل الإدخال/الإخراج مثل عدم العثور على الملف) هي نوع من الأخطاء التي "يتم اكتشافها في وحدة برمجية منخفضة المستوى، ولكن من الأنسب أن يكون مُعالجها موجودًا في وحدة برمجية عالية المستوى". على سبيل المثال، قد يحتوي البرنامج على عدة استدعاءات لقراءة الملفات، ولكن الإجراء الذي يتم تنفيذه عند عدم العثور على ملف يعتمد على معنى (غرض) الملف المعني بالنسبة للبرنامج، وبالتالي لا يمكن تحديد روتين معالجة هذه الحالة الشاذة في كود النظام منخفض المستوى. ويشير واتس كذلك إلى أن إدخال اختبارات علامات الحالة في الدالة المستدعِية، كما هو الحال في البرمجة الهيكلية ذات المخرج الواحد أو حتى في مُسلسلات الإرجاع (ذات المخارج المتعددة)، يؤدي إلى حالة "يميل فيها كود التطبيق إلى أن يصبح مزدحمًا باختبارات علامات الحالة"، وأن "المبرمج قد ينسى أو يتجاهل اختبار علامة حالة ما. في الواقع، يتم تجاهل الحالات الشاذة التي تمثلها علامات الحالة افتراضيًا!". ويلاحظ أنه على عكس اختبار علامات الحالة، فإن الاستثناءات لها سلوك افتراضي معاكس ، مما يؤدي إلى إنهاء البرنامج ما لم يتعامل المبرمج مع الاستثناء بشكل صريح بطريقة ما، ربما عن طريق إضافة كود لتجاهله عمدًا. بناءً على هذه الحجج، يخلص واتس إلى أن مُسلسلات القفز أو مُسلسلات الهروب (التي نوقشت في القسم السابق) ليست مناسبة مثل مُسلسل استثناءات مخصص بالدلالات المذكورة أعلاه. ^{[ 17 ]}

يؤكد كتاب لودن ولامبرت أن معالجة الاستثناءات تختلف عن بنيات البرمجة الهيكلية مثل حلقات while، لأن نقل التحكم "يتم إعداده في نقطة مختلفة من البرنامج عن النقطة التي يحدث فيها النقل الفعلي. عند النقطة التي يحدث فيها النقل فعليًا، قد لا يكون هناك أي مؤشر نحوي على أن التحكم سينتقل بالفعل." ^{[ 18 ]} ويشير أستاذ علوم الحاسوب أرفيند كومار بانسال أيضًا إلى أنه في اللغات التي تُنفذ معالجة الاستثناءات، حتى بنيات التحكم مثل for، التي تتمتع بخاصية الخروج الفردي في غياب الاستثناءات، تفقد هذه الخاصية في وجود الاستثناءات، لأن الاستثناء قد يتسبب في خروج مبكر في أي جزء من بنية التحكم؛ على سبيل المثال، إذا init()أطلق استثناءً في دالة for (init(); check(); increm())check()، فلن يتم الوصول إلى نقطة الخروج المعتادة بعد check(). ^{[ 19 ]} وبالاستناد إلى دراسات سابقة متعددة أجراها باحثون آخرون (1999-2004) ونتائجهم الخاصة، كتب ويستلي وايمر وجورج نيكولا أن إحدى المشكلات الرئيسية في الاستثناءات هي أنها "تُنشئ مسارات تحكم خفية يصعب على المبرمجين فهمها". ^{[ 20 ]}

تظهر ضرورة تقييد التعليمات البرمجية بنقاط خروج واحدة في بعض بيئات البرمجة المعاصرة التي تركز على الحوسبة المتوازية ، مثل OpenMP . لا تسمح بنيات التوازي المختلفة في OpenMP، مثل ` parallel do_____________، بالخروج المبكر من داخل بنية التوازي إلى خارجها؛ يشمل هذا القيد جميع أنواع الخروج، بما في ذلك `break` والاستثناءات، ولكن يُسمح بكل هذه الأنواع داخل بنية التوازي إذا كان هدف القفز موجودًا أيضًا داخلها. ^{[ 21 ]}

نادرًا ما تسمح الدوال بدخول متعدد. ويقتصر هذا غالبًا على إعادة الدخول إلى روتين فرعي (أو مولد /روتين فرعي شبه)، حيث تُسلّم الدالة التحكم (وربما قيمة)، ولكن يمكن استئنافها من حيث توقفت. لهذا النوع من البرمجة استخدامات شائعة عديدة، لا سيما في تدفقات البيانات (خاصةً المدخلات/المخرجات)، وآلات الحالة، والتزامن. من منظور تنفيذ التعليمات البرمجية، يُعدّ التنازل عن التحكم من روتين فرعي أقرب إلى البرمجة المهيكلة من العودة من دالة، لأن الدالة لم تنتهِ فعليًا، وستستمر عند استدعائها مرة أخرى - فهو ليس خروجًا مبكرًا. مع ذلك، تعني الروتينات الفرعية أن دوالًا متعددة لها حالة تنفيذ - بدلًا من مكدس استدعاء واحد للدوال - مما يُدخل شكلًا مختلفًا من التعقيد.

من النادر أن تسمح الدوال بالدخول إلى موضع عشوائي في الدالة، لأنه في هذه الحالة تكون حالة البرنامج (مثل قيم المتغيرات) غير مهيأة أو غامضة، وهذا يشبه أمر goto.

تتضمن بعض البرامج، ولا سيما برامج التحليل اللغوي وبروتوكولات الاتصال ، عددًا من الحالات المتتابعة بطريقة يصعب اختزالها إلى البنى الأساسية، ولذا يقوم بعض المبرمجين بتنفيذ تغييرات الحالة بالقفز إلى الحالة الجديدة. يُستخدم هذا النوع من تبديل الحالة بكثرة في نواة لينكس. ^{[ 22 ]}

مع ذلك، من الممكن هيكلة هذه الأنظمة بجعل كل تغيير في الحالة دالة منفصلة واستخدام متغير للإشارة إلى الحالة النشطة (انظر الترامبولين ). بدلاً من ذلك، يمكن تنفيذ ذلك عبر الروتينات الفرعية، مما يُغني عن استخدام الترامبولين.