الاستخدام الخاطئ لنطاق المتغير يزيد ساعات عملك، ما هي الخطوات الوقائية للمحافظة على وقتك

قرارات صغيرة تضيع جل وقت المبرمج.

القرارات الصغيرة التي نتخذها كمبرمجين هي السبب الرئيس لقضاء وقت طويل في حل مشكلة صغيرة جداً.

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

هذا الحل البسيط هو ما أسميه بـ “العادة”.

عندما تواجه خطئاً بسيطاً وتحتاج لوقتٍ طويل لحله، ثم تجد أنك قد اتخذت قراراً بسيطاً كلّفك وقتاً طويلاً وأحياناً -بل غالباً- يكونُ الوقت ذو قيمةٍ يجب أن تخلق عادةً تجعلك تتجنّب هذا الخطأ تلقائياً مستقبلاً.

مثلاً في حال كان السبب نسيان أحد الأقواس فبإمكانك أن تجعل عادتك فتح وغلق القوس في نفس الوقت قبل كتابة أي قوس آخر … وعلى ذلك قس.

في هذه التدوينة نتحدث عن فعلٍ بسيط، يسبب أخطاءً منطقية غالباً، والعادة التي تستبعده لها آثارٌ إيجابية متعددة.

قبل أن تبدأ: فلتتعرّف على نطاق المتغيّر

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

نطاق المتغير هو المدى الذي تستطيع فيه استخدام المتغير بعد تعريفه.

في المثال بالأعلى إذا أردت أن تستخدم المتغير counter في شفرتك بين قوسي الحلقة التكرارية for فإنك ستستطيع ذلك بلا شك.

ولكن على النقيض سيصرخ المترجم مخبراً بأنك أخطأت في محاولة استخدام المتغير counter إذا حاولت استخدامه بعد قوس نهاية الحلقة التكرارية!

جميل؟

فلنرَ الآن ما هي المشكلة البسيطة التي قد تحدث في نطاق المتغير.

هل ترغب برؤية عواقب استخدام خاطئ لنطاق المتغيّر؟

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

أعتقد أن الأمر بديهي.. أليس كذلك؟

ولكن انظر إلى هذه الشفرة المصدرية (عشوائية تماماً) وتابع تواجد المتغيّر i ونطاقه والتداخلات بين النطاقات

public class BlogPostx006267 {
    static int i = 10;
    
    public static void main(String args[]){
        
        returnNumber(9);
        
    }
    
   protected static void returnNumber(int i){
       i = 50;
       for(i = 10; i < 50; i++){
           i += 2;
       }
       System.out.println("i = "+i);
   }
    
 
}

هل استطعت معرفة قيمة المتغير i عند الطباعة؟ حاول حسابه وجرّب الشفرة المصدرية وقارن النتيجة، هل صدَقت توقّعاتُك؟

إن لم تكن النتيجة صحيحة فلا تحزن. هذا لا يعني أنك مبرمج غير كُفئ إطلاقاً. بل على النقيض، هذه الشفرة البرمجية التي أمامك مُزرية إلى الحد البعيد في التعامل مع إدارة نطاق المتغيّر.

دعنا نحلل تواجد المتغيرات المسماة i في هذه الشفرة:

• يوجد متغير i نطاقُه على مستوى الفئة، على الرغم من ذلك فإنّه غير مستخدم إطلاقاً داخل الشفرة المصدرية.
• يوجد متغير i نطاقُه على مستوى الدالّة، هذا المتغير مستخدم في داخل الدالة.
• يتقاطع نطاقا المتغيرين i على مستوى الفئة و i على مستوى الدالّة في داخل الدالّة returnNmber ما يجعل إدارة الوصول إلى هذين المتغيرين:
  • أكثر تعقيداً.
  • أقل مقروئية.
  • أصعب صيانة.

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

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

في نهاية الأمر ستعود إلى عملية التصحيح ومراجعة الشفرة المصدرية حتى تجد الخطأ وتبدأ بمعالجته!

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

خطواتك الوقائية: كيف تُحسّن من استخدامك لنطاق المتغيّر

في حياتك كمبرمج، مثلما أن قرارات صغيرة تنتج عنها آثار كبيرة، فإن قراراتٍ صغيرة كذلك تحفظ لك أوقات ثمينة من المعالجة والتصحيح ومراجعة الشفرات المصدرية في ليالٍ مظلمة.

حتى تتفادى المشاكل المتعلقة بنطاق المتغير وعواقبه من تعقيد نطاق المتغير و صعوبة مقروئية شفرتك المصدرية وكذلك صعوبة صيانتك لبرنامج الذي كتبته بيديك بمساعدة جرعات قويّة من الكافيين غالباً اتّبع القاعدة الذهبيّة التالية

قلّل نطاق متغيراتك إلى أدنى قدر ممكن

قاعدة بسيطة وتستطيع أن تصنع منها عادات تُنفذها دون أي تفكير، حتى عندما تصل إلى تلك المرحلة من الإرهاق تجعل من التفكير في كتابة سطر واحد صحيح مهمة مرهقة تستطيع اتباع هذه العادات تلقائياً.

دعني أخبرك بعادات تستطيع استنباطها من هذه القاعدة:

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

هل لاحظت في الشفرة المصدرية السابقة أن حرف i غير مُعبّر عن مهمّته؟

اتّباعُك للقواعد الموصى بها في تسمية المتغيرات تعتبر أيضاً من العوامل التي تجعل صيانة برنامجك أسهل وترفع درجة مقروئيته.

الخلاصة

مما تعلّمته خلال سنوات الخبرات (أو الأخطاء) أنّه عندما تواجه خطئاً ما عليك فعل أمرين:

1. معالجة المشكلة الحاليّة: في حالتنا هنا يجب مراجعة وتصحيح البرنامج.
2. اتخذ من الاجراءات ما يمنع تكرار المشكلة مستقبلاً: في حالتنا هنا يجب أن تتبنّى العادات البرمجيّة التي تمنع وقوعك في نفسك الخطأ مرّة أخرى.

حتى تتجنّب مشاكل نطاق المتغيّر، اتّبع القاعدة الذهبية: قلل نطاق متغيّراتك إلى أدنى قدر ممكن.

مقالات مفيدة لك:

ما هو الخطأ “java.lang.nullpointerexception” و كيف يتم إصلاحه!!