مفاهيم عامة للغات البرمجة

|Parameter vs Argument

نظرة عامة

مرحباََ بكم مجدداََ في تدوينة جديدة من موقع أكوادي ، يوجد العديد من الأنواع للغات البرمجة ، وما سنتحدث عنه في هذه المقالة ينطبق علي أغلب لغات البرمجة ، في تدوينة سابقة تحدثتنا عن بعض المصطلحات المهمة لكل مبرمج .

 

الدوال Functions 

تمثل الدوال الجزء الأساسي في لغات البرمجة ، والإهتمام بها شىء ضروري ، وجرت العادة بين المطورين على إستخدام طرق مختلفة لتسميتها ، ولكن إشترك الأغلب في طريقتين وهما Camel Case و Pascal Case بإسثتناء المطورين الذين عملوا على لغة C  فقد جرت العادة لديهم على كتابة الدوال بطريقة Underscore Case وهذا الأمر مجرد تقليد متبع ، فقد تجد برامج بلغة C وبأساليب مختلفة .

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- إذا كانت البيئة التي تطور فيها لا تضع قاعدة معينة لتسمية الدوال أو لا يريد فريق العمل إستخدام الطريقة التي تفرضها بيئة العمل ، فالأفضل إستخدام أسلوب Camel Case

2- عندما تفرض بيئة العمل أو لغة البرمجة التي تعمل عليها Style معين ، فالأفضل السير عليه ، فمثلا تستخدم بيئة الدوت نت أسلوب Pascal Case لتسمية الدوال ، وحاول ان لا تستخدم طريقة أو أسلوب Underscore Case في التسمية مالم يكن هناك ما يدعوا لإستخدامها .

3- في حالة كتابة الدالة فأحياناََ يضع المطورون Prefix بإسم المكتبة البرمجية ولكن في حال كان Method أو دالة مكتبة بداخل كلاس فغالباََ ما يتم تجنب هذا التقليد

4- حاول أن لا تستخدم أسلوب كتابة للدوال يتشابه مع أسلوب الكتابة بالباراميترات .

 

الباراميترات Parameters 

من المعلوم أن الباراميترات هي عبارة عن متغيرات تخص دالة معينة، ومن خلالها تستطيع الدالة توسيع إمكانياتها من خلال قبول قيم متعددة أو حتي التصرف بطرق مختلفة ويجب التنبيه هنا إلى أن المطور قد يخلط بين كلمة Parameter و كلمة Argument ، حيث تمثل الأولي المتغير الذي تم تعريفه مع الدالة ، بينما تمثل الثانية ، القيمة التي وضعناها لذلك المتغير أثناء إستدعاء الدالة

Parameter vs Argument

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- تذكر أن الباراميتر هو مجرد متغير ويجري عليه غالباََ ما يجري علي المتغير العادي

2- في حال قمت بتسمية الباراميتر بأسلوب معين ، فحاول قدر الإمكان أن لا يتشابه ذلك الأسلوب مع الأسلوب الذي إستخدمته لتسميه الدالة حتي يصبح التمييز بينمها أدق وأفضل

3- حاول أن تضع طريقة أو قاعدة تساعدك على التمييز بين اسم الباراميتر والمتغيرات التي تم تعريفها بداخل الدالة أو Local Variables  مثل وضع حرف p  قبل اسم الباراميتر أو أي قاعدة تراها مناسبة

4- في حال كان عدد الباراميترات كبير بحيث لا يمكن رؤية رأس الدالة بالكامل ، فعندها حاول وضع الباراميترات تحت بعضها البعض بحيث يتم وضع كا باراميتر في سطر بمفرده والأفضل أن لا تكون تحت اسم الدالة في نفس المستوى بل أبعد قليلاََ على اليمين

 

المتغيرات Variables

تخزين البيانات والتلاعب بها من أهم الأمور التي تقوم عليها لغات البرمجة ، والمتغيرات تعتبر قلب لغة البرمجة ، ولذا فإن المطورين إبتكروا أساليبهم الخاصة فيها ، وأكثر طريقتين كتبت بها المتغيرات هما Underscore Case و طريقة أو أسلوب Camel Case ، وغالباََ ما يتم إستخدام طريقة Pascal Case لهذا الغرض لأنه لم تجري العادة على إستخدام هذا الأسلوب مع المتغيرات .

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- إذا كانت البيئة التي تطور فيها لا تضع قاعدة معينة لتسمية المتغيرات أو لا يريد فريق العمل إستخدام الطريقة التي تفرضها بيئة العمل، فالأفضل إستخدام أسلوب Underscore Case

