الكود الطويل مقابل الكود القصير: أيهما أفضل لحالة استخدامك البرمجية؟

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

1. قابلية القراءة (Readability): مفتاح التعاون والاستدامة

قال خبير تطوير البرمجيات، مارتن فاولر (Martin Fowler)، ذات مرة: “أي أحمق يمكنه كتابة كود يفهمه الكمبيوتر. المبرمجون الجيدون يكتبون كودًا يفهمه البشر”. عند كتابة الكود، يجب أن تضع في اعتبارك دائمًا الأشخاص الآخرين الذين قد يتعاملون معه. فمن ناحية، ستقوم الآلة بمعالجته، وهي لا تهتم بمدى طول الكود أو قصره. ولكن من ناحية أخرى، قد يتطور الكود المصدري الخاص بك على أيدي مبرمجين آخرين يحتاجون إلى فهم كيفية عمله وما هي التحسينات التي يجب إجراؤها. لذلك، غالبًا ما تكون قابلية قراءة الكود المصدري أكثر أهمية من عدد الأسطر البرمجية.

إليك مثال على كود جافاسكريبت (JavaScript) يستخدم صيغة المعامل الثلاثي (ternary operator) لجملة if..else statement:

 const firstNumb = 100 ;
 let secondNumb;
 const secondNumb = firstNumb > 50 ? "Number is greater than 50" : "Number is less than 50" ;

وهنا نفس الكود مكتوبًا بالصيغة التقليدية الأطول:

 const firstNumb = 100 ;
 let secondNumb;
 if (firstNumb > 50 ) {
  secondNumb = "Number is greater than 50" ;
 } else {
  secondNumb = "Number is less than 50" ;
 }

يتكون أسلوب البرمجة الثاني من أسطر برمجية أكثر بكثير من الأول. ولكن يمكن القول إنه أسهل في القراءة والتفسير، خاصة للمبرمجين المبتدئين. ومع ذلك، يمكن أن يكون الإصدار الأول الذي يستخدم صيغة المعامل الثلاثي موفرًا كبيرًا للوقت إذا كنت ترغب في كتابة جملة if..else statement في سطر واحد فقط.

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

2. قابلية الصيانة (Maintainability): تقليل الأخطاء وتكاليف التطوير

يمكن أن يكون الكود القصير والمربك صعب الصيانة. قد يؤدي إلى مشكلات مثل الأخطاء (bugs) وارتفاع التكاليف العامة أثناء صيانة الجودة. كما يمكن أن يسبب مشكلات تحفيزية وإرباكًا لك كمطور. ماذا لو كتبت جزءًا قصيرًا من الكود واكتشفت أنك غير قادر على تفسيره بعد ستة أشهر؟ قد يساعدك الكود الأطول والأكثر تفصيلاً على استعادة فهمك لما كتبته ولماذا كتبته بهذا الأسلوب الخاص.

مع الكود الأطول، يصبح تصحيح الأخطاء (debugging) في البرنامج أسهل بكثير، حيث سيكون لديك متغيرات غير مرتبطة لفحصها والمزيد من الأماكن لإدراج نقاط التوقف (breakpoints). على الجانب الآخر، يمكن للكود القصير وغير الواضح أن يهدر الوقت والمال بينما يقوم المطورون بإعادة هيكلة (refactor) أو إعادة كتابة الكود الحالي لتضمين ميزات جديدة يسهل صيانتها على المدى الطويل.

هذا الكود أقصر:

 let a, b, c = 50 ;

ومع ذلك، فإن الكود أدناه أسهل في الصيانة والفهم:

 let a;
 let b;
 let c = 50 ;

3. الكفاءة (Efficiency): تحقيق الأهداف بأقل جهد

يمكن القول إن استخدام أسطر كود أقصر أكثر كفاءة من توزيع الكود على عدة أسطر. فإذا كان لديك المزيد من أسطر الكود، فهناك المزيد من الأماكن التي يمكن أن تختبئ فيها الأخطاء (bugs)، وقد يكون العثور عليها أكثر صعوبة. يمكن لعدد أقل من أسطر الكود تحقيق نفس النتائج (وربما أفضل) من العديد من أسطر الكود. إذا قللت من كمية الكود في مهمة ما، فستخفض عدد الأخطاء، خاصة إذا كان الكود المصدري واضحًا وقابلاً للقراءة والصيانة.

