كانت دوالنا متاهة: كيف أنقذتنا ‘الشروط الحارسة’ (Guard Clauses) من جحيم الـ if/else المتداخلة؟

يا أهلاً وسهلاً فيكم، معكم أبو عمر.

بتذكر قبل كم سنة، كنا شغالين على نظام تجارة إلكترونية كبير. كان يوم جمعة، والمفروض الواحد يرتاح فيه، بس إحنا كنا في المكتب بنحاول نصلح “بَغ” (bug) غريب في دالة (function) مسؤولة عن معالجة طلبات الشراء. الدالة هاي كان اسمها processOrder، بس إحنا بينا وبين بعض كنا مسميينها “متاهة الخليل” من كثر ما هي معقدة ومليانة تفرعات.

كل ما نفتح الكود، نلاقي كتلة ضخمة من if و else متداخلة في بعضها، زي عروق الشجر اللي بتلف على حالها. شرط جوا شرط جوا شرط… عشان تتأكد من المستخدم، وبعدها تتأكد من المنتجات في السلة، وبعدها تتأكد من رصيده، وبعدها تتأكد من عنوان الشحن… وهلم جرا. كل تعديل بسيط كان ياخد ساعات، وكل إصلاح لعلة كان يخلّف وراه علتين جداد. وقتها، واحد من الشباب صاح فينا وقال: “يا جماعة الخير، إحنا ضايعين في الكود هاد! لازم نلاقي حل!”. كان يومها يوم طويل، بس كان كمان اليوم اللي تعلمنا فيه درس من أهم الدروس في كتابة الكود النظيف.

ما هي مشكلة الـ if/else المتداخلة (Pyramid of Doom)؟

المشكلة اللي كنا بنواجهها الها اسم مشهور في عالم البرمجة: “هرم الهلاك” أو “هرم الموت” (Pyramid of Doom). وهو ببساطة وصف لشكل الكود اللي بصير لما تكثر فيه الشروط المتداخلة. بصير الكود يشبه هرم مقلوب، وكل ما نزلت لتحت، بزيد التعقيد وبتقل سهولة القراءة.

خلينا نشوف مثال بسيط لدالة بتعاني من هاي المشكلة. لنفترض عنا دالة لمعالجة تعليق من مستخدم:

function processComment(user, commentText) {
    if (user) { // هل المستخدم موجود؟
        if (user.isVerified) { // هل حسابه موثق؟
            if (commentText && commentText.length > 0) { // هل التعليق ليس فارغاً؟
                if (!commentText.includes("spam")) { // هل التعليق لا يحتوي على كلمات محظورة؟
                    
                    // --- هنا يقع المنطق الأساسي للدالة! ---
                    console.log("معالجة وحفظ التعليق...");
                    // ...
                    // ... عشرات الأسطر من الكود المهم
                    // ...
                    return { success: true, message: "تم نشر التعليق بنجاح" };

                } else {
                    return { success: false, message: "التعليق يحتوي على كلمات محظورة" };
                }
            } else {
                return { success: false, message: "التعليق لا يمكن أن يكون فارغاً" };
            }
        } else {
            return { success: false, message: "يجب توثيق الحساب لنشر تعليق" };
        }
    } else {
        return { success: false, message: "يجب تسجيل الدخول أولاً" };
    }
}

شايفين كيف؟ المنطق الأساسي للدالة، اللي هو أهم جزء فيها (الـ Happy Path أو “المسار السعيد”)، مدفون جوا أربع طبقات من الشروط. هذا الكود كارثي لعدة أسباب:

• صعب القراءة: عينك ودماغك لازم يظلوا يتتبعوا مسار الشروط عشان تعرف وين المنطق الأساسي.
• صعب الصيانة: تخيل لو بدك تضيف شرط خامس؟ بدك تضيف طبقة جديدة من التعقيد.
• صعب الاختبار: عشان تختبر كل حالة، بدك تبني سيناريو معقد جداً.

الحل السحري: الشروط الحارسة (Guard Clauses)

الحل بسيط وأنيق بشكل لا يصدق: “الشروط الحارسة” أو “الحراس”. الفكرة بكل بساطة هي: بدل ما تبني أسوار حول الكود المهم، ضع حراس على مدخل الدالة يطردوا الحالات غير المرغوب فيها من البداية.

المبدأ هو “اخرج مبكراً” (Return Early). بدل ما تسأل “هل كل شيء تمام؟ إذاً افعل كذا”، اسأل العكس: “هل هناك مشكلة؟ إذاً اخرج فوراً”.

إعادة كتابة المثال باستخدام الحراس

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