2- يفضل التمييز بين أسماء المتغيرات بحرف أو طريقة معينة ، فمثلاََ الباراميترات هي متغيرات ولكن مكانها يختلف عن المتغيرات العامة Global ، بالإضافة إلي وجود متغيرات Local ، لذا فإن وضع علامة مثل الحرف الأول كـ g لـ Global و l لـ Local و p لـ Parameter ، سيجعل الكود البرمجة أكثر وضوحاََ عند قرائته .

3- في حالة كان المتغير موجود بداخل كلاس ، فجرت العادة عند بعض المطورين على إستخدام Underscore للدلالة بأن المتغير Private ، ونحن لا ننصح بإستخدام هذا الأسلوب إلا إذا كان هناك ما يبرره

4- لا تستخدم الحروف الكبيرة في تسمية المتغيرات

 

الثوابت Constants

تعتبر الثوابت من الأشياء التي لا يكاد يخلو منها برنامج ولها أهمية كبرى ، ولذا ابتكر المطورون لها أساليب مختلفة لكتابتها ، وقد اعتاد المطورون علي كتابتها بطريقة Screaming Caps أو بحروف كبيرة غير أن هذا الأمر لا يعتبر إلزامي وهو ما جرت العادة عليه ولكن هناك إعتبارات مختلفة يجب الإنتباه لها عند تسمية الثوابت .

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- إذا كانت البيئة التي تطور فيها لا تضع قاعدة معينة لتسمية الثوابت أو لا يريد فريق العمل استخدام الطريقة التي تفرضها بيئة العمل ، فأفضل الخيارات هو الحروف الكبيرة

2- عندما تفرض بيئة العمل أو لغة البرمجة التي تعمل عليها Style معين ، فالأفضل السير عليه ، فمثلاََ تستخدم بيئة الدوت نت أسلوب Pascal Case لتسمية الثوابت ، والقرار في النهاية لفريق العمل أو للمطور ، والسبب في عرض هذه النقطة هو لكي يبقي القانون الذي وضعه الفريق أو المطور متوافق مع القانون الذي تقره بيئة العمل

3- أكتب الثواب بطريقة التصنيف ، بحيث يدل علي الهدف منه ويتبع لأي تصنيف ، فمثلاََ DB_INFO_USERNAME يوضح أن DB يدل على أن الثابت يخص قاعدة البيانات و INFO يقصد بها تصنيف فرعي أي معلومات قاعدة البيانات و USERNAME أي معلومة اسم المستخدم من قاعدة البيانات أو بنفس الطريقة في حال Pascal Case  ليصبح الثابت     DbInfoUserName أو DBInfoUserName

 

المسافات White Spaces

من المعلوم أن السائد في لغات البرمجة هو عدم إهتمامها بالمسافات ولا تؤثر المسافات علي الشيفرة البرمجية في شيء باستثناء بعض اللغات مثل Python والتي يعتمد فيها الكود البرمجي علي المسافات ، ولكن هذا الأمر لا يعني أن تلك المسافات لا تؤتر على الشكل الخارجي للكود ، لذلك يجب علي المطور أن يستخدم تلك المسافات بطريقة منظمة ومرتبة أثناء عملية الكتابة أو التعديل

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- لا تبالغ في وضع المسافات بين الأسطر البرمجية بداعي التنظيم

2- حاول أن تنظم الأسطر من خلال وضع الأسطر التي لها علاقة ببعضها البعض بشكل متتالي يليها سطر واحد فارغ ومن ثم الأسطر الأخرى التي لها علاقة ببعضها البعض وهكذا

3- حاول أن تستخدم المسافة Space لوضع المسافات وأبتعد قدر الإمكان عن وضع المسافات من خلال Tab ، رغم أن البعض قد يقرر العكس ، ولكن قد تظهر مشكلة Tab عند نقل الملف من نظام تشغيل إلى آخر أو من محرر إلى آخر من خلال تغير المسافات في الملف مما يعطي شكل مختلف عن الملف الأصلي