بالإضافة إلى ذلك، قد تتطلب كتابة أسطر كود طويلة تضمين عدد كبير جدًا من المتغيرات المحلية (local variables)، حيث يتعين عليك صياغة أسماء لها. يمكن أن تؤدي كل هذه الأسماء المختلفة إلى الارتباك وبرامج غير فعالة. إذا كنت ترغب في بناء تطبيقات فعالة بأخطاء أقل تزعجك، فقد يكون استخدام عدد أقل من أسطر الكود هو الحل الأفضل لك.

4. عبء العمل المتوقع (Expected Workload): تسريع التطوير وتقليل التكاليف

تتيح لك البرمجة المختصرة (shorthand coding) إنجاز المزيد بجهد أقل، وبالتالي تقلل بشكل كبير من عدد الساعات التي تقضيها في تطوير تطبيقاتك. مع التدريب والخبرة الكافيين، يمكنك تعلم كيفية إنجاز المزيد بسرعة أكبر وبعدد أقل من أسطر الكود. كما تعلم على الأرجح، فإن أسطر الكود الطويلة تتطلب أحيانًا جهدًا كبيرًا في الكتابة ويمكن أن تجعلك تقضي ساعات طويلة في العمل.

مع الكود القصير، يمكنك تقليل كمية الكود المطلوبة للعبارات المتكررة ومعالجة السلاسل النصية (string manipulation). بهذه الطريقة، بدلاً من استخدام كود مطول (verbose code)، يمكنك دمج العديد من الخطوات في خطوات فردية بشكل ملائم، مما يقلل بشكل كبير من عبء عملك والتكاليف الأخرى المرتبطة به.

إليك بعض أكواد جافاسكريبت (JavaScript) المكتوبة باستخدام العديد من الأسطر:

 function myFunc ( foo ) {
  console .log( "Hello World" , foo);
 }
 setTimeout ( function ( ) {
  console .log( "Upload completed" );
 }, 3000 );
 mylist.forEach( function ( foo ) {
  console .log(foo);
 });

وهنا نفس الكود بصيغة أقصر مكتوبة باستخدام صيغة دالة السهم (arrow function syntax) في جافاسكريبت:

 myFunc = ( foo ) => console .log( "Hello World" , foo);
 setTimeout ( () => console .log( "Upload completed" ), 3000 );
 mylist.forEach( ( foo ) => console .log(foo));

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

الخلاصة: التوازن هو المفتاح

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

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

ويجب ألا يكون استخدامك لأسطر كود طويلة أو قصيرة هو دافعك الرئيسي. هدفك الحقيقي لكل حالة يجب أن يكون تحقيق معايير عالية من قابلية القراءة، قابلية الصيانة، الكفاءة، والفعالية من حيث التكلفة – عادةً بهذا الترتيب. ويجب ألا يكون لعدد أسطر الكود مكان في هذه القائمة.

الخلاصة التقنية

إن الجدل بين الكود الطويل و الكود القصير هو في جوهره نقاش حول الموازنة بين الوضوح والكفاءة. بينما يمكن للكود القصير والمكثف أن يوفر الوقت في الكتابة ويقلل من حجم الملفات، فإنه غالبًا ما يأتي على حساب قابلية القراءة والصيانة، خاصة في المشاريع الكبيرة أو الفرق المتعددة. على النقيض، الكود الأطول والأكثر تفصيلاً قد يستغرق وقتًا أطول في الكتابة، ولكنه يقلل بشكل كبير من منحنى التعلم للمطورين الجدد ويجعل عملية تصحيح الأخطاء والتوسع المستقبلي أكثر سلاسة. التوصية التقنية هي تبني نهج براغماتي؛ استخدم الكود القصير عندما يكون واضحًا بذاته ولا يضر بالصيانة، وارجع إلى الكود الأطول والأكثر تفصيلاً عندما تكون قابلية القراءة والتعاون على المدى الطويل أمرًا بالغ الأهمية. الهدف الأسمى هو الكود النظيف (Clean Code) الذي يخدم الغرض بكفاءة ويسهل على البشر فهمه وتعديله.