function processCommentWithGuards(user, commentText) {
    // حارس 1: هل المستخدم موجود؟
    if (!user) {
        return { success: false, message: "يجب تسجيل الدخول أولاً" };
    }

    // حارس 2: هل الحساب موثق؟
    if (!user.isVerified) {
        return { success: false, message: "يجب توثيق الحساب لنشر تعليق" };
    }

    // حارس 3: هل التعليق فارغ؟
    if (!commentText || commentText.length === 0) {
        return { success: false, message: "التعليق لا يمكن أن يكون فارغاً" };
    }

    // حارس 4: هل يحتوي على كلمات محظورة؟
    if (commentText.includes("spam")) {
        return { success: false, message: "التعليق يحتوي على كلمات محظورة" };
    }

    // --- المسار السعيد (Happy Path) ---
    // إذا وصل الكود إلى هنا، فكل الشروط سليمة 100%
    console.log("معالجة وحفظ التعليق...");
    // ...
    // ... عشرات الأسطر من الكود المهم
    // ...
    return { success: true, message: "تم نشر التعليق بنجاح" };
}

شفتوا الفرق؟ يا سلام على الترتيب! شغل نظيف ومرتب. الكود صار مسطح (flat) وواضح. أي مبرمج، حتى لو كان جديداً على المشروع، بيقدر يقرأه ويفهمه بسهولة:

1. الدالة بتعمل مجموعة من التحققات في البداية.
2. إذا فشل أي تحقق، الدالة بتخرج فوراً.
3. إذا نجحت كل التحققات، الدالة بتنفذ المنطق الأساسي في النهاية.

نصيحة من أبو عمر: فكّر في دالتك على أنها نادي خاص. الشروط الحارسة هي الحراس على الباب. مهمتهم يتأكدوا من كل الشروط (بطاقة العضوية، العمر، اللباس المناسب) قبل السماح لأي شخص بالدخول. فقط المؤهلون يصلون إلى “حلبة الرقص” (المنطق الأساسي للدالة).

متى وكيف تستخدم الشروط الحارسة؟

استخدامها بسيط ومباشر، وهي مفيدة جداً في الحالات التالية:

1. التحقق من مُدخلات الدالة (Argument Validation)

أول شيء يجب أن تفعله في أي دالة هو التحقق من أن المدخلات التي وصلتها صالحة. هل هي null؟ هل هي من النوع الصحيح؟

function calculateDiscount(price, user) {
    if (price <= 0) {
        return 0; // لا يوجد خصم على سعر صفري أو سالب
    }
    if (!user || !user.isPremium) {
        return 0; // لا يوجد خصم للمستخدم العادي أو غير المسجل
    }

    // المنطق الأساسي لحساب الخصم للمستخدم المميز
    return price * 0.15;
}

2. التعامل مع الحالات الاستثنائية (Edge Cases)

كل دالة فيها حالات طبيعية وحالات استثنائية. تخلص من الحالات الاستثنائية أولاً بأول.

function getFirstElement(arr) {
    // حالة استثنائية: المصفوفة فارغة أو غير موجودة
    if (!arr || arr.length === 0) {
        return null;
    }

    // الحالة الطبيعية
    return arr[0];
}

3. تبسيط الشروط المعقدة

بدلاً من كتابة if (A && B && C) { ... }، يمكنك عكس الشروط وفصلها:

// بدلاً من هذا...
if (user.isLoggedIn && user.hasSubscription && !user.isBlocked) {
    // show premium content
}

// ...جرّب هذا
if (!user.isLoggedIn) return;
if (!user.hasSubscription) return;
if (user.isBlocked) return;

// show premium content

الكود الثاني أسهل للقراءة والdebug. لو صار في مشكلة، بتعرف بالضبط أي شرط هو الذي فشل.

الخلاصة والزبدة 💡

في قصتنا، لما رجعنا لدالة “متاهة الخليل” processOrder وبدأنا نطبق عليها مبدأ الشروط الحارسة، الموضوع أخذ منا كم ساعة من إعادة الهيكلة (Refactoring). لكن النتيجة كانت مذهلة. تحولت الدالة من كابوس معقد إلى مجموعة خطوات واضحة ومنطقية. صيانة الكود أصبحت أسهل، وثقتنا في النظام زادت.

تذكر دائماً يا خال:

• اخرج مبكراً (Return Early): تخلص من الحالات غير الصالحة في بداية الدالة.
• اعكس شروطك: بدل ما تبحث عن “المسار السعيد”، ابحث عن أسباب الفشل واخرج عند أول سبب.
• اجعل منطقك الأساسي واضحاً: “المسار السعيد” يجب أن يكون آخر شيء في الدالة، بدون أي تداخلات أو مسافات بادئة (indentation) غير ضرورية.

في المرة القادمة التي تكتب فيها دالة أو ترى فيها كتلة if/else متداخلة، توقف للحظة واسأل نفسك: “هل يمكن لحارس أن ينقذ الموقف؟”. في أغلب الأحيان، الجواب سيكون نعم. 👍