اعتمادًا على الموقف المحدد، غالبًا ما يكون المطورون العاديون أقل كفاءة بنسبة 10% إلى 20% من المطورين المتميزين. المطورون الجيدون أكثر كفاءة لأن لديهم خبرة واسعة وعادات برمجية جيدة. عادات البرمجة السيئة سوف تؤثر على الكفاءة. تساعدك هذه المقالة على أن تصبح مبرمجًا أفضل من خلال إظهار بعض عادات البرمجة الجيدة.
لا تؤدي عادات البرمجة الجيدة هذه إلى زيادة الكفاءة فحسب، بل تسمح لك أيضًا بكتابة تعليمات برمجية يسهل الحفاظ عليها طوال دورة حياة التطبيق الخاص بك. قد يتطلب الكود الذي تكتبه الكثير من الصيانة، كما أن صيانة التطبيق تعتبر تكلفة كبيرة. يمكن أن يؤدي تطوير عادات البرمجة الجيدة إلى تحسين جودة التصميم (مثل النمطية)، مما يجعل الكود أسهل في الفهم وبالتالي أسهل في الصيانة، مع تقليل تكاليف الصيانة أيضًا.
ستتسبب عادات البرمجة السيئة في حدوث عيوب في التعليمات البرمجية، مما يجعل من الصعب صيانتها وتعديلها، ومن المحتمل أن تؤدي إلى عيوب أخرى عند التعديل. فيما يلي 5 عادات برمجة جيدة يمكن أن تساعد كود PHP على تجنب هذه المخاطر:
◆استخدم تسمية جيدة.
◆تقسيمها إلى أجزاء أصغر.
◆إضافة تعليقات على الكود.
◆ التعامل مع حالات الخطأ.
◆لا تستخدم النسخ واللصق.
هذه العادات مفصلة أدناه:
استخدام التسمية الجيدة
يعد استخدام التسمية الجيدة من أهم عادات البرمجة لأن الأسماء الوصفية تجعل التعليمات البرمجية أسهل في القراءة والفهم. يعتمد ما إذا كان من السهل فهم الكود على ما إذا كان من الممكن الحفاظ عليه في المستقبل. حتى لو لم يتم التعليق على الكود، فإنه سيسهل إلى حد كبير التغييرات المستقبلية إذا كان من السهل فهمه. الهدف من هذه العادة هو جعل الكود الذي تكتبه سهل القراءة والفهم مثل الكتاب.
العادة السيئة: أسماء غامضة أو لا معنى لها
يحتوي الكود الموجود في القائمة 1 على أسماء متغيرات قصيرة جدًا، ومختصرات غير مقروءة، وأسماء الطرق التي لا تعكس وظيفة الطريقة. إذا كان اسم الطريقة يعطي انطباعا بأنه من المفترض أن يفعل شيئا واحدا، ولكنه في الواقع يفعل شيئا آخر، فإن هذا سوف يسبب مشاكل خطيرة لأنه سيكون مضللا.
القائمة 1. العادات السيئة: أسماء غامضة أو لا معنى لها
<?php
function getNBDay($d){
التبديل($د) {
الحالة 5:
الحالة 6:
الحالة 7:
العودة 1؛
تقصير:
العائد ($د + 1)؛
}
}
$day = 5;
$nextDay = getNBDay($day);
echo ("اليوم التالي هو: " . $nextDay . "n")
;
الممارسة الجيدة: الأسماء الوصفية والموجزة
يوضح الكود الموجود في القائمة 2 ممارسات البرمجة الجيدة. أسماء الطرق الجديدة وصفية للغاية وتعكس الغرض من الطريقة. وبالمثل، فإن أسماء المتغيرات التي تم تغييرها تكون أكثر وصفية. المتغير الوحيد الذي يظل الأقصر هو $i، وهو في هذه القائمة متغير حلقة. على الرغم من أن العديد من الأشخاص يستهجن استخدام الأسماء القصيرة جدًا، إلا أنه من المقبول (وحتى المفيد) استخدامها في متغيرات الحلقة لأنها تشير بوضوح إلى وظيفة الكود.
القائمة 2. الممارسات الجيدة: أسماء وصفية وموجزة
<?php
تحديد ('الاثنين'، 1)؛
تحديد ('الثلاثاء'، 2)؛
تحديد ("الأربعاء"، 3)؛
تحديد ('الخميس'، 4)؛
تحديد ("الجمعة"، 5)؛
تحديد ('السبت'، 6)؛
تحديد ("الأحد"، 7)؛
/*
*
* @param $dayOfWeek
* @return int يوم من أيام الأسبوع، حيث يكون الرقم 1 هو يوم الاثنين، وهكذا.
*/
الدالة findNextBusinessDay($dayOfWeek){
$nextBusinessDay = $dayOfWeek;
التبديل($dayOfWeek) {
حالة الجمعة:
حالة السبت:
حالة الأحد:
$nextBusinessDay = الاثنين;
استراحة؛
تقصير:
$nextBusinessDay += 1;
استراحة؛
}
إرجاع $nextBusinessDay؛
}
يوم $ = الجمعة؛
$nextBusDay = findNextBusinessDay($day);
echo ("اليوم التالي هو:" . $nextBusDay . "n");
?＞
نحن نشجعك على تقسيم الشروط الكبيرة إلى أسلوب، ثم تسمية الأسلوب باسم يصف الشرط. يمكن لهذه التقنية تحسين إمكانية قراءة الكود وجعل الحالة ملموسة بحيث يمكن استخراجها وحتى إعادة استخدامها. من السهل أيضًا تحديث الأساليب إذا تغيرت الظروف. نظرًا لأن الطريقة لها اسم ذو معنى، فإنها تعكس الغرض من التعليمات البرمجية وتسهل قراءة التعليمات البرمجية.
في أجزاء أصغر
قبل متابعة البرمجة. إذا واصلت البرمجة أثناء حل مشكلة عاجلة، فسوف تصبح الوظيفة أطول فأطول. على المدى الطويل، هذه ليست مشكلة، ولكن عليك أن تتذكر العودة وإعادة هيكلتها إلى أجزاء أصغر.
تعد إعادة البناء فكرة جيدة، لكن يجب أن تعتاد على كتابة تعليمات برمجية أقصر وأكثر تركيزًا. يمكن قراءة الطرق القصيرة في نافذة واحدة وسهلة الفهم. إذا كانت الطريقة طويلة جدًا بحيث لا يمكن قراءتها في نافذة واحدة، يصبح من الصعب متابعتها لأنه لا يمكنك متابعة الفكرة بأكملها بسرعة من البداية إلى النهاية.
عند بناء الطرق، يجب أن تعتاد على أن تقوم كل طريقة بشيء واحد فقط. هذه عادة جيدة لأنه: أولاً، إذا كانت الطريقة تفعل شيئًا واحدًا فقط، فمن المرجح أن يتم إعادة استخدامها؛ ثانيًا، من السهل اختبار هذه الطريقة؛ ثالثًا، من السهل فهم هذه الطريقة وتغييرها.
العادة السيئة: الأساليب الطويلة جدًا (القيام بأشياء كثيرة جدًا)
تعرض القائمة 3 دالة طويلة جدًا بها العديد من المشكلات. إنه يفعل الكثير من الأشياء، لذا فهو ليس مضغوطًا بدرجة كافية. كما أنه من الأسهل القراءة والتصحيح والاختبار. تتضمن الأشياء التي يتضمنها التكرار على ملف، وإنشاء قائمة، وتعيين قيم لكل كائن، وإجراء العمليات الحسابية، والمزيد.
القائمة 3. العادة السيئة: دالة طويلة جدًا
<?php
function writeRssFeed($user)
{
// احصل على معلومات اتصال قاعدة البيانات
// ابحث عن تفضيلات المستخدم...
رابط $ = mysql_connect('mysql_host', 'mysql_user', 'mysql_password')
أو يموت (mysql_error());
// Query
$perfsQuery = sprintf("اختر max_stories من user_perfs حيث المستخدم= '%s'"،
mysql_real_escape_string($user));
$result = mysql_query($query, $link);
$max_stories = 25؛ // القيمة الافتراضية هي 25؛
إذا ($row = mysql_fetch_assoc($result)) {
$max_stories = $row['max_stories'];
}
// اذهب واحصل على بياناتي
$perfsQuery = sprintf("SELECT * FROM Stories WHERE post_date = '%s'"،
mysql_real_escape_string());
$result = mysql_query($query, $link);
$feed = "＜rss version="2.0"＞" .
"<القناة>" .
"＜العنوان＞خلاصتي الرائعة＜/العنوان＞" .
"＜رابط＞ http://www.example.com/feed.xml ＜/link＞" .
"＜وصف＞أفضل تغذية في العالم＜/وصف＞" .
"＜لغة＞en-us＜/لغة＞" .
"＜ تاريخ النشر ＞ الثلاثاء، 20 أكتوبر 2008 10:00:00 بتوقيت جرينتش ＜/ تاريخ النشر ＞" .
"＜تاريخ البناء الأخير＞الثلاثاء، 20 أكتوبر 2008 10:00:00 بتوقيت جرينتش＜/تاريخ البناء الأخير＞" .
"＜docs＞ http://www.example.com/rss ＜/docs＞" .
"<generator>MyFeed Generator</generator>" .
"＜managingEditor＞ [email protected] ＜/managingEditor＞" .
"＜webMaster＞ [email protected] ＜/webMaster＞" .
"＜ttl＞5＜/ttl＞";
// بناء الخلاصة...
بينما ($row = mysql_fetch_assoc($result)) {
$title = $row['title'];
$link = $row['link'];
$description = $row['description'];
$date = $row['date'];
$guid = $row['guid']
;
$feed .= "＜title＞" $title "＜/title＞";
$feed .= "＜link＞" $link "＜/link＞";
$feed .= "＜description＞ " . $description "＜/description＞";
$feed .= "＜pubDate＞" $date "＜/pubDate＞";
$feed .= "＜guid＞" $guid "＜/guid＞";
$feed .= "＜/العنصر＞";
}
$feed .= "＜/rss";
// اكتب التغذية إلى الخادم...
echo($feed);
}
?>إذا كتبت عدة طرق أخرى كهذه، فستصبح الصيانة مشكلة حقيقية.
العادة الجيدة: قائمة الأساليب القابلة للإدارة والمخصصة لوظيفة محددة
4 أعد كتابة الطريقة الأصلية إلى طريقة أكثر إحكاما وقابلة للقراءة. في هذا المثال، تم تقسيم الطريقة الطويلة إلى عدة طرق قصيرة، وكل طريقة قصيرة مسؤولة عن شيء واحد. يعد هذا الرمز مفيدًا جدًا لإعادة الاستخدام والاختبار في المستقبل.
القائمة 4. الممارسة الجيدة: نهج سهل الإدارة ومخصص للوظيفة
<?php
function createRssHeader()
{
إرجاع "<rss version="2.0">" .
"<القناة>" .
"＜العنوان＞خلاصتي الرائعة＜/العنوان＞" .
"＜رابط＞ http://www.example.com/feed.xml ＜/link＞" .
"＜وصف＞أفضل تغذية في العالم＜/وصف＞" .
"＜لغة＞en-us＜/لغة＞" .
"＜ تاريخ النشر ＞ الثلاثاء، 20 أكتوبر 2008 10:00:00 بتوقيت جرينتش ＜/ تاريخ النشر ＞" .
"＜تاريخ البناء الأخير＞الثلاثاء، 20 أكتوبر 2008 10:00:00 بتوقيت جرينتش＜/تاريخ البناء الأخير＞" .
"＜docs＞ http://www.example.com/rss ＜/docs＞" .
"<generator>MyFeed Generator</generator>" .
"＜managingEditor＞ [email protected] ＜/managingEditor＞" .
"＜webMaster＞ [email protected] ＜/webMaster＞" .
"＜ttl＞5＜/ttl＞";
}
وظيفة createRssFooter()
{
إرجاع "＜/القناة＞＜/rss＞";
}
وظيفة createRssItem($title, $link, $desc, $date, $guid)
{
$item .= "＜item＞";
$item .= "＜title＞" $title "＜/title＞";
$item .= "＜رابط＞" $link "＜/رابط＞";
$item .= "＜description＞ " . $description "＜/description＞";
$item .= "＜pubDate＞" $date "＜/pubDate＞";
$item .= "＜guid＞" $guid "＜/guid＞";
$item .= "＜/item＞";
إرجاع العنصر $؛
}
الدالة getUserMaxStories($db_link, $default)
{
$perfsQuery = sprintf("اختر max_stories من user_perfs حيث المستخدم= '%s'"،
mysql_real_escape_string($user));
$result = mysql_query($perfsQuery, $db_link);
$max_stories = $default;
إذا ($row = mysql_fetch_assoc($result)) {
$max_stories = $row['max_stories'];
}
إرجاع $max_stories؛
}
وظيفة writeRssFeed($user)
{
// احصل على معلومات اتصال قاعدة البيانات
$settings = parse_ini_file("rss_server.ini");
// ابحث عن تفضيلات المستخدم...
$link = mysql_connect($settings['db_host'], $settings['user'],
$settings['password']) OR die(mysql_error());
$max_stories = getUserMaxStories($link, 25);
// اذهب واحصل على بياناتي
$newsQuery = sprintf("SELECT * FROM Stories WHERE post_date = '%s'"،
mysql_real_escape_string(time()));
$result = mysql_query($newsQuery, $link)
;
$i = 0;
// بناء الخلاصة...
بينما ($row = mysql_fetch_assoc($result)) {
إذا ($i < $max_stories) {
$title = $row['title'];
$link = $row['link'];
$description = $row['description'];
$date = $row['date'];
$guid = $row['guid']
;
$i++;
} آخر {
استراحة؛
}
}
mysql_ Close($link);
$feed .= createRssFooter();
// اكتب الخلاصة إلى الخادم...
صدى($تغذية);
}
?> هناك أيضًا قيود على تقسيم الأساليب الطويلة إلى أساليب قصيرة، كما أن التقسيم المفرط سيؤدي إلى نتائج عكسية. لذلك، لا تسيء استخدام هذه العادة الجيدة. قد يؤدي تقسيم التعليمات البرمجية إلى أجزاء كبيرة إلى جعل القراءة صعبة مثل عدم تقسيم التعليمات البرمجية الطويلة.
إضافة تعليقات إلى التعليمات البرمجية الخاصة بك
قد تبدو إضافة تعليقات جيدة إلى التعليمات البرمجية الخاصة بك في بعض الأحيان صعبة مثل كتابة التعليمات البرمجية. ليس من السهل معرفة ما يجب التعليق عليه لأننا غالبًا ما نميل إلى التعليق على ما يفعله الكود حاليًا. إنها فكرة جيدة أن تقوم بالتعليق على الغرض من التعليمات البرمجية الخاصة بك. في كتلة رأس الوظيفة الأقل وضوحًا، يتم إخبار القارئ عن مدخلات ومخرجات الطريقة، بالإضافة إلى الهدف الأصلي للطريقة.
من الشائع التعليق على ما تفعله التعليمات البرمجية حاليًا، ولكن هذا غير ضروري. إذا كانت التعليمات البرمجية معقدة وكان عليك التعليق على ما تفعله حاليًا، فسيقترح عليك إعادة كتابة التعليمات البرمجية لتسهيل فهمها. تعلم كيفية استخدام الأسماء الجيدة والأساليب الأقصر لجعل التعليمات البرمجية الخاصة بك أكثر قابلية للقراءة دون تقديم تعليقات تشرح الغرض منها.
العادة السيئة: وظائف التعليق الزائد أو الناقص
التعليقات الموجودة في القائمة 5 تخبر القارئ فقط بما يفعله الكود - فهو يتكرر من خلال حلقة أو يضيف رقمًا. لكنها تتجاهل سبب قيامها بعملها الحالي. وهذا يترك الأشخاص الذين يحافظون على الكود دون معرفة ما إذا كان يمكن تغيير الكود بأمان (دون إدخال عيوب جديدة).
القائمة 5. العادة السيئة: عدد كبير جدًا أو غير كافٍ من التعليقات الوظيفية
<?php
class ResultMessage
{
خطورة $ الخاصة؛
رسالة $ خاصة؛
الوظيفة العامة __construct($sev, $msg)
{
$this->severity = $sev;
$this->message = $msg;
}
الوظيفة العامة getSeverity ()
{
إرجاع $this->severity;
}
مجموعة الوظائف العامةSeverity($severity)
{
$this->severity = $severity;
}
الوظيفة العامة getMessage ()
{
إرجاع $this->message;
}
الوظيفة العامة setMessage($msg)
{
$this->message = $msg;
}
}
الدالة cntMsgs($messages)
{
$ن = 0;
/* التكرار عبر الرسائل...*/
foreach(رسائل $ كـ $m) {
إذا ($m->getSeverity() == 'خطأ') {
$n++; // أضف واحدًا إلى النتيجة؛
}
}
إرجاع $ ن؛
}
$messages = array(new ResultMessage("خطأ"، "هذا خطأ!")،
رسالة ResultMessage جديدة ("تحذير"، "هذا تحذير!")،
new ResultMessage("خطأ"، "هذا خطأ آخر!"));
$errs = cntMsgs($messages);
echo("هناك أخطاء " . $errs . " في النتيجة.n");
?>
الممارسة الجيدة: الوظائف والفئات المشروحة
تخبر التعليقات في القائمة 6 القارئ عن الفئات والطرق غاية. يشرح هذا التعليق سبب قيام الكود بعمله الحالي، والذي يمكن أن يكون مفيدًا عند صيانة الكود في المستقبل. قد تحتاج التعليمات البرمجية إلى التعديل مع تغير الظروف، ولكن التعديلات تكون سهلة إذا كان الغرض من التعليمات البرمجية مفهومًا بسهولة.
القائمة 6. الممارسة الجيدة: الوظائف والفئات المشروحة
<?php
/**
* تحتوي فئة ResultMessage على رسالة يمكن إرجاعها
* نتيجة لعملية الرسالة لها خطورة و
* رسالة.
*
* @المؤلف ناجود
*
*/
رسالة نتيجة الصف
{
خطورة $ الخاصة؛
رسالة $ خاصة؛
/**
* منشئ ResultMessage الذي يسمح لك بالتعيين
* الشدة والرسالة.
* @param $sev راجع {@link getSeverity()}
* @param $msg
* @عودة نوع غير معروف
*/
الوظيفة العامة __construct($sev, $msg)
{
$this->severity = $sev;
$this->message = $msg;
}
/**
* إرجاع خطورة الرسالة يجب أن تكون واحدة
* "معلومات" أو "تحذير" أو "خطأ".
* سلسلة @return خطورة الرسالة
*/
الوظيفة العامة getSeverity ()
{
إرجاع $this->severity;
}
/**
* يضبط خطورة الرسالة
* @param $ الخطورة
* @العودة فارغة
*/
مجموعة الوظائف العامةSeverity($severity)
{
$this->severity = $severity;
}
الوظيفة العامة getMessage ()
{
إرجاع $this->message;
}
الوظيفة العامة setMessage($msg)
{
$this->message = $msg;
}
}
/*
* حساب الرسائل ذات الخطورة المحددة في المصفوفة
*من الرسائل.
*
* @param $messages مجموعة من ResultMessage
* @return int عدد الرسائل ذات خطورة "خطأ"
*/
وظيفة عدد الأخطاء(رسائل $)
{
$matchingCount = 0;
foreach(رسائل $ كـ $m) {
إذا ($m->getSeverity() == "خطأ") {
$matchingCount++;
}
}
إرجاع $matchingCount؛
}
$messages = array(new ResultMessage("خطأ"، "هذا خطأ!")،
رسالة ResultMessage جديدة ("تحذير"، "هذا تحذير!")،
new ResultMessage("خطأ"، "هذا خطأ آخر!"));
$errs = countErrors($messages
echo("هناك أخطاء " . $errs . " في النتيجة.n")
;
معالجة الأخطاء
كقاعدة عامة، إذا كنت تريد كتابة تطبيقات قوية، فاتبع قاعدة 80/20 لمعالجة الأخطاء: يتم استخدام 80% من التعليمات البرمجية الخاصة بك للتعامل مع الاستثناءات والتحقق من الصحة، ويتم استخدام 20% من التعليمات البرمجية الخاصة بك للقيام بذلك. العمل الفعلي. يتم ذلك غالبًا عند ترميز المنطق الأساسي (المسار السعيد) للبرنامج. وهذا يعني كتابة التعليمات البرمجية التي تعمل تحت الغطاء، وأن جميع البيانات متاحة وجميع الشروط كما هو متوقع. يمكن أن تكون هذه التعليمات البرمجية هشة أثناء دورة حياة التطبيق. على الجانب الآخر، يستغرق الأمر وقتًا طويلاً لكتابة التعليمات البرمجية للظروف التي لم تواجهها من قبل.
تتطلب هذه العادة منك كتابة ما يكفي من التعليمات البرمجية لمعالجة الأخطاء، بدلاً من كتابة التعليمات البرمجية للتعامل مع جميع الأخطاء، بحيث لا يكتمل الرمز أبدًا.
العادات السيئة: لا توجد معالجة للأخطاء على الإطلاق يوضح الكود
الموجود في القائمة 7 عادتين سيئتين. أولاً، لم يتم التحقق من معلمات الإدخال، على الرغم من أنه من المعروف أن المعلمات في حالات معينة ستتسبب في حدوث استثناءات في الطريقة. ثانيًا، تستدعي التعليمات البرمجية أسلوبًا قد يطرح استثناءً ولكنه لا يعالج الاستثناء. عند حدوث مشكلة، يمكن لمؤلف الكود أو الشخص الذي يحافظ على الكود أن يخمن مصدر المشكلة فقط.
القائمة 7. العادة السيئة: عدم التعامل مع حالات الخطأ
<?php
// احصل على الاسم الفعلي لـ
الدالة تحويلDayOfWeekToName($day)
{
$dayNames = صفيف (
"الأحد"،
"الاثنين"،
"يوم الثلاثاء"،
"الأربعاء"،
"يوم الخميس"،
"جمعة"،
"السبت")؛
إرجاع $dayNames[$day];
}
echo("اسم اليوم 0 هو:" . converterDayOfWeekToName(0) . "n");
echo("اسم اليوم العاشر هو:" .convertDayOfWeekToName(10) ."n");
echo("اسم اليوم "البرتقالي" هو: " . converterDayOfWeekToName('orange') . "n" ?
＞
الممارسة الجيدة: التعامل مع الاستثناءات
توضح القائمة 8 طرح الاستثناءات والتعامل معها بطريقة هادفة. إن معالجة الأخطاء الإضافية لا تجعل الكود أكثر قوة فحسب، بل تعمل أيضًا على تحسين إمكانية قراءة الكود، مما يسهل فهمه. تعد طريقة معالجة الاستثناءات مؤشرًا جيدًا على نية المؤلف الأصلي عند كتابة الطريقة.
القائمة 8. الممارسات الجيدة: التعامل مع الاستثناءات
<?php
/**
* هذا هو الاستثناء الذي يتم طرحه إذا كان يوم الأسبوع غير صالح.
* @المؤلف ناجود
*
*/
فئة InvalidDayOfWeekException يمتد الاستثناء { }
فئة InvalidDayFormatException يمتد الاستثناء { }
/**
* يحصل على اسم اليوم نظرا ليوم في الأسبوع
* إرجاع خطأ إذا كانت القيمة المقدمة خارج النطاق.
*
* @param $day
* @عودة نوع غير معروف
*/
الدالة كونفيرتDayOfWeekToName($day)
{
إذا (! is_numeric($day)) {
قم بطرح InvalidDayFormatException('القيمة'' .$day .'' هي ' .
"تنسيق غير صالح ليوم من أيام الأسبوع.');
}
إذا (($day ＞ 6) || ($day ＜ 0)) {
طرح InvalidDayOfWeekException الجديد ('رقم اليوم'' . $day .'' هو ' .
"يوم غير صالح من الأسبوع. توقع 0-6.');
}
$dayNames = صفيف (
"الأحد"،
"الاثنين"،
"يوم الثلاثاء"،
"الأربعاء"،
"يوم الخميس"،
"جمعة"،
"السبت")؛
إرجاع $dayNames[$day];
}
echo("اسم اليوم 0 هو:" . converterDayOfWeekToName(0) . "n")
;
echo("اسم اليوم العاشر هو:" .convertDayOfWeekToName(10) ."n");
} التقاط (InvalidDayOfWeekException $e) {
echo ("حدث خطأ أثناء محاولة تحويل القيمة: " . $e->getMessage() . "n");
}
يحاول {
echo("اسم اليوم "البرتقالي" هو:" . converterDayOfWeekToName('orange') . "n");
} التقاط (InvalidDayFormatException $e) {
echo ("حدث خطأ أثناء محاولة تحويل القيمة: " . $e->getMessage() . "n");
}
?>
على الرغم من أن التحقق من المعلمات هو تأكيد - إذا كنت تطلب أن تكون المعلمات في حالة معينة، فسيكون ذلك مفيدًا للأشخاص الذين يستخدمون الطريقة - يجب عليك التحقق منها وطرح استثناءات ذات معنى:
◆ التعامل مع الاستثناءات بأقصى قدر ممكن من المشكلات التي تنشأ ترتبط ارتباطا وثيقا.
◆ معالجة مخصصة لكل استثناء.
لا تستخدم النسخ واللصق:
يمكنك نسخ ولصق التعليمات البرمجية من مكان آخر إلى محرر التعليمات البرمجية الخاص بك، ولكن هناك إيجابيات وسلبيات للقيام بذلك. والشيء الجيد هو أن نسخ التعليمات البرمجية من مثال أو قالب يمكن أن يتجنب العديد من الأخطاء. الجانب السلبي هو أن هذا يؤدي بسهولة إلى الكثير من أساليب البرمجة المماثلة.
احرص على عدم نسخ ولصق التعليمات البرمجية من جزء من التطبيق إلى جزء آخر. إذا كنت على هذا النحو، توقف عن هذه العادة السيئة وفكر في إعادة كتابة هذا الرمز ليكون قابلاً لإعادة الاستخدام. بشكل عام، وضع التعليمات البرمجية في مكان واحد يجعل من السهل صيانتها لاحقًا لأنها تحتاج إلى التغيير في مكان واحد فقط.
العادات السيئة: تعرض مقتطفات التعليمات البرمجية المماثلة
في القائمة 9 عدة طرق متطابقة تقريبًا، ولكن بقيم مختلفة. هناك أدوات يمكنها المساعدة في العثور على التعليمات البرمجية المنسوخة والملصقة (انظر الموارد).
القائمة 9. العادات السيئة: مقتطفات برمجية مماثلة
<?php
/**
* يحسب عدد الرسائل الموجودة في المصفوفة
* رسالة النتيجة بقيمة getSeverity () لـ "خطأ"
*
* @param $messages مجموعة من ResultMessage
* @عودة نوع غير معروف
*/
وظيفة عدد الأخطاء(رسائل $)
{
$matchingCount = 0;
foreach(رسائل $ كـ $m) {
إذا ($m->getSeverity() == "خطأ") {
$matchingCount++;
}
}
إرجاع $matchingCount؛
}
/**
* يحسب عدد الرسائل الموجودة في المصفوفة
* رسالة النتيجة بقيمة getSeverity () لـ "تحذير"
*
* @param $messages مجموعة من ResultMessage
* @عودة نوع غير معروف
*/
عدد الوظائف التحذيرات(رسائل $)
{
$matchingCount = 0;
foreach(رسائل $ كـ $m) {
إذا ($m->getSeverity() == "تحذير") {
$matchingCount++;
}
}
إرجاع $matchingCount؛
}
/**
* يحسب عدد الرسائل الموجودة في المصفوفة
* رسالة النتيجة بقيمة getSeverity () الخاصة بـ "المعلومات"
*
* @param $messages مجموعة من ResultMessage
* @عودة نوع غير معروف
*/
معلومات عدد الوظائف(رسائل $)
{
$matchingCount = 0;
foreach(رسائل $ كـ $m) {
إذا ($m->getSeverity() == "المعلومات") {
$matchingCount++;
}
}
إرجاع $matchingCount؛
}
$messages = array(new ResultMessage("خطأ"، "هذا خطأ!")،
رسالة نتيجة جديدة ("تحذير"، "هذا تحذير!")،
new ResultMessage("خطأ"، "هذا خطأ آخر!"));
$errs = countErrors($messages
echo("هناك أخطاء " . $errs . " في النتيجة.n");
?>
الممارسة الجيدة: تعرض قائمة الوظائف القابلة لإعادة الاستخدام مع المعلمات
10 الكود المعدل، مما يضع الكود المنسوخ في إحدى الطرق. تم أيضًا تغيير طريقة أخرى وتقوم الآن بتفويض المهام إلى الطريقة الجديدة. يستغرق بناء نهج مشترك وقتًا في التصميم، والقيام بذلك يسمح لك بالتوقف والتفكير، بدلاً من النسخ واللصق بشكل غريزي. ولكن الوقت المستثمر في التوصل إلى نهج مشترك سوف يؤتي ثماره عندما تصبح التغييرات ضرورية.
القائمة 10. الممارسة الجيدة: وظائف قابلة لإعادة الاستخدام مع معلمات
<?php
/*
* حساب الرسائل ذات الخطورة المحددة في المصفوفة
*من الرسائل.
*
* @param $messages مجموعة من ResultMessage
*return int عدد الرسائل المطابقة $withSeverity
*/
وظيفة countMessages($messages, $withSeverity)
{
$matchingCount = 0;
foreach(رسائل $ كـ $m) {
إذا ($m->getSeverity() == $withSeverity) {
$matchingCount++;
}
}
إرجاع $matchingCount؛
}
/**
* يحسب عدد الرسائل الموجودة في المصفوفة
* رسالة النتيجة بقيمة getSeverity () لـ "خطأ"
*
* @param $messages مجموعة من ResultMessage
* @عودة نوع غير معروف
*/
وظيفة عدد الأخطاء(رسائل $)
{
إرجاع countMessages($messages, "Errors");
}
/**
* يحسب عدد الرسائل الموجودة في المصفوفة
* رسالة النتيجة بقيمة getSeverity () لـ "تحذير"
*
* @param $messages مجموعة من ResultMessage
* @عودة نوع غير معروف
*/
عدد الوظائف التحذيرات(رسائل $)
{
إرجاع countMessages($messages, "Warning");
}
/**
* يحسب عدد الرسائل الموجودة في المصفوفة
* رسالة النتيجة بقيمة getSeverity () لـ "تحذير"
*
* @param $messages مجموعة من ResultMessage
* @عودة نوع غير معروف
*/
معلومات عدد الوظائف(رسائل $)
{
إرجاع countMessages($messages, "Information");
}
$messages = array(new ResultMessage("خطأ"، "هذا خطأ!")،
رسالة نتيجة جديدة ("تحذير"، "هذا تحذير!")،
new ResultMessage("خطأ"، "هذا خطأ آخر!"));
$errs = countErrors($messages);
echo("هناك أخطاء " . $rrs . " في النتيجة.n");
?＞
الخلاصة
إذا قمت بتطوير العادات الجيدة التي تمت مناقشتها في هذه المقالة عند كتابة كود PHP، فسوف تفعل ذلك تكون قادرًا على إنشاء كود يسهل قراءته وفهمه وصيانته. سيؤدي إنشاء التعليمات البرمجية القابلة للصيانة بهذه الطريقة إلى تقليل مخاطر تصحيح الأخطاء وإصلاحها وتوسيعها.
يؤدي استخدام الأسماء الجيدة والأساليب الأقصر إلى تحسين إمكانية قراءة التعليمات البرمجية. الغرض من التعليق على الكود هو تسهيل فهم الكود وتوسيعه. التعامل مع الأخطاء بشكل مناسب يجعل التعليمات البرمجية الخاصة بك أكثر قوة. أخيرًا، توقف عن استخدام النسخ واللصق للحفاظ على نظافة التعليمات البرمجية وتحسين إمكانية إعادة الاستخدام.