خوب
قسمت اول مربوط به استاندارد PSR-1 هست
1- قوانین کلی
- تنها تگ های <?php , <?= در php مجاز هستند
- فایل های php می بایست با UTF-8 بدون کاراکتر BOM ذخیره شوند
- بهتره فایل یا حاوی عناصر (کلاس، تابع، ثابت و ...) و یا حاوی عبارت های دارای اثرات جانبی (چاپ خروجی، تغییر تنظیمات pnp.ini و ...) باشند و نه هر دو!
- فضای نام ها و کلاس ها باید از قوانین تعریف شده برای autoloading تبعیت کنند (از قوانین PSR-0 و PSR-4)
- نام کلاس ها باید به صورت StudlyCaps تعریف بشه
- ثابت های درون کلاس باید تماما با حروف بزرگ با جداکننده "_" (underscore) تعریف بشند
- نام متدها باید به صورت camelCase تعریف بشه
2- فایل های PHP
- تگهای Php
در کدهای php فقط باید از تگ بلند (
<?php ?>) و تگ کوتاه چاپ (
<?= ?>) استفاده بشه و استفاده از سایر تگ ها ممنوعه!
- انکودینگ
فایل های php می بایست با UTF-8 بدون کاراکتر BOM ذخیره شوند، این BOM یک کاراکتر هست که در برخی نمونه های UTF-8 ابتدای فایل ذخیره میشه و این همون کاراکتر معروف هست که وقتی فایل رو با dreamviewer ذخیره می کردیم، گاهی اوقات برای اجرا با خطا مواجه میشد.
- اثرات جانبی
یک فایل php یا باید محل تعریف توابع و کلاس و ... باشه و هیچگونه اثر جانبی مثل تولید خروجی و دستکاری تنظیمات php.ini و کانفیگ و ...نداشته باشه و یا باید فقط حاوی کارهای دارای اثرات جانبی باشه و نه هر دو!
عبارت "اثرات جانبی" شامل تولید خروجی، استفاده صریح از include و require، اتصال به سرویس های خارجی، تغییر در php.ini، مدیریت خطاها و استثناها، تغییر متغیر و ثابت های سراسری، خواندن و نوشتن فایل و موارد مشابه هست.
مثال زیر یک نمونه از تعریف عناصر همراه با اثرات جانبی هست، چیزی که شما باید ازش اجتناب کنید!
// 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
}
و مثال زیر یک نمونه از تعریف عناصر بدون اثر جانبی هست، چیزی که باید بهش مقید باشید
<?php
// declaration
function foo()
{
// function body
}
// conditional declaration is *not* a side effect
if (! function_exists('bar')) {
function bar()
{
// function body
}
}
3- نامگذاری فضای نام و کلاس
فضای نام ها و کلاس ها باید از قوانین تعریف شده برای autoloading تبعیت کنند (از قوانین PSR-0 و PSR-4)، بدین معنی که هر کلاس باید به تنهای در یک فایل تعریف بشه و شامل فضای نام با دستکم یک سطح باشه. همچنین فضای نام ریشه همون نام vendor هست.
نام کلاس ها باید از StudlyCaps تبعیت کنه.
کدهای نوشته شده با php نسخه 5.3 و بالاتر باید از فضای نام رسمی استفاده کنند، مثل کد زیر:
<?php
// PHP 5.3 and later:
namespace VendorModel;
class Foo
{
}
و کلاس های نوشته شده در نسخه های 5.2 و پایین تر بهتره از روش pseudo-namespacing با پیشوند
vendor_ در نام کلاس استفاده کنند، مثل:
<?php
// PHP 5.2.x and earlier:
class Vendor_Model_Foo
{
}
4- متدها، مشخصه ها و ثابت های کلاس
این قوانین مربوط به همه کلاس ها، اینترفیس ها و تریت ها میشه
- ثابت ها
ثابت های درون کلاس باید تماما با حروف بزرگ با جداکننده "_" (underscore) تعریف بشند، مانند:
<?php
namespace VendorModel;
class Foo
{
const VERSION = '1.0';
const DATE_APPROVED = '2012-06-01';
}
- مشخصه ها (properties)
در این سند، به جد از هرگونه پیشنهاد برای روش نامگذاری مشخصه ها مثل
$StudlyCaps یا
$camelCaps و یا
$under_score اجتناب شده، هرچند پیشنهاد میشه از یک روش در محدوده مشخص استفاده بشه. منظور از محدوده مشخص، محدوده vendor، پکیج، کلاس یا متد هست.
- متدها
نام متدها باید به صورت camelCase تعریف بشه
پ ن:
- قوانین PSR-0 و PSR-4 مربوط به نوشتن autoloading هستند که بعدا توضیح داده میشند.
- StudlyCaps یک روش برای نامگذاری شناسه ها هست، که اصل اساسیش بزرگ بودن کاراکتر اول همه کلمات هست، مثل MyClass.
- vendor اصطلاحا نام مخزن Git یک پروژه هست، مثل github.com/facebook/react که در اینجا facebook نام vendor و react نام پکیج هست.
- camelCase هم روش دیگه نام گذاری شناسه ها هست با این اصل که کاراکتر اول کلمات دوم به بعد بزرگ نوشته میشه و بقیه کوچک، مثل myMethod.
![[عکس: packages.gif]](http://forum.ncis.ir/images/ads/packages.gif)
