استانداردهای php در وردپرس


استانداردهای طراحی سایت با وردپرسوردپرس 

در استانداردهای php در وردپرس به موارد زیر خواهیم پرداخت:

بعضی از ساختار کدهای وردپرس برای نشانه گذاری PHP در سبک خود ناسازگار هستند. وردپرس توسط کمک کاربرانش به تدریج کار را بهبود می بخشد طوری که در یک نگاه کد تمیز و خوانا به نظر برسد.

نکاتی که مطرح می شود را هنگام نوشتن کد PHP برای وردپرس به خاطر داشته باشید، دستورالعمل ها در بسیاری از جهات مشابه استانداردهای گلابی می باشند، اما در برخی موارد کلیدی متفاوت می باشند.

همچنین مستندات استاندارد PHP را نیز ببینید.

#تک کوتیشن و جفت کوتیشن Single and Double Quotes

در زمان مناسب از تک کوتیشن و جفت کوتیشن استفاده کنید. اگر شما چیزی را در رشته ارزیابی نمی کنید، از تک کوتیشن استفاده کنید. شما تقریبا هرگز نباید مجبور به خروج از تک کوتیشن باشید، چرا که شما فقط قادر به استفاده سبک کوتیشن متناوب مانند زیر می باشید :

 

متنی که این ویژگی ها را دارد باید از طریق ()esc_attr اجرا شود، طوری که تک کوتیشن یا جفت کوتیشن، پایان کار مقدار ویژگی، HTML باطل می تواند باعث ایجاد مسئله امنیتی نشود. اعتبار سنجی داده ها را در Codex برای جزییات بیشتر ببینید.

#دندانه گذاری Indentation

دندانه گذاری شما همیشه باید ساختار شرطی را منعکس کند. استفاده از TAB های واقعی نه دکمه SPACES، به شما انعطاف پذیری بیشتر در سراسر کاربران را اجازه می دهد.

استثنا: اگر شما یک بلوک از کد داشته باشید که میخواهید همه چیز در تراز وسط قرار گرفته و قابلیت خوانایی بیشتر پیدا کند از space استفاده کنید:

برای آرایه های انجمنی، مقادیر باید با یک خط جدید شروع شوند. به کاما پس از آخرین مورد آرایه توجه داشته باشید:

زیرا آن را برای تغییر آرایه و Deffs های پاک برای افزودن موارد جدید توصیه می شود چون آن را برای کارایی آسان تر می کند.

حساب سرانگشتی: Tab ها باید در شروع خط برای دندانه گذاری استفاده شوند، در حالی که spaces می توانند مورد استفاده هم ترازی خط میانی شوند.

#براکت ها

براکت ها باید در حالتی که اینجا نشان داده شده باید استفاده شود:

علاوه بر این، اگر شما واقعا یک بلوک طولانی دارید، در نظر بگیرید که آن می تواند به دو یا چند بلوک یا تابع شکسته شود. اگر شما چنین بلوک طولانی اجتناب ناپذیری را در نظر بگیرید، لطفاً در پایان یک توضیحات کوتاه قرار دهید تا مردم  در یک نگاه بدانند که بلوک کجا خاتمه یافته است. معمولا این برای یک بلوک منطقی است (طولانی تر از 35 سطر)، اما برای هر کد که به طور مستقیم آشکار است نمی توان اظهار نظر کرد.

براکت ها همیشه باید مورد استفاده قرار بگیرند حتی زمانی که لازم نیستند:

توجه داشته باشید استفاده از براکت بدان معناست که ساختارهای کنترل خطی تک بیانیه ای ( single-statement inline control structures) ممنوع است. شما می توانید به صورت رایگان ازجایگزین برای ساختارهای کنترلی استفاده کنید. ( به عنوان مثال:  if/endifwhile/endwhile) به ویژه جایگذاری PHP در HTML در قالب های خودتان، برای مثال:

#استفاده از elseif، نه else if

else if با سینتکس دو نقطه برای بلوک های if|elseif سازگار نیست. به این دلیل از elseif برای شرط ها استفاده کنید.

#عبارات منظم Regular Expressions

