بعد قراءة PSR-1 ، ظهرت بعض الأفكار التي أود مشاركتها مع مجتمع البرمجة للحصول على قصص حول تجربتك.
PSR-1: معيار الترميز الأساسي - معيار يوصي بقواعد التنسيق والتشفير. التصميم هو كيفية كتابة الكود ، والكتابة هي ما تكتبه.
ينص النص الفرعي PSR-1 على أنه لا يجب استخدام خلط الكود والاستنتاجات المنطقية للكود. أضعها قليلاً غير واضح ، ولكن بعد ذلك ستفهم أن PSR-1 لا ينصح بكتابة فصل دراسي وعرضه على الشاشة وتهيئة الخصائص في ملف واحد.
يجب أن تستخدم جميع ملفات PHP إما <?php
أو <?=
. كل شيء واضح ومفهوم هنا ، العلامة الأولى تقول عن إعلان قسم كود php ، والثاني هو تسجيل قصير <?php echo
، أي الإخراج.
يجب أن تكون الملفات أيضًا بترميز UTF-8 بدون BOM ، وهذا أمر منطقي. كانت هناك حالات في أحد المشاريع حيث كان هناك العديد من المبرمجين. لذلك ، تمكن أحدهم بطريقة ما من إدراج رمز قائمة مكونات الصنف وبسبب هذا ، تعطل تحليل الملفات.
كما ينص على أنه لا ينصح باستخدام آثار جانبية متعددة. مع الترجمة ، لست بخير دائمًا ... أي أننا لا نستطيع أن نأخذ ونكتب في الملف:
<?php
// side effect: change ini settings
ini_set('error_reporting', E_ALL);
// side effect: loads a file
include "file.php";
// side effect: generates output
echo "<html>\n";
// declaration
function foo()
{
// function body
}
حسنًا ، هذه اللحظة مثيرة للجدل للغاية. على الرغم من أن المعيار يوصي باستخدام أداة التحميل التلقائي وفقًا لمعايير PSR-0 و PSR-4. من ناحية ، نعم ، ولكن يمكن أن يكون هناك تهيئة للتطبيق عند نقطة دخول واحدة. باختصار ، هذه اللحظة مشكوك فيها. نفس Yii2 لا يتبع هذا النهج ... لن أنتبه لهذه التوصية بالذات.
(namespace). , , . StudlyCaps
. PHP < 7.0, , .
, DATE_APPROVED
. , – . .
. PSR-1 : $StudlyCaps
, $camelCase
, $under_score
. . , , , , $camelCase
. , , ... , . camelCase
.
مع تسمية الطرق في الشكل camelCase()
أوافق تمامًا وأحتفظ بها. من المنطقي أن نسمي الفئات بحرف كبير ، والثوابت بحرف صغير ، والطرق ذات الحرف الصغير. ومن حيث المبدأ ، يمكنك تمييز أحدهما عن الآخر بمجرد الكتابة.
شكرا لاهتمامكم ، وآمل أن تكون المادة مفيدة ، على الرغم من أنها عبارة عن بيان للأفكار حول قراءة PSR-1.