4- من المعلوم أن بيئات التطوير والمحررات تحتوي على أدوات تساعدك على تنظيم الكود البرمجي ولكن تلك الأدوات لا تعطيك الشيء الذي تريده بالضبط ، لذلك حاول الإعتماد عليها في تنسيق الشيفرة بشكل عام ، ثم ضع لمسات خفيفة حتي لا تفقد كامل تنسيق الشيفر مرة أخرى بإستخدام تلك الأدوات

 

أسماء الملفات

يجب عليك وضع قاعدة معينة لتسمية الملفات في المشروع الخاص بك أو إستخدام قواعد وقوانين موجودة للتسمية ويجب التنبيه هنا إلى أن نوع التطبيق قد يؤثر في التسمية فمثلاََ إذا كان التطبيق للويب فإن أسماء الملفات قد يكتبها الزائر بشكل مباشرة عند زيارته لصفحة معينة وهذا يختلف عن كتابة أسماء الملفات لتطبيقات مثل تطبيقات سطح المكتب أو تطبيقات الموبايل

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- حاول أن تكون القاعدة المستخدمة سهلة لأن أسماء الملفات تمثل الشكل الخارجي للمشروع وتعطي الإنطباع الأول لكل مطور يريد التطوير.

2- لا تستخدم الحروف الكبيرة في تسمية الملفات لكون هذه الطريقة غير مألوفة وغير متعارف عليها في الأوساط البرمجية

3- غالباََ ما يستخدم المطورون Pascal Case أو Underscore Case لتسمية ملفات المشروع

4- لا تستخدم طرق تسمية مختلفة لنفس المشروع إلا في حال كانت مختلفة من باب التمييز ، مثل تسمية المكتبة البرمجية بطريقة وملفات الواجهات بطريقة

5- لا تستخدم طريقة Camel Case لكونها طريقة غير مألوفه لتسمية الملفات

 

التعليقات Comments

التعليقات من الأمور الضرورية عند كتابة الشيفرة البرمجية وتزيد أهميتها إذا كان المشروع يدار من قبل فريق عمل لأن الملف البرمجي الواحد قد يعمل عليه أكثر من مطور من حيث الإضافة والتعديل والحذف ، فيتطلب الأمر بعض التوضيحات من قبل أعضاء الفريق لبعضهم البعض ، لذا وجب إيجاد أسلوب واضح لكتابة التعليقات والإبتعاد قدر الإمكان عن العشوائية

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- ابتعد عن كتابة التعليقات علي الأمور الواضحة ، فمثلاََ لو كان لديك أحد الأسطر لجمع عددين ، فهذا السطر لا يحتاج لكتابة تعليق يوضح ان العملية هي عبارة عن جمع !

2- من المعلوم أن اللغات تحتوي على أكثر من طريقة لكتابة التعليقات لذلك يجب على الفريق أو المطور إيجاد طريقة ثابتة للتعليقات ، فلا يفضل كتابة تعليقات متعدد الأسطر لدالة معينة ثم استخدام الملاحظات التي تكون بسطر واحد Inline لدالة أخرى !

3- ليس كل سطر برمجي يحتاج إلى تعليق ، لذا وكما أن التعليقات مهمة ، إلا أن المبالغة فيها قد تؤدي إلي شفرة برمجية غير واضحة

4- يضع بعض المطورون علامات أوكلمات معينة ضمن نفس التعليقات مثل كلمة Note لتنبيه المطورين الآخرين علي شيء أو كلمة BUG يليها نقطتين ومن ثم وصف مشكلة معينة في الكود التالي ليتم إصلاحه من قبل أحد المطورين وهكذا ، أي بإمكانك الإستفادة من التعليقات بطرق مختلفة

 

الكلاسات Classes 

عندما نتحدث عن تنظيم الكود البرمجي فأول ما يتبادر إلى أذهان الكثير من المطورين موضوع برمجة الكائنات ، لذا فإن طريقة كتابة الكلاسات تعد من الأمور الهامة وأكثر الأساليب المستخدمة في تسمية الكلاسات هو أسلوب Pascal Case ونادرا ما تجد من يستخدم Camel Case أو Underscore Case لتسمية الكلاسات مع بقاء القرار في نهاية المطاف إلى فريق العمل أو المطور

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- إذا كانت البيئة التي تطور فيها لا تضع قاعدة معينة لتسمية الكلاسات أو لا يريد فريق العمل استخدام الطريقة التي تفرضها بيئة العمل ، فالأفضل إستخدام أسلوب Pascal Case 