عبارات منظم سازگار پرل باید در اولویت همتایان خود POSIX استفاده شوند. هرگز از سوئیچ e/ استفاده نکنید، از preg_replace_callback به جای آن استفاده کنید. آسان ترین روش برای عبارات منظم استفاده از رشته های تک کوتیشن می باشد، برخلاف رشته های جفت کوتیشن، آنها تنها دو توالی متا (metasequences) دارند: ‘\ و \\.

#باز و بسته کردن تگ های PHP

هنگامی که چند خط php را در بلوک html جایگذاری می کنیم، تگ های باز و بسته کردن php باید در خط خودشان باشند.

صحیح ( چند خطی )

صحیح ( تک خطی )

غلط

#تگ های PHP بدون استفاده از کوتاه نویسی No Shorthand PHP Tags

توجه: هرگز از کدهای کوتاه PHP در شروع استفاده نکنید. همیشه از تگ های کامل PHP استفاده کنید.

صحیح

غلط

#حذف فضاهای پشتی Remove Trailing Spaces

فضاهای سفید در پایان هر یک از خطوط کدها را حذف نمایید. اولویت با حذف پایان تگ php در انتهای کدها می باشد. اگر شما از این تگ استفاده می کنید، اطمینان یابید که فضاهای سفید عقبی را حذف کرده اید.

#طریقه استفاده از فضا Space Usage

همیشه بعد از کاماها، و در هر دو طرف منطق ها، مقایسه ها، رشته ها و عملگرهای انتساب فاصله بگذارید.

در هر دو طرف باز و بسته شدن پرانتزها با if, elseif, foreach, for و بلوک های switch فاصله بگذارید.

هنگام تعریف یک تابع، آن را مانند زیر انجام دهید:

هنگام فراخوانی تابع، آن را مانند زیر انجام دهید:

هنگام مقایسه های منطقی، آن را مانند زیر انجام دهید:

هنگام type casting, مانند زیر انجام دهید:

زمانی که اشاره به موارد آرایه دارد، اگر آن یک متغیر است تنها شامل یک فاصله اطراف شاخص می باشد، برای مثال:

در یک بلاک switch، قبل از کولون برای یک مورد نباید هیچ فضایی وجود داشته باشد.

#توضیحات قالب بندی SQL

هنگام قالب بندی SQL ممکن است شما آن را به چندین و خطوط و دندانه بشکنید اگر به اندازه کافی پیچدگی بر آن حاکم باشد. اکثر قالب بندی ها مانند  one line though به خوبی کار کند. همیشه حروف بزرگ در SQL بخشی از قالب ها شبیه UPDATE یا WHERE می باشد.

توابعی که بروزرسانی پایگاه داده را انجام می دهند باید منتظر پارامترهای فاقد SQL های بریده بریده در گذشته باشند. به عنوان سریع ترین زمان پرس و جو باید ممکن است عبور از چنین پارامترهایی انجام گیرد، ترجیحا با استفاده از: $wpdb->prepare() این یک متد handles escaping، کوتیشن و int-casting برای پرس و جوهای SQL است. آن به عنوان یک زیر مجموعه ()sprintf در قالب بندی حالات استفاده می شود. برای مثال:

s% برای نگهدارنده رشته ها و d% برای نگهداری از اعداد صحیح استفاده می شود. توجه داشته باشید که آن ها کوتیشن ندارند.

()wpdb->prepare$ مراقب عبور و کوتیشن ها برای ما می باشد. مزیت این کار فراموشی استفاده ما از ()esc_sql به صورت دستی می باشد، همچنین آن برای مرور در یک نگاه و فراموشی این که چیزی عبور کرده یا نه بسیار آسان است، چون آن درست زمانی که پرس و جو اتفاق می افتد انجام می شود.

برای اطلاعات بیشتر اعتبار سنجی داده ها را در  Codex مطالعه نمایید.

#پرس و جوهای پایگاه داده Database Queries

از دستکاری پایگاه داده به صورت مستقیم اجتناب کنید. در صورتی که شما می توانید با تعریف یک تابع معین به اطلاعاتی که نیاز دارید دست یابید. مفهوم پایگاه داده ( استفاده از توابع به جای پرس و جو ) کمک می کند تا کدهای شما در آینده سازگار باشد و در مواردی که نتایج در حافظه ذخیره می شوند، می تواند آن را چند بار سریع تر کند.

