أسلوبك في تسمية المتغيرات (Variables)

طريقتي في تسمية المتغيرات تتوقف على نوع البرمجية أو الإسكربت أو حتى محتوي المتغير

مثلا قمت ببرمجة تقويم عن طريق javascript وكان في نيتي جعل التقويم متاح للجميع اما عن طريق الربط المباشر مع موقعي أو تحميل التقويم وإدراجه في ضمن ملفات مواقعهم

فأنتبهت لانه قد يحدث تعارض بين المتغيرات الموجودة في التقويم وبين التي يقوم المبرمج بتسميتها في صفحاته لمهام أخري

مثلا لدي المتغير day وأيضا year وغيرها

قد يكون المبرمج الذي ضمن الكود الخاص بي لا يعلم محتواه وحين برمجة أشياء أخري في نفس الصفحة يسمي أحد متغيراته day أو year فيحدث تعارض

فقمت مراجعة لكل متغيرات سكريبت التقويم وضفت لها كلمة calendar

• المتغير day يصبح calendar_day

• المتغير yaer يصبح calendar_yaer

فاكون بذلك تجنبت تداخل التسميات

ملحوظة أخيرة

تسمية المتغيرات بأسماء مفهومة تسهل عليك التعديل وتتبع الأخطاء بعد مرور فترة من البرمجة لأن الإنسان طبيعته النسيان والإسم ذو المعنى يذكر بمهمة المتغير

بداية رحلتي البرمجية كانت في الجامعة. في أول ترم كنت أستخدم متغيرات من حرف واحد فقط بسبب سهولة البرامج و قلة عدد المتغيرات. و أيضا كنت أستخدم vim بشكل رئيسي.

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

بعد الجامعة، قررت تعلّم coldfusion. و من خلال الدروس، اعجبت بطريقة شخص. الطريقة بتحديد نوع المتغير في البداية (إذا رقم، المتغير يبدأ بـ i اختصار integer. إذا نص، يبدأ المتغير بـ s اختصار string). و بعدها اسم المتغير. مثلا calendarYear تصبح iCalendarYear بسبب ان السنة رقم. اتبعت الطريقة لفترة، حتى فمت باستخدامها في موقع واحد فقط صغير.

حاليا و بسبب استخدامي و تعلمي للغة Ruby On Rails، أغلب المتغيرات و الأوامر تبدأ بحرف صغير و يفصل بين كل كلمة و الثانية _ . فأسماء المتغيرات calendar_year .

شخصيا، أتوقع تسمية المتغيرات تتغير باتباع منهج الأغلبية في اللغة. لا أقوم بالاكتفاء برموز أو اختصار اسم المغيرات لأن محررات البرمجيات تظهر المتغيرات في برنامج في حالة كتابتك لمتغير بنفس البداية. و أيضأ اسماء المتغيرات لا تفرق في حجم البرنامج النهائي، بعد الـ compile.

بالنسبة لطرق غريبة، البعض يستعمل الكلمات المحجوزة في اللغة و يضيف متغيرات باسماء لإضافة حس فكاهي للكود. مثلا:

Exception up = new Exception("Something is really wrong.");
throw up;  //ha ha

معنى throw up = الاستفراغ ...

أحاول عادة الالتزام بقواعد التسمية ضمن Zend Framework Coding Standard

يختلف اسلوبي بحسب اللغة التى استخدمها ففي الجافا Myvariable

الدوت نت استخدم myvariable

روبي وبايثون استخدم my_variable

وفي كل لغة احاول بقدر الاستطاعة عمل بالNaming convention standard

حتى يسهل علي عمل ال code optimization

أميل الى أختصار اسماء المتحولات مع تضمينها بالأحرف الانكليزية الأولى للاسم الكامل

أحاول دائما الالتزام بقواعد التسمية للغة جافا فيكون الأمر كالاتي

Person person

Date personBirthDay

أتجنب كذلك ال "_" في التسمية

بالنسبة للثوابت :

"static final String TAG= "tag here

كل الحروف كبيرة

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

هناك بعض الأشخاص الذين قاموا بتقديم معايير و مقاييس لتسمية المتغيرات و الدوال Style Guide for Coding ، مثلا الاتفاق على تمسية المتغيرات Lower case و تبديل المسافات space بـ _، و تسمية الدوال و الكلاسات بدون _ و الحرف الأول من الكلمة الثانية Upper case، و يكون الحرف الأول من اسم البكييج دائما Upper case. هذه بعض النقاط التي تستخدم في الـ Java .

مثلا في الـ Python يوجد هدا المقال الذي يعتمد عليه معظم المبرمجي و المطوريين:

ستجد Style Guides كثيرة للغات أخرى كـ JavaScript, C++, Java... etc