معايير ترميز دلفي - قواعد تنسيق كود المصدر العامة

توفر معايير الترميز بشكل أساسي لفريق التطوير إرشادات برمجة بحيث يكون لدى مطوري المشروع تنسيق ثابت يجب اتباعه عند البرمجة. بهذه الطريقة، يمكن للآخرين فهم الكود الذي كتبه كل مبرمج في فريق التطوير، وبالتالي تحسين قابلية صيانة الكود، وجعل مجموعة من البرامج مكتوبة من قبل عدة أشخاص كما لو أنها كتبها شخص واحد، مما يجعل الكود أسهل لفهم. وهذا يتطلب من الجميع استخدام أسلوب ترميز ثابت. حسنًا، السبب وراء كون تقديم هذه المعايير أمرًا مبتذلاً هو أنه عندما ينضم مطورون جدد إلى فريق تطوير المشروع، قد لا يكون البعض على دراية بمعايير ترميز دلفي. سيتم تقديم هذه المعايير هنا في الفئات التالية: 1. قواعد تنسيق التعليمات البرمجية المصدر العامة 2. الإجراءات والوظائف 3. تسمية وحدة الملفات والنماذج والبيانات 4. تسمية الحزمة والمكونات القواعد العامة لتنسيق التعليمات البرمجية المصدر المسافة البادئة هي كل مستوى هناك مستويان الفراغات بينهما. لا تضع أحرف علامة التبويب في التعليمات البرمجية المصدر. وذلك لأن عرض حرف علامة التبويب يختلف باختلاف الإعدادات والأدوات المساعدة لإدارة التعليمات البرمجية (الطباعة، والتوثيق، والتحكم في الإصدار، وما إلى ذلك). الهوامش يتم تعيين الهوامش على 80 حرفًا. بشكل عام، كود المصدر لا يتجاوز الهامش بكتابة كلمة واحدة، لكن هذه القاعدة أكثر مرونة. كلما أمكن، يجب تغليف البيانات الأطول من سطر واحد بفواصل أو عوامل تشغيل. بعد فاصل الأسطر، يجب أن يكون هناك مسافة بادئة بواسطة حرفين. لا تحتوي الأقواس على مسافة بين قوس الفتح والحرف التالي. وبالمثل، لا توجد مسافة بين قوس الإغلاق والحرف السابق. يوضح المثال التالي المسافة البيضاء الصحيحة وغير الصحيحة. CallPRocedure(Parameters); // خطأ! CallProcedure (Parameters); // صحيح! الكلمات والكلمات الأساسية المحجوزة هي دائمًا أحرف صغيرة تمامًا. يجب أن تكون عبارة begin...endbegin في السطر الخاص بها. على سبيل المثال، السطر الأول أدناه خاطئ، ولكن السطر الثاني صحيح: for i:=0 to 10 do beginStatement end// خطأ، البداية على نفس السطر بالنسبة لـ i:=0 to 10 do // صحيح start in حالة خاصة لهذه القاعدة في beginStatementend على سطر آخر هي عندما تكون begin جزءًا من عبارة else. على سبيل المثال: إذا كانت الحالة ثمbeginStatement endelse beginStatement؛ فإن عبارة النهاية تكون دائمًا في سطر منفصل. عندما لا تكون begin جزءًا من عبارة else، يتم وضع مسافة بادئة لعبارة النهاية المقابلة بنفس المقدار الموجود في عبارة begin. العبارة (1) يجب وضع الموقف الأكثر احتمالاً لعبارة if_then_else في جملةthen، ويجب وضع الموقف غير المحتمل في جملة else. لتجنب العديد من عبارات if، استخدم عبارات الحالة بدلاً من ذلك. إذا كان هناك أكثر من 5 مستويات، فلا تستخدم عبارات if. الرجاء استخدام طريقة أكثر وضوحًا بدلاً من ذلك. لا تستخدم أقواسًا إضافية في عبارات if. في الكود المصدري، يتم استخدام الأقواس فقط عند الحاجة إليها حقًا. على سبيل المثال: إذا (I=42) إذن // خطأ، الأقواس زائدة عن الحاجة إذا (I=42) أو (J=42) ثم // صحيح، يجب استخدام الأقواس إذا كانت هناك شروط متعددة للاختبار في عبارة if، يجب عليك الترتيب من اليمين إلى اليسار حسب التعقيد الحسابي. يتيح ذلك للكود الاستفادة الكاملة من منطق تقدير الدائرة القصيرة للمترجم. إذا كان Condition1 أسرع من Condition2 وCondition2 أسرع من Condition3، فيجب إنشاء عبارة if على النحو التالي: if Condition1 وCondition2 وCondition3 ثم (2) عبارة case_else يجب ترتيب ثوابت كل حالة في بيان الحالة عدديًا أو أبجديًا طلب. يجب أن يكون بيان الإجراء لكل موقف قصيرًا ولا يزيد عادةً عن 4 إلى 5 أسطر من التعليمات البرمجية. إذا كان الإجراء معقدًا جدًا، فيجب وضع الكود في إجراء أو وظيفة منفصلة. يتم استخدام جملة else في بيان الحالة فقط للحالات الافتراضية أو اكتشاف الأخطاء. (3) توصي عبارة while بعدم استخدام عملية الخروج للخروج من حلقة while. إذا لزم الأمر، يجب استخدام شرط الحلقة للخروج من الحلقة. يجب أن تكون جميع التعليمات البرمجية التي تقوم بتهيئة الحلقة while موجودة قبل الإدخال while ولا يجب فصلها بعبارات غير ذات صلة. يجب تنفيذ أي عمل مساعد للشركة مباشرة بعد الدورة. (4) للبيان إذا تم تحديد عدد الحلقات، فيجب استخدام عبارة for بدلاً من عبارة while. (5) عبارة التكرار عبارة التكرار تشبه حلقة while وتتبع نفس القواعد. (6) مع العبارة يجب استخدام العبارة بحذر. تجنب الإفراط في استخدام عبارات with، خاصة عند استخدام كائنات أو سجلات متعددة ضمن عبارة with. على سبيل المثال: مع Record1، Record2، يمكن أن تؤدي هذه المواقف إلى إرباك المبرمجين بسهولة وتجعل تصحيح الأخطاء أمرًا صعبًا. معالجة الاستثناءات المنظمة تُستخدم معالجة الاستثناءات بشكل أساسي لتصحيح الأخطاء وحماية الموارد. وهذا يعني أنه أينما يتم تخصيص الموارد، حاول... وأخيرًا يجب استخدامها لضمان تحرير الموارد. ومع ذلك، يتم إجراء استثناءات إذا تم تخصيص/تحرير الموارد في الجزء الأولي/الأخير من الوحدة أو في منشئ/مدمر الكائن. (1) استخدام المحاولة...أخيرًا، كلما أمكن ذلك، يجب أن يتطابق كل تخصيص للموارد مع بنية المحاولة...أخيرًا. على سبيل المثال: // قد يتسبب الكود التالي في حدوث أخطاء SomeClass1: = TSomeClass.Create;SomeClass2: = TSomeClass.Create;try{do some code}finallySomeClass.Free;SomeClass.Free;end;// حل آمن للمورد أعلاه التخصيص هو: SomeClass1: = إنشاء TSomeClass؛trySomeClass2: = إنشاء TSomeClass؛حاول {القيام ببعض التعليمات البرمجية}finallySomeClass2.Free;end;finallySomeClass1.Free;end;(2) استخدام المحاولة...إلا إذا كنت تريد تنفيذ بعض المهام عند حدوث استثناء، فيمكنك استخدام المحاولة...إلا. عادةً، ليست هناك حاجة لاستخدام حاول... إلا لعرض رسالة خطأ ببساطة، لأن كائن التطبيق يمكنه القيام بذلك تلقائيًا بناءً على السياق. إذا كنت تريد تنشيط معالجة الاستثناء الافتراضي في الجملة، فيمكنك تشغيل الاستثناء مرة أخرى. (3) لا يُنصح باستخدام المحاولة...إلا...else من استخدام المحاولة...إلا مع عبارة else، لأن هذا سيمنع كافة الاستثناءات، بما في ذلك الاستثناءات التي لست مستعدًا للتعامل معها.