اگر شما باید به پایگاه داده دسترسی داشته باشید، با ارسال یک پیام به wp-hackers mailing list با برخی از توسعه دهندگان ارتباط داشته باشید. آن ها ممکن است در اندیشه ایجاد یک تابع جدید برای ورژن جدید وردپرس برای خواسته شما باشند.

#قرارداد نامگذاری Naming Conventions

از کلمات با حروف کوچک در متغیر، action و نام های توابع استفاده کنید.(هرگز از camelCase استفاده نکنید). کلمات توسط زیر خط جدا می شوند. نام متغیرهای بی ارزش را خلاصه نکنید؛ اجازه دهید کد بدون ابهام و مستند باشد.

در نام کلاس ها باید از حروف بزرگ استفاده کرد و با زیر خط آن ها را جدا کرد. هر کلمه اختصاری باید حروف بزرگ داشته باشد.

حروف تمام ثابت ها باید بزرگ بوده و با زیرخط کلمات از هم جدا شوند:

فایل باید با استفاده از حروف کوچک به صورت توصیفی نامگذاری شوند. کلمات باید با خط فاصله جدا شوند.

نام فایل های کلاس باید متکی بر نام کلاس با -class اضافه شوند و زیر خط در نام کلاس با خط فاصله جایگزین می شود، برای مثال WP_Error تبدیل می شود به:

این استاندارد نامگذاری فایل برای همه فایل های فعلی و جدید با کلاس ها است. یک استثنا برای سه فایل حاوی کد منتقل شده به دکمه برگشت وجود دارد:

class.wp-scripts.php, class.wp-styles.php ,class.wp-dependencies.php این فایل ها توسط .class اضافه شده اند، یک نقطه بعد از کلمه class بجای خط فاصله استفاده می شود.

فایل های حاوی تگ های قالب در wp-includes باید دارای template- در انتهای نام آن ها به صورت آشکار داشته باشند.

#خود توصیفی ارزش Flag برای پارامترهای توابع

در هنگام فراخوانی توابع ارزش رشته ها فقط true و false ترجیح داده می شوند.

از آنجا که php از استدلال نام پشتیبانی نمی کند، ارزش flag ها بی معنی است و هر زمان بخواهیم یک تابع سراسری شبیه مثال بالا را فراخوانی کنیم، ما باید تعریف تابع را جستجو کنیم. کد می تواند قابل خواناتر توسط استفاده از مقدار رشته ای به جای بولین ساخته شود.

وقتی که کلمات زیادی برای توصیف پارامترهای تابع نیاز داریم، یک آرایه args$ شاید یک الگوی خوب باشد.

#الحاق برای نامگذاری داینامیک هوک ها Interpolation for Naming Dynamic Hooks

هوک های داینامیک باید با استفاده از الحاق به جای تسلسل برای خوانایی بهتر و کشف اهداف نامگذاری شوند.

هوک های داینامیک هوک هایی شامل مقادیر داینامیک در نام تگ خود هستند، مثال:  {$new_status}_{$post->post_type}

(publish_post)

متغیر های استفاده شده در تگ های هوک باید تو در تو در براکتهای { و } باشند، با تکمیل نام تگ بیرونی تو در تو در جفت کوتیشن.

این برای اطمینان به php است که می تواند به درستی نوع متغیرهای داده شده را با داخل کردن رشته ها parse کند.

در صورت امکان، همچنین مقادیر داینامیک در اسامی تگ باید تا جایی که ممکن است مختصر شوند.

user_id$ خیلی بیشتر از خود مستند است، گفته می شود، this->id$

#عملگر سه تایی Ternary Operator

عملگرهای سه گانه خوب هستند، اما همیشه آن ها تست می شوند اگر درست بوده و غلط نباشند. در غیر این صورت، آن فقط گیج کننده می شود. ( با استفاده از ()empty! به عنوان یک تست غلط به طور کلی بیشتر به صورت بصری یک استثنا خواهد بود. )

برای مثال

#شرایط  Yoda Conditions