2- يستخدم معظم المطورين Prefix معينة قبل اسم الكلاس ، فمثلاََ ستجد في مكتبة Swing الخاصة ببرمجة الواجهات في Java أن التقليد المتبع لديهم هو وضع حرف J  قبل اسم الكلاس ليصبح الكلاس الخاص بالأزرار JButton ، والأفضل إيجاد التقليد الحرف أو الكلمة التي تناسب المشروع وغالباََ ما تكون حروف لإختصار اسم المشروع أو كلمة أو كلمتين تمثل اسم المشروع نفسة وأحياناََ قد تكتفي بعض الفرق بإسم الكلاس دون وضع Prefix .

3- لا تستخدم الحروف الكبيرة في تسمية الكلاس وحاول قدر الإمكان عدم استخدام Underscore Case في تسمية الكلاسات

4- لا يفضل استخدام علامة Underscore في اسم الكلاس

 

المصفوفات Arrays

المصفوفة برمجياََ عبارة عن متغير له أكثر من قيمة وتكتب بأكثر من طريقة من لغة برمجة إلى إخرى وقد تختلف ايضاََ طرق كتابتها في نفس اللغة ، وتعتبر المصفوفة من العناصر المهمة في أي لغة برمجة ، لذلك قام المطورون بإبتكار العديد من الأساليب لكتابة المصفوفات مع التنبيه على أن المصفوفات قد تأتي بأنواع مختلفة مثل Indexed ، Associative وقد لا يتوفر النوع الثاني في بعض اللغات

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- من القواعد المشهورة التي وضعها المطورون Arrays: Always Plural ، ويقصد بها أن اسم المصفوفة الأفضل أن تكون بصيغة الجمع مثل Students  لكون المطورين قد يستخدمونها في جملة foreach لإستخراج البيانات منها على شكل عنصر عنصر ، وهذا بدوره سيساعد المطور علي استقبال العنصر في ( مفرد اسم المصفوفة ) وفي حالتنا سيكون Student  وهذا سيجعل الكود البرمجة أكثر وضوحاََ

2- يجب أن تتذكر أن المصفوفة ما هي الإ متغير بأكثر من قيمة ، لذلك فأن الكثير من القواعد التي تنطبق على المتغيرات قد تناسب المصفوفات أيضاََ

3- بدلاََ من المصفوفات متعددة الأبعاد Multi-Dimension Arrays  حاول أن تستخدم مصفوفة ذات بعد واحد وكل عنصر فيها عبارة عن كائن Object لكونها تعطي صورة أفضل للكود ويبقي النقاش هنا حول الأداء وهو ليس محور نقاشنا .

 

البلوكات Blocks

تختلف طريقة التعامل مع البلوكات من لغة برمجة لأخرى فهناك لغات تعتمد على الأقواس لتعريف البلوكات واخرى تعتمد على الكلمات كـ end  لإنهاء البلوك ، بالإضافة إلى أن اللغات التي تعتمد علي الأقواس قد تستخدم أقواس مختلفة ، غير أن الشائع من الأقواس هو { } ، وبغض النظر عن الأسلوب المستخدم فإن تنسيق تلك البلوكات يحسن من الشيفرة البرمجية ويجعلها أسهل للقراءة

 

كيف أقوم بوضع طريقتي الخاصة ؟

1- إذا كانت اللغة التي تعمل عليها تستخدم الأقواس للبوكات فالأفضل أن يعطي سطر كامل لكل قوس

2- مع تنسيق الشيفرة البرمجية ، يجب أن تظهر القوسين على عمود واحد أي فوق بعضها البعض مباشرة ، ولتوضيح ذلك ، لو كان البلوك البرمجي مكون من 7 أسطر بالإضافة إلى سطرين للأقواس فأن القوس في السطر الأول سيظهر في نفس المكان المتواجد فيه القوس الموجود في السطر التاسع

3- نفس الطريقة التي ذكرت في النقطة رقم 2 تنطبق علي اللغات التي تستخدم الكلمات لبدء وانهاء البلوكات

4- في حالة الأقواس ايضاََ يوجد أسلوب يتبعه المطورون ، وهو وضع قوس البدء الخاص بالبلوكات في نهاية السطر بدلاََ من تخصيص سطر خاص به ، والأفضل عد استخدام هذه الطريقة لكون قوس الفتح لا يكون نفس مستوي قوس الإغلاق ، والأمر يعود للفريق أو المطور

عن الكاتب

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

Scroll to Top