با قسمت دهم از «دوره تخصصی استانداردهای طراحی قالب وردپرس» در خدمت شما هستیم. در این قسمت استانداردهای مربوط به قرار دادن کد php در وردپرس را تا پایان بررسی خواهیم کرد.
ادامه ی استانداردها به شرح زیر هستند:
زمانی که کدهای پیچیده ی SQL را قالببندی می کنید، احتمالا مجبور می شوید که این کدها را به خط های متعدد تقسیم کنید و نیز در این خطوط از فرورفتگی هایی با استفاده از کلید tab هم استفاده خواهید کرد. البته بعضی از کدها را می توان در یک خط نوشت. به خاطر داشته باشید که قسمت های SQL کد را با حروف بزرگ بنویسید. مثل: UPDATE
و WHERE
فانکشن هایی که مسئولیت بروزرسانی دیتابیس را برعهده دارند، هنگام گذشت باید فاقد SQL slash escaping باشند. Escaping باید تا حد ممکن، قبل از به اتمام رسیدن زمان کوئری انجام شود. ترجیحا با استفاده از متد ()wpdb->prepare$ .
متد ()wpdb->prepare$ متدی است که escaping و quoting و int-casting را برای کوئری های SQL کنترل می کند. این متد از یک زیرمجموعه ی ()sprintf استفاده می کند. مثال:
$var = "dangerous'"; // raw data that may or may not need to be escaped $id = some_foo_number(); // data we expect to be an integer, but we're not certain $wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET post_title = %s WHERE ID = %d", $var, $id ) );
علامت s% در کد بالا برای متغیر های رشته ای و علامت d% برای متغیر های نگهدارنده ی اعداد، مورد استفاده قرار می گیرند. توجه داشته باشید که آن ها علامت کوتیشن ندارند. متد بالا escaping و را برای ما انجام می دهد. مزیت این متد، آن است که دیگر نیازی به بخاطر سپردن استفاده ی دستی از ()esc_sql نداریم.
از دستکاری مستقیم پایگاه داده (دیتابیس) خودداری کنید. اگر یک فانکشن تعریف شده برای دستیابی به داده های درون دیتابیس دارید، ترجیحا از آن استفاده کنید. فلسفه و دلیل ایجاد دیتابیس، استفاده از فانکشن ها به جای کوئری ها است. این کار کمک می کند که کد شما قابل پیشرفت به جلو (forward-compatible) باشد. همچنین در مواردی که نتایج از طریق حافظه ی دستگاه قابل دسترسی هستند، می توان با این روش، چندین برابر سریع تر عمل کرد.
اگر فانکشنی برای انجام کار شما وجود نداشت و مجبور به دستکاری دیتابیس شدید، اشکالی ندارد ولی یک پیام برای توسعه دهندگان وردپرس بفرستید تا برای ورژن بعدی از وردپرس، یک فانکشن مطابق خواسته ی شما ایجاد کنند.
در نامگذاری متغیرها، اکشن ها، فیلترها و فانکشن ها از حروف کوچک استفاده کنید (هرگز از روش camelCase برای نام گذاری این موارد استفاده نکنید). کلماتشان را نیز با علامت _ از هم جدا کنید.
function some_name( $some_variable ) { [...] }
نام کلاس ها باید با حروف بزرگ نوشته شده و کلمات آن با علامت _ از هم جدا شوند. تمام مختصرنویسی ها هم باید با حروف بزرگ نوشته شوند.
class Walker_Category extends Walker { [...] } class WP_HTTP { [...] }
برای ثابت ها هم قوانین به شکل بالا است.
define( 'DOING_AJAX', true );
نام فایل ها باید به شکلی توصیف کننده، و با حروف کوچک نوشته شوند. هر کلمه نیز با خطفاصله ( - ) از هم جدا می شوند.
my-plugin-name.php
نام فایلی که در بردارنده ی یک کلاس است باید با عبارت -class شروع شود و در ادامه ی آن، نام کلاس مدکور آورده شود. همچنین تمام علائم _ که در نام کلاس استفاده شده بودند، در نام فایل به شکا خطفاصله نمایان خواهند شد. مثلا نام فایلی که در برگیرنده ی کلاس WP_Error است، تبدیل می شود به:
class
-wp-error.php
همچنین می توان به جای خط فاصله بعد از عبارت class از نقطه استفاده کرد. مثلا:
class.wp-dependencies.php
class.wp-scripts.php
class.wp-styles.php
فایل های دارای تگ های template که در دایرکتوری wp-includes قرار دارند، باید بعد از نام خود یک عبارت template- بگیرند.
general-template.php
برای مقادیر رشته ای، زمانی که تابعی را فراخوانی می کنند، فقط true و false بگذارید.
// Incorrect function eat( $what, $slowly = true ) { ... } eat( 'mushrooms' ); eat( 'mushrooms', true ); // what does true mean? eat( 'dogfood', false ); // what does false mean? The opposite of true?
از زمانی که دیگر پی اچ پی ارگومان های نامگذاری شده را دیگر پشتیبانی نمی کند، مقدار آرگومان ها بی معنی به نظر می رسند. به همین دلیل هر زمان که به فانکشنی مثل کد بالا می رسیم، باید برای فهمیدن معنای آن به دنبال تعریف فانکشن بگردیم. چاره ی کار این چیست؟ خب! کد بالا با یک مقدار تعریفگر در رشته، خواناتر و بهتر می شود.
// Correct function eat( $what, $speed = 'slowly' ) { ... } eat( 'mushrooms' ); eat( 'mushrooms', 'slowly' ); eat( 'dogfood', 'quickly' );
وقتی که برای توضیح پارامترهای یک فانکشن به بیش از یک کلمه نیاز دارید، بهتر است که از args$ استفاده کنید.
// Even Better function eat( $what, $args ) { ... } eat ( 'noodles', array( 'speed' => 'moderate' ) );
برای نام گذاری هوک های داینامیک باید از درون یابی یا تناسب (interpolation) به جای تسلسل (concatenation) استفاده کرد. این کار باعث خوانایی بیشتر و راحت تر پیدا شدن آن ها می شود.
هوک های داینامیک، هوک هایی هستند که شامل مقادیر داینامیک در tag name هایشان می شوند. مثلا:
{$new_status}_{$post->post_type}
توابع مورد استفاده در هوک ها باید درون یک بریس {} قرار بگیرند و همراه با tag name در یک دابل کوتیشن محصور شوند.
do_action( "{$new_status}_{$post->post_type}", $post->ID, $post );
مقادیر داینامیک (dynamic values) موجود در tag name ها، باید تا آنجا که ممکن است خلاصه و مختصر نوشته شوند. مثلا user_id$ خیلی بیشتر از this->id$ برای خواننده قابل فهم است.
عملگرهای سه گانه چیز های بدی نیستند ولی زمانی که جواب آن ها true می شود از آن ها استفاده کنید، نه زمانی که جواب آن ها false می شود. زیرا در این صورت کمی پیچیده می شوند.
برای مثال:
// (if statement is true) ? (do this) : (else, do this); $musictype = ( 'jazz' == $music ) ? 'cool' : 'blah'; // (if field is not empty ) ? (do this) : (else, do this);
if ( true == $the_force ) { $victorious = you_will( $be ); }
هنگام انجام مقایسه منطقی ای که شامل متغیرها هم می شود، همیشه متغیر را در طرف راست عملگر قرار دهید و در طرف چپ از فانکشن ها، ثابت ها و غیره استفاده کنید. اگر هیچ یک از طرفین عملگر، متغیر نبودند آنگاه قانون خاصی وجود ندارد (راحت باشید!) .
در کد بالا اگر یکی از علامت های مساوی را حذف کنید با ارور مواجه خواهید شد. دلیل کاملا روشن است. شما نمی توانید به یک «ثابت» مقدار true را اختصاص دهید. بلکه فقط می توانید مقدار آن را با علامت == بررسی کنید.
به طور کلی، «خوانایی کد» بسیار مهم تر از «مختصر نویسی» و «زیرکانه نوشتن» آن است.
isset( $var ) || $var = some_function();
کد بالا با زیرکی بسیار و به صورت خلاصه نوشته شده است. اما همان طور که پیداست فهمیدن آن کمی دشوارتر می باشد. ترجیحا باید خوانا بودن کد را در اولویت قرار داد. بنابراین کد بالا را به شکل زیر می نویسیم:
if ( ! isset( $var ) ) { $var = some_function(); }
در دستور switch هیچ اشکالی ندارد که case های چندگانه ی خالی داشته باشیم. اگر یک case حاوی یک بلوک کد باشد، آنگاه به بلوک بعدی منتقل می شود. کامنت های موجود در کد دارای توضیحات بیشتری هستند.
switch ( $foo ) { case 'bar': // Correct, an empty case can fall through without comment. case 'baz': echo $foo; // Incorrect, a case with a block must break, return, or have a comment. case 'cat': echo 'mouse'; break; // Correct, a case with a break does not require a comment. case 'dog': echo 'horse'; // no break // Correct, a case can have a comment to explicitly mention the fall through. case 'fish': echo 'bird'; break; }
دستور goto هرگز نباید استفاده شود. ()eval و ()create_function هم منسوخ شده اند و دیگر نباید استفاده شوند.
دو نقل قول از طرف خود وب سایت PHP:
پی اچ پی فقط از یک عملگر کنترل کننده ی ارور پشتیبانی می کند که آن هم اتساین یا @ می باشد. هنگامی که این عملگر به یک عبارت در php اضافه شود، همه ی ارورهای مربوط به آن عبارت نادیده گرفته می شوند.
هشدار: عملگر کنترل کننده ی خطا (@)، خطاهای مهم و ضروری که باعث خراب شدن برنامه می شوند را هم نادیده می گیرد. پس اگر مثلا این عملگر را در ابتدای یک فانکشن دارای ارور ضروری قرار دهیم، بعد از کرش شدن برنامه، پی اچ پی هیچ دلیلی برای انجام این کار نشان نخواهد داد و شما هم نخواهید فهمید که برنامه چرا بسته شده است!
فانکشن ()extract، فانکشن وحشتناک و دردسرسازی است که اغلب باعث پیچیده تر شدن کدها می شود. ما (توسعه دهندگان وردپرس) به کلی بی خیال مزیت های آن شدیم و توصیه می کنیم از آن به هیچ عنوان استفاده نکنید.
به پایان قسمت دوم استانداردهای قرار دادن کد PHP در وردپرس رسیدیم. در قسمت بعدی، در کنار ما باشید.
منبع: سایت WordPress
در این قسمت، به پرسشهای تخصصی شما دربارهی محتوای مقاله پاسخ داده نمیشود. سوالات خود را اینجا بپرسید.