نصائح لكتابة كود PHP ناجح | تحديث PHP 8.1.11
إليك بعض النصائح التي يمكنني تقديمها لك لمساعدتك في أن تصبح
مبرمجًا أفضل وكتابة كود أكثر قوة. هل أنت مهتم بالعمل في مجال تطوير البرمجيات؟
يوصى بشدة أن تبدأ في تنفيذ هذه الاقتراحات على الفور.
حسنًا ، دعنا نصل إليهم مباشرة:
تجنب الأجزاء الكبيرة من التعليمات البرمجية
ينطبق مبدأ "الأقل هو الأفضل" على البرامج مهما كانت درجة تعقيدها.
ضع في اعتبارك أن الكود الذي لم تنشئه هو أفضل رمز. رمز أقل
يعني نقاط دخول محتملة أقل لمشكلة ما. يحد من عمق التفرع المحتمل لبرنامجك.
عندما يتم إصدار عبارة "if" ، قد يتم تنفيذ الكود بطريقتين مختلفتين.
يوجد الآن أربع نتائج محتملة بفضل إضافة "if" أخرى ، ثمان نتائج بفضل
وجود ثلاث جمل "if" (التعقيد السيكلومي = 8) ، وهكذا دواليك.
بشكل عام ، كلما كانت الشفرة أكثر تعقيدًا ، زاد احتمال وجود عيوب فيها.
يوصى باستخدام درجة تعقيد سيكلوماتية مستهدفة أقل من 20.
تطبيق تقنيات الكود النظيف
لا يوجد شيء أكثر إحباطًا من العودة إلى الكود حيث تعلم أن لديك مشكلة
ملحة يجب إصلاحها ولكن ليس لديك أي فكرة عن ماهية المشكلة.
قم بتدوين ملاحظات حول اختياراتك في الملاحظات. يجب أن يكون للمتغيرات
والطرق والفئات والثوابت وما إلى ذلك أسماء ذات معنى.
إنها تجعل من السهل رؤية ما يفعله جزء من التعليمات البرمجية في لمح البصر.
إن قضاء بضع دقائق في التفكير في اسم وصفي لمتغير قد ينتهي بك الأمر إلى
توفير الكثير من الوقت والإحباط في المستقبل.
اكتب متغيرات التلميح
استخدام كتل doc لتزويد IDE بدليل بخصوص نوع المتغير؟ في مثل هذه الحالة ،
أقترح أن تبدأ على الفور. نظرًا لأن PHP هي لغة مفسرة ،
فقد يتغير نوع المتغير أثناء تشغيل البرنامج.
على الرغم من أن خادم PHP قد يكون قادرًا على تشغيل الكود بدون مشكلة ،
فقد لا يتمكن محرر الكود الخاص بك من عرض محتويات المتغير بشكل صحيح.
هل هو شيء من فئة المستخدم؟ أيضًا ، قد تعمل "خطأ" أو "خالية".
إن معرفة ذلك سيسمح لـ IDE الخاص بك باكتشاف الأخطاء الشائعة التي يسهل تفويتها بشكل أفضل
ما الجديد في PHP 8.1.11 ؟
هناك عمل مستمر يتم إجراؤه على PHP ، ويحتوي أحدث إصدار ثانوي (8.0)
على العديد من إصلاحات الأخطاء الممتازة.
رفض الخدمة مع ملف
ينصب تركيزي على تعديل غلاف PHAR بشكل خاص. من أجل إنشاء تطبيقات ،
قد يستخدم مطورو PHP PHAR ، وهو برنامج يجمع ملفات PHP.
في حالات نادرة ، قد يتعطل غلاف PHP PHAR في حلقة لا نهاية لها.
كان هذا عيبًا فادحًا يجب معالجته لأنه أثر على جميع عمليات الملف ، بما في ذلك وجود الملف وغيرها.
يجب على المستخدم إرسال مستند إلى خادم PHP للاستفادة من الخلل.
الجانب المثير للاهتمام هو الهيكل المطلوب للملف.
أرشيف gzip ذاتي الاحتواء
ربما لم تكن قد أدركت ذلك ، ولكن يمكن تحويل أرشيفات gzip إلى أسطر.
لذلك ، قد يعمل ملف gzip كبرنامج مستقل بدلاً من مجرد حاوية للمعلومات المضغوطة.
قد تكون العمليات والمواد الأرشيفية من مستوى أعلى جزءًا منه.
كانت التطبيقات القائمة بذاتها شائعة في الديموسين قبل بضع سنوات.
في ذروة برمجة الكمبيوتر ، كانت هذه الوظيفة ضرورية لتحقيق أقصى
استفادة من كل بايت من البيانات. حتى الوصول إلى النقطة التي يكون فيها
256 بايت من البيانات هو كل ما هو مطلوب لمثل هذه المرئيات:
كيف يربط الـ PHP
بالتالي ، سيدخل مغلف PHAR في حلقة لا نهاية لها في محاولة
لإكمال معالجة المستند عندما يكون أرشيف gzip قائمًا بذاته بطريقة معينة.
لكن هذا لا يمكن أن يحدث لأن الوثيقة ستمنع بشكل فعال إكمالها.
بعبارة أخرى ، يمكن لمستخدم ضار إرسال ملف gzip باستخدام بروتوكول
PHAR وإغلاق النظام بشكل فعال. في آخر تحديث 8.1.11 ، يعد هذا أحد الإصلاحات الرائعة.
لأنه يوضح إلى أي مدى سيذهب المجتمع للكشف عن مشكلة وحلها ، حتى لو بدت ميؤوسًا منها في البداية.
إنه مكان ممتاز لبدء استكشاف quins ، وهو موضوع معقد ولكنه رائع لتطوير البرمجيات.
