أسلوب البرمجة
تحتاج هذه المقالة إلى مصادر إضافية للتحقق . ( يونيو 2016 ) |
يشير أسلوب البرمجة ، المعروف أيضًا باسم أسلوب الترميز ، إلى الاتفاقيات والأنماط المستخدمة في كتابة التعليمات البرمجية المصدرية ، مما يؤدي إلى قاعدة بيانات متسقة وقابلة للقراءة . غالبًا ما تشمل هذه الاتفاقيات جوانب مثل المسافة البادئة واتفاقيات التسمية والحروف الكبيرة والتعليقات . يُعتبر أسلوب البرمجة المتسق مفيدًا بشكل عام لقابلية قراءة التعليمات البرمجية وصيانتها ، خاصة في البيئات التعاونية.
إن الحفاظ على نمط متسق عبر قاعدة التعليمات البرمجية يمكن أن يحسن قابلية القراءة وسهولة صيانة البرامج. فهو يسمح للمطورين بفهم التعليمات البرمجية التي كتبها آخرون بسرعة ويقلل من احتمالية حدوث أخطاء أثناء التعديلات. إن الالتزام بإرشادات الترميز الموحدة يضمن اتباع الفرق لنهج موحد، مما يجعل قاعدة التعليمات البرمجية أسهل في الإدارة والتوسع. تتبنى العديد من المؤسسات والمشاريع مفتوحة المصدر معايير ترميز محددة لتسهيل التعاون وتقليل الحمل المعرفي.
يمكن صياغة إرشادات الأسلوب رسميًا في مستندات تُعرف باسم اتفاقيات الترميز ، والتي تملي قواعد تنسيق وتسمية محددة. قد يتم تحديد هذه الاتفاقيات من خلال معايير رسمية للغة برمجة أو تطويرها داخليًا داخل فريق أو مشروع. على سبيل المثال، يعد PEP 8 الخاص بـ Python دليل أسلوب معترف به على نطاق واسع يحدد أفضل الممارسات لكتابة كود Python. على النقيض من ذلك، قد تحتوي لغات مثل C أو Java على معايير صناعية موثقة رسميًا أو ملتزمة باتفاقية.
الأتمتة
يمكن فرض الالتزام بأسلوب الترميز من خلال أدوات آلية، والتي تقوم بتنسيق الكود وفقًا لإرشادات محددة مسبقًا. تعمل هذه الأدوات على تقليل الجهد اليدوي المطلوب للحفاظ على اتساق الأسلوب، مما يسمح للمبرمجين بالتركيز على المنطق والوظائف. على سبيل المثال، تقوم أدوات مثل BlackPython و clang-formatC++ بإعادة تنسيق الكود تلقائيًا للامتثال لمعايير الترميز المحددة.
إرشادات الأسلوب
تتضمن العناصر المشتركة لأسلوب الترميز ما يلي:
- استخدام المسافة البادئة والمسافة البيضاء – يضمن هياكل كتلة متسقة ويحسن قابلية القراءة.
- اتفاقيات التسمية - توحيد كيفية تسمية المتغيرات والوظائف والفئات، عادةً بالالتزام بـ camelCase أو Snake_case أو Pascal Case ، اعتمادًا على اللغة.
- استخدام الأحرف الكبيرة - يحدد ما إذا كانت الكلمات الرئيسية والمعرفات مكتوبة بأحرف كبيرة أو صغيرة، بما يتماشى مع قواعد اللغة.
- استخدام التعليقات – يوفر السياق والشروحات داخل الكود دون التأثير على تنفيذه.
المسافة البادئة
يمكن أن يساعد أسلوب المسافة البادئة القارئ بطرق مختلفة بما في ذلك: تحديد تدفق التحكم وكتل التعليمات البرمجية. في بعض لغات البرمجة، تُستخدم المسافة البادئة لتحديد كتل التعليمات البرمجية وبالتالي فهي ليست مسألة أسلوب. في اللغات التي تتجاهل المسافات الفارغة، يمكن أن تؤثر المسافة البادئة على قابلية القراءة.
على سبيل المثال، تم تنسيقه بالنمط المستخدم بشكل شائع:
إذا ( الساعات < 24 والدقائق < 60 والثواني < 60 ) { إرجاع صحيح ؛ } وإلا { إرجاع خطأ ؛ }
يمكن القول أن التنسيق سيئ:
إذا ( الساعات < 24 والدقائق < 60 والثواني < 60 ) { ارجع صحيح ؛ } وإلا { ارجع خطأ ؛ }
أنماط المسافة البادئة البارزة
موديليك
يقوم نمط المسافة البادئة ModuLiq Zero بالتجميع حسب الأسطر الفارغة بدلاً من المسافة البادئة.
مثال:
إذا ( الساعات < 24 والدقائق < 60 والثواني < 60 ) ارجع صحيحًا ؛
وإلا
العودة false ؛
لوا
لا تستخدم لغة البرمجة Lua الأقواس المتعرجة أو الأقواس التقليدية ؛ بدلاً من ذلك، يجب أن يتبع التعبير في العبارة الشرطية then، ويجب إغلاق الكتلة بـ end.
إذا كانت الساعات < 24 والدقائق < 60 والثواني < 60 ، فقم بإرجاع true وإلا قم بإرجاع false
يعد التباعد اختياريًا في لغة Lua. andو or، و notتعمل كمشغلات منطقية.
بايثون
تعتمد لغة بايثون على قاعدة التسلل ، باستخدام المسافة البادئة للإشارة إلى بنية التحكم وتنفيذها، وبالتالي القضاء على الحاجة إلى الأقواس (أي، {و }). ومع ذلك، فإن نسخ ولصق التعليمات البرمجية المسننة يمكن أن يسبب مشاكل، لأن مستوى المسافة البادئة للتعليمات البرمجية الملصقة قد لا يكون هو نفسه مستوى المسافة البادئة للسطر المستهدف. مثل هذه إعادة التنسيق يدويًا مملة وعرضة للأخطاء، ولكن بعض محرري النصوص وبيئات التطوير المتكاملة (IDEs) لديها ميزات للقيام بذلك تلقائيًا. هناك أيضًا مشاكل عندما يتم جعل التعليمات البرمجية المسننة غير قابلة للاستخدام عند نشرها على منتدى أو صفحة ويب تزيل المسافات الفارغة، على الرغم من أنه يمكن تجنب هذه المشكلة حيث يمكن وضع التعليمات البرمجية في علامات تحافظ على المسافات الفارغة مثل "<pre> ... </pre>" (لـ HTML )، "[code]" ... "[/code]" (لـ bbcode )، إلخ.
إذا كانت الساعات < 24 والدقائق < 60 والثواني < 60 : ارجع True وإلا : ارجع False
يبدأ Python كتلة بعلامة النقطتين ( :).
يميل مبرمجو Python إلى اتباع دليل أسلوب متفق عليه بشكل عام يُعرف باسم PEP8. [1] هناك أدوات مصممة لأتمتة الامتثال لـ PEP8.
هاسكل
Haskell ، مثل Python، لديها قاعدة off-side . ولديها بناء جملة ثنائي الأبعاد حيث يكون التباعد مفيدًا لتعريف الكتل (على الرغم من أن بناء الجملة البديل يستخدم الأقواس المتعرجة والفاصلة المنقوطة).
Haskell هي لغة إعلانية، وهناك عبارات، ولكن الإعلانات تكون داخل نص Haskell.
مثال:
دع c_1 = 1 c_2 = 2 في f x y = c_1 * x + c_2 * y
يمكن كتابتها في سطر واحد على النحو التالي:
دع { c_1 = 1 ؛ c_2 = 2 } في f x y = c_1 * x + c_2 * y
تشجع لغة Haskell استخدام البرمجة المتعلمة ، حيث يشرح النص الممتد أصل الكود. في نصوص Haskell المتعلمة (المسماة بالامتداد lhs)، كل شيء عبارة عن تعليق باستثناء الكتل التي تم وضع علامة عليها ككود. يمكن كتابة البرنامج بلغة LaTeX ، وفي هذه الحالة codeتحدد البيئة ما هو كود. أيضًا، يمكن وضع علامة على كل فقرة كود نشطة عن طريق وضعها قبلها وإنهائها بسطر فارغ، وبدء كل سطر من الكود بعلامة أكبر من ومسافة. فيما يلي مثال باستخدام ترميز LaTeX:
الدالة \ verb + isValidDate + اختبار ما إذا كان التاريخ صحيحًا \ begin { code } isValidDate :: Date -> Bool isValidDate date = hh >= 0 && mm > = 0 && ss >= 0 && hh < 24 && mm < 60 && ss < 60 حيث ( hh , mm , ss ) = fromDate date \ end { code } لاحظ أنه في هذه الحالة تكون الدالة المحملة هي \ verb + fromDate :: Date - > ( Int , Int , Int ) +.
ومثال باستخدام النص العادي:
وظيفة isValidDate اختبار ما إذا كان التاريخ صحيحًا
> isValidDate :: Date -> Bool > isValidDate date = hh >= 0 && mm >= 0 && ss >= 0 > && hh < 24 && mm < 60 && ss < 60 > حيث ( hh , mm , ss ) = fromDate date
لاحظ أنه في هذه الحالة تكون الدالة المحملة هي fromDate :: Date - > ( Int , Int , Int ) .
المحاذاة العمودية
يرى بعض المبرمجين أنه من المفيد محاذاة العناصر المتشابهة عموديًا (مثل الجدول، في الأعمدة)، مشيرين إلى أن ذلك قد يجعل الأخطاء الناتجة عن الأخطاء المطبعية أكثر وضوحًا.
على سبيل المثال، غير محاذي:
$search = array ( 'a' , 'b' , 'c' , 'd' , 'e' );
$replacement = array ( 'foo' , 'bar' , 'baz' , 'quux' );
القيمة = 0 ؛
القيمة الأخرى = 1 ؛
القيمة الأخرى = 2 ؛
محاذاة:
$search = array ( 'a' , 'b' , 'c' , 'd' , 'e' );
$replacement = array ( 'foo' , 'bar' , 'baz' , 'quux' );
القيمة = 0 ؛
القيمة الأخرى = 1 ؛
القيمة الأخرى = 2 ؛
على عكس الكود غير المحاذي، فإن الكود المحاذي يعني أن قيمتي البحث والاستبدال مرتبطتان حيث أنهما تحتويان على عناصر متطابقة. ونظرًا لوجود قيمة واحدة أكثر للبحث من قيمة الاستبدال، فإذا كان هذا خطأ، فمن المرجح اكتشافه من خلال الفحص البصري.
تشمل العيوب المذكورة للمحاذاة الرأسية ما يلي:
- التبعيات عبر الأسطر مما يؤدي إلى زيادة عبء الصيانة. على سبيل المثال، إذا تمت إضافة قيمة عمود طويل تتطلب عمودًا أوسع، فيجب تعديل جميع أسطر الجدول (للحفاظ على الشكل الجدولي)، وهو تغيير أكبر يؤدي إلى بذل المزيد من الجهد لمراجعة التغيير وفهمه في وقت لاحق
- الهشاشة: إذا لم يقم المبرمج بتنسيق الجدول بشكل صحيح عند إجراء تغيير، فإن النتيجة هي فوضى بصرية يصعب قراءتها مقارنة بالكود غير المنسق. يمكن لعمليات إعادة الهيكلة البسيطة، مثل إعادة التسمية، أن تكسر التنسيق.
- مزيد من الجهد للحفاظ على الأمر، وهو ما قد يثبط عزيمة المبرمج عن إجراء تغيير مفيد، مثل تحسين اسم المعرف، لأن القيام بذلك يتطلب جهدًا كبيرًا في التنسيق
- متطلب استخدام خطوط ذات عرض ثابت؛ خطوط غير متناسبة
يمكن التخفيف من مشكلة الحفاظ على المحاذاة باستخدام أداة توفر الدعم (على سبيل المثال، لعلامات التبويب المرنة )، على الرغم من أن ذلك يخلق اعتمادًا على مثل هذه الأدوات.
على سبيل المثال، تؤدي عمليات إعادة الهيكلة البسيطة لإعادة تسمية "$replacement" إلى "$r" و"$anothervalue" إلى "$a" إلى:
$search = array ( 'a' , 'b' , 'c' , 'd' , 'e' );
$r = array ( 'foo' , 'bar' , 'baz' , 'quux' );
القيمة = 0 ؛
أ = 1 ؛
والقيمة الأخرى = 2 ؛
مع التنسيق غير المحاذي، لا يكون لهذه التغييرات تأثير دراماتيكي أو غير متسق أو غير مرغوب فيه:
$search = array ( 'a' , 'b' , 'c' , 'd' , 'e' );
$r = array ( 'foo' , 'bar' , 'baz' , 'quux' );
القيمة = 0 ؛
أ = 1 ؛
والقيمة الأخرى = 2 ؛
مسافة بيضاء
تتجاهل لغة التنسيق الحر أحرف المسافات البيضاء : المسافات، وعلامات التبويب، والأسطر الجديدة، وبالتالي يكون المبرمج حرًا في تصميم الكود بطرق مختلفة دون التأثير على معنى الكود. بشكل عام، يستخدم المبرمج أسلوبًا يعتبر أنه يعزز قابلية القراءة .
إن مقتطفي التعليمات البرمجية أدناه متماثلان منطقيًا، ولكنهما يختلفان في المسافة البيضاء.
int i ؛ بالنسبة إلى ( i = 0 ؛ i < 10 ؛ ++ i ) { printf ( "%d" ، i * i + i )؛ }
عكس
int i ؛ بالنسبة إلى ( i = 0 ؛ i < 10 ؛ ++ i ) { printf ( "%d" ، i * i + i )؛ }
إن استخدام علامات التبويب للمسافات البيضاء أمر مثير للجدل. تنشأ مشكلات المحاذاة بسبب اختلاف علامات التبويب في بيئات مختلفة والاستخدام المختلط لعلامات التبويب والمسافات.
على سبيل المثال، يفضل أحد المبرمجين علامات التبويب الأربعة ويقوم بتكوين مجموعة أدواته بهذه الطريقة، ويستخدمها لتنسيق الكود الخاص به.
int ix ; // فهرس لمسح المصفوفة long sum ; // مُراكم للمجموع
يفضل مبرمج آخر استخدام علامات تبويب مكونة من ثمانية، وقد تم تكوين مجموعة أدواته بهذه الطريقة. عندما يفحص شخص آخر الكود الذي كتبه الشخص الأصلي، فقد يجد صعوبة في قراءته.
int ix ; // فهرس لمسح المصفوفة long sum ; // مُراكم للمجموع
قد يتضمن أحد الحلول الشائعة الاستخدام لهذه المشكلة حظر استخدام علامات التبويب للمحاذاة أو وضع قواعد حول كيفية تعيين علامات التبويب. لاحظ أن علامات التبويب تعمل بشكل جيد بشرط استخدامها بشكل متسق، وتقييدها بالمسافة البادئة المنطقية، وعدم استخدامها للمحاذاة:
الفئة MyClass { int foobar ( int qux ، // المعلمة الأولى int quux ); // المعلمة الثانية int foobar2 ( int qux ، // المعلمة الأولى int quux ، // المعلمة الثانية int quuux ); // المعلمة الثالثة };
انظر أيضا
- MISRA C – معيار تطوير البرمجيات للغة البرمجة C
- اتفاقية التسمية (البرمجة) - مجموعة من القواعد لتسمية الكيانات في الكود المصدري والوثائق
مراجع
- ^ "PEP 0008: دليل الأسلوب لكود Python". python.org.
روابط خارجية
- منسقو الكود المصدر في Curlie