هنگام انجام مقایسه متغیرهای پیچیده، همیشه متغیرها را در سمت راست و ثابت ها، literals یا فراخوانی تابع ها را در سمت چپ قرار دهید. اگر هیچ طرفی متغیر ندارد این توصیه اهمیتی ندارد. ( در علوم کامپیوتر، همیشه در مقایسه سعی بر قرار دادن متغیرهای l در سمت راست و متغیرهای r در سمت چپ می باشد. )

در مثال بالا، اگر شما هر یک از علامت های مساوی را حذف کنید، شما یک خطا در parse دریافت می کنید، چون شما نمی توانید به یک ثابت چیزی شبیه true اختصاص دهید. اگر دستورالعمل جای دیگری در اطراف بود ( the_force = true$ )، دستورالعمل کاملا معتبر خواهد بود ( 1 را برمی گرداند )، نتیجه دستور if برابر true می شود و شما می توانید آن باگ را در یک حلقه تعقیب کنید.

این برای خواندن کمی عجیب و غریب بود. از آن استفاده کنید تا آن را درک کنید.

این به ==، =!، === و ==! اعمال می شود. شرایط Yoda برای <,>,=> یا =< به طور قابل ملاحظه ای بسیار دشوار هستند و بهتر است از آن ها اجتناب کرد.

#کد هوشمند Clever Code

به طور کلی، خوانایی در هوشمند بودن یا اختصار بسیار مهم می باشد.

هر چند خط بالا هوشمندانه است، اگر شما با آن آشنا نباشید آن یک حلقه در grok اخذ می کند. بنابراین، فقط آن را شبیه زیر بنویسید:

در یک تابع switch، بهتر است که چند مورد خالی به جای یک بلوک رایج از بین برود. اگر یک پرونده حاوی یک بلوک باشد، پس به بلوک بعدی منتقل می شود، با این حال، این باید صریحاً نظر داده شود.

#کنترل خطای عملگر @ Error Control Operator

همانطور که در PHP docs اشاره شده است:

php از یک کنترل خطای عملگر پشتیبانی می کند: آن @ است. هنگامی که یک اصطلاح در php اضافه شده باشد. هرگونه خطایی که ممکن است توسط آن اصطلاح تولید شود نادیده گرفته می شود.

در حالی که این عملگر داخل هسته موجود است، اغلب با تنبلی به جای بررسی مناسب خطا استفاده می شود. همچنین استفاده از آن در PHP docs نیز بسیار دلسرد کننده است:

هشدار: در حال حاضر پیشوند عملگر کنترل خطای @ گزارش خطا را حتی برای خطاهای بحرانی با خاتمه دادن به اجرای اسکریپت غیر فعال می کند. در میان چیزهای دیگر، این بدان معنی است که اگر شما از @ برای متوقف کردن خطاها از یک تابع خاص استفاده می کنید و هر یک از آن دو موجود نیست یا اشتباه بوده است، بدون هیچ چون و چرا اسکریپت سمت راست از بین خواهد رفت.

#()Don’t extract

مطابق #22400

()extract یک تابع وحشتناک است که دیباگ و فهم کد را سخت تر می کند. ما باید از استفاده آن دلسرد شده و تمام استفاده های قبلی از آن را از بین ببریم.

Joseph Scott یک نوشته خوب در مورد اینکه چرا آن بد است دارد.

در این مرحله استانداردهای php نیز به پایان می رسد و این اتمام ماجرا نیست شما برای مطالعه بیشتر می توانید Pear standards و PHP Documentation Standards را مطالعه نمایید.

در ادامه به آموزش طراحی قالب با وردپرس خواهیم پرداخت همچنین سازگاری آن با انواع افزونه را شرح خواهیم داد.

دوستان اگر در ترجمه مطالب مشکلی وجود داشت عذر بنده را پذیرا باشید، بهترین رفرنس همیشه منبع اصلی است و این هم در نظر داشته باشید بعضی از کلمات در برنامه نویسی اصطلاح هستند و نمی شود  آن را دقیق ترجمه نمود.

در مطلب قبلی می توانید استاندارد جاوا اسکریپت در وردپرس را مطالعه نمایید.




مطالب مرتبط با این دسته بندی