PHP 編程的 5 個良好習慣

根據具體的狀況,通常的開發人員每每比優秀的開發人員的效率低 10%~20%。優秀的開發人員的效率更高,由於他們擁有豐富的經驗和良好的編程習慣。不良的編程習慣將會影響到效率。本文經過展現一些良好的編程習慣,幫助您成爲更優秀的程序員。php

這 些良好的編程習慣不只能提升效率,還能讓您編寫出在應用程序的整個生命週期中易於維護的代碼。編寫出來的代碼可能須要大量的維護;應用程序的維護是一筆很 大的開支。養成良好的編程習慣可以提升設計質量(好比模塊化),從而使代碼更加容易理解,所以維護就更加容易,同時也下降維護成本。html

不良的編程習慣會形成代碼缺陷,使其難以維護和修改,而且極可能在修改時又引入其餘缺陷。如下是 5 個良好的編程習慣,可以幫助 PHP 代碼避免這些缺陷:mysql

  1. 使用良好的命名。
  2. 分紅更小的部分。
  3. 爲代碼添加註釋。
  4. 處理錯誤條件。
  5. 切忌使用複製粘貼。

下一小節將詳細介紹這些習慣。程序員

使用良好的命名web

使用良好的命名是最重要的編程習慣,由於描述性強的名稱讓代碼更加容易閱讀和理解。代碼是否好理解取決因而否能在將來維護它。即使代碼不帶有註釋,若是它很容易理解,將大大方便往後的更改。這個習慣的目標是讓您編寫的代碼像書本同樣容易閱讀和理解。sql

不良習慣:含糊的或無心義的名稱編程

清單 1 中的代碼包含太短的變量名、難以辨認的縮寫詞,而且方法名不能反映該方法的功能。若是方法名給人的感受是它應該作這件事情,而實際中它卻作另外的事情,這將帶來嚴重的問題,由於它會誤導人。安全

 

清單 1. 不良習慣:含糊的或無心義的名稱app

 

                <?php
 
function getNBDay($d)
{
    switch($d) {
        case 5:
        case 6:
        case 7:
            return 1;
        default:
            return ($d + 1);
    }
}
 
$day = 5;
 
$nextDay = getNBDay($day);
 
echo ("Next day is: " . $nextDay . "n");
 
?>

 

良好習慣:說明性強而且簡潔的名稱編輯器

清單 2 中的代碼體現了良好的編程習慣。新的方法名具備很強的說明性,反映了方法的用途。一樣,更改後的變量名也更具說明性。唯一的保持最短的變量是 $i,在本清單中,它是一個循環變量。儘管不少人不贊同使用太短的名稱,但在循環變量中使用仍是能夠接受的(甚至有好處),由於它明確代表了代碼的功能。

 

清單 2. 良好習慣:說明性強而且簡潔的名稱

 

                <?php
 
define ('MONDAY', 1);
define ('TUESDAY', 2);
define ('WEDNESDAY', 3);
define ('THURSDAY', 4);
define ('FRIDAY', 5);
define ('SATURDAY', 6);
define ('SUNDAY', 7);
 
/*
*
* @param $dayOfWeek
* @return int Day of week, with 1 being Monday and so on.
*/
function findNextBusinessDay($dayOfWeek)
{
    $nextBusinessDay = $dayOfWeek;
 
    switch($dayOfWeek) {
        case FRIDAY:
        case SATURDAY:
        case SUNDAY:
            $nextBusinessDay = MONDAY;
            break;
        default:
            $nextBusinessDay += 1;
            break;
    }
 
    return $nextBusinessDay;
}
 
$day = FRIDAY;
 
$nextBusDay = findNextBusinessDay($day);
 
echo ("Next day is:" . $nextBusDay . "n");
 
?>

 

咱們鼓勵您將大的條件拆分爲一個方法,而後用可以描述該條件的名字命名方法。這個技巧可以提升代碼的可讀性,而且可以將條件具體化,使之可以被提取甚至重用。若是條件發生變化,更新方法也很容易。由於方法擁有一個有意義的名字,因此它能反映代碼的用途,讓代碼更容易閱讀。

 

\
\
\
 



分紅更小的部分

專心解決一個問題以後再繼續編程,這樣會讓您更輕鬆。在解決一個緊急的問題時,若是繼續編程,會使函數愈來愈長。從長遠來講,這並非一個問題,但您要記得回過頭來將它重構爲更小的部分。

重構是個不錯的主意,但您應該養成編寫更短、功能更集中的代碼。短的方法可以在一個窗口中一次看完,而且容易理解。若是方法過長,不能在一個窗口中一次看完,那麼它就變得不容易理解,由於您不能快速地從頭至尾瞭解它的整個思路。

構建方法時,您應該養成這樣的習慣,讓每一個方法只完成一件事情。這個習慣很好,由於:首先,若是方法只完成一件事情,那麼它就更容易被重用;其次,這樣的方法容易測試;第三,這樣的方法便於理解和更改。

不良習慣:過長的方法(完成不少件事情)

清單 3 展現了一個很長的函數,其中存在不少問題。它完成不少件事情,所以不夠緊湊。它也不便於閱讀、調試和測試。它要作的事情包括遍歷一個文件、構建一個列表、爲每一個對象賦值、執行計算等等。

 

清單 3. 不良習慣:過長的函數

 

                <?php
 
function writeRssFeed($user)
{
    // Get the DB connection information
 
 
    // look up the user's preferences...
    $link = mysql_connect('mysql_host', 'mysql_user', 'mysql_password')
        OR die(mysql_error());
 
    // Query
    $perfsQuery = sprintf("SELECT max_stories FROM user_perfs WHERE user= '%s'",
            mysql_real_escape_string($user));
 
    $result = mysql_query($query, $link);
 
    $max_stories = 25; // default it to 25;
 
    if ($row = mysql_fetch_assoc($result)) {
        $max_stories = $row['max_stories'];
    }
 
    // go get my data
    $perfsQuery = sprintf("SELECT * FROM stories WHERE post_date = '%s'",
            mysql_real_escape_string());
 
    $result = mysql_query($query, $link);
 
 
    $feed = "<rss version="2.0">" .
        "<channel>" .
        "<title>My Great Feed</title>" .
        "<link>http://www.example.com/feed.xml</link>" .
        "<description>The best feed in the world</description>" .
        "<language>en-us</language>" .
        "<pubDate>Tue, 20 Oct 2008 10:00:00 GMT</pubDate>" .
        "<lastBuildDate>Tue, 20 Oct 2008 10:00:00 GMT</lastBuildDate>" .
        "<docs>http://www.example.com/rss</docs>" .
        "<generator>MyFeed Generator</generator>" .
        "<managingEditor>editor@example.com</managingEditor>" .
        "<webMaster>webmaster@example.com</webMaster>" .
        "<ttl>5</ttl>";
 
        // build the feed...
        while ($row = mysql_fetch_assoc($result)) {
            $title = $row['title'];
            $link = $row['link'];
            $description = $row['description'];
            $date = $row['date'];
            $guid = $row['guid'];
 
            $feed .= "<item>";
            $feed .= "<title>" . $title . "</title>";
            $feed .= "<link>" . $link . "</link>";
            $feed .= "<description> " . $description . "</description>";
            $feed .= "<pubDate>" . $date . "</pubDate>";
            $feed .= "<guid>" . $guid . "</guid>";
            $feed .= "</item>";
        }
 
        $feed .= "</rss";
 
        // write the feed out to the server...
        echo($feed);
 
}
 
?>

 

若是多編寫幾個這樣的方法,維護就成了真正的難題了。

良好習慣:易管理、功能專注的方法

清單 4 將原來的方法改寫爲更加緊湊、易讀的方法。在這個示例中,將一個很長的方法分解爲幾個短方法,而且讓每一個短方法負責一件事情。這樣的代碼對未來的重用和測試都是大有裨益的。

 

清單 4. 良好習慣:易管理、功能專注的方法

 

                <?php
 
function createRssHeader()
{
    return "<rss version="2.0">" .
        "<channel>" .
        "<title>My Great Feed</title>" .
        "<link>http://www.example.com/feed.xml</link>" .
        "<description>The best feed in the world</description>" .
        "<language>en-us</language>" .
        "<pubDate>Tue, 20 Oct 2008 10:00:00 GMT</pubDate>" .
        "<lastBuildDate>Tue, 20 Oct 2008 10:00:00 GMT</lastBuildDate>" .
        "<docs>http://www.example.com/rss</docs>" .
        "<generator>MyFeed Generator</generator>" .
        "<managingEditor>editor@example.com</managingEditor>" .
        "<webMaster>webmaster@example.com</webMaster>" .
        "<ttl>5</ttl>";
}
 
function createRssFooter()
{
    return "</channel></rss>";
}
 
function createRssItem($title, $link, $desc, $date, $guid)
{
    $item .= "<item>";
    $item .= "<title>" . $title . "</title>";
    $item .= "<link>" . $link . "</link>";
    $item .= "<description> " . $description . "</description>";
    $item .= "<pubDate>" . $date . "</pubDate>";
    $item .= "<guid>" . $guid . "</guid>";
    $item .= "</item>";
    return $item;
}
 
function getUserMaxStories($db_link, $default)
{
    $perfsQuery = sprintf("SELECT max_stories FROM user_perfs WHERE user= '%s'",
            mysql_real_escape_string($user));
 
    $result = mysql_query($perfsQuery, $db_link);
 
    $max_stories = $default;
 
    if ($row = mysql_fetch_assoc($result)) {
        $max_stories = $row['max_stories'];
    }
 
    return $max_stories;
}
 
function writeRssFeed($user)
{
    // Get the DB connection information
    $settings = parse_ini_file("rss_server.ini");
 
    // look up the user's preferences...
    $link = mysql_connect($settings['db_host'], $settings['user'],
        $settings['password']) OR die(mysql_error());
 
    $max_stories = getUserMaxStories($link, 25);
 
    // go get my data
    $newsQuery = sprintf("SELECT * FROM stories WHERE post_date = '%s'",
            mysql_real_escape_string(time()));
 
    $result = mysql_query($newsQuery, $link);
 
    $feed = createRssHeader();
 
    $i = 0;
    // build the feed...
    while ($row = mysql_fetch_assoc($result)) {
        if ($i < $max_stories) {
            $title = $row['title'];
            $link = $row['link'];
            $description = $row['description'];
            $date = $row['date'];
            $guid = $row['guid'];
 
            $feed .= createRssItem($title, $link, $description, $date, $guid);
 
            $i++;
        } else {
            break;
        }
    }
 
    mysql_close($link);
 
    $feed .= createRssFooter();
 
    // write the feed out to the server...
    echo($feed);
}
?>

 

將長方法拆分爲短方法也是有限制的,過分拆分將拔苗助長。所以,不要濫用這個良好的習慣。將代碼分紅大量的片斷就像沒有拆分長代碼同樣,都會形成閱讀困難。

 

\
\
\
 



爲代碼添加註釋

要爲代碼添加良好的註釋有時彷佛和編寫代碼同樣難。要了解應該爲哪些內容添加註釋並不容易,由於咱們經常傾向於註釋代碼當前作的事情。註釋代碼的目的是不錯的主意。在函數的不是很明顯的頭部代碼塊中,告訴讀者方法的輸入和輸出,以及方法的最初目標。

註釋代碼當前作什麼是很常見的,但這是沒必要要的。若是代碼很複雜,不得不註釋它當前在作什麼,這將暗示您應該重寫代碼,讓它更容易理解。學會使用良好的名稱和更短的方法,在不提供註釋說明其用途的狀況下提升代碼的可讀性。

不良習慣:函數註釋過多或不足

清單 5 中的註釋僅告訴讀者代碼在作什麼 — 它正在經過一個循環進行迭代或添加一個數字。但它忽略了它爲何 作當前的工做。這使維護該代碼的人員不知道是否能夠安全地更改代碼(不引入新缺陷)。

 

清單 5. 不良習慣:函數註釋過多或不足

 

                <?php
 
class ResultMessage
{
    private $severity;
    private $message;
 
    public function __construct($sev, $msg)
    {
        $this->severity = $sev;
        $this->message = $msg;
    }
 
    public function getSeverity()
    {
        return $this->severity;
    }
 
    public function setSeverity($severity)
    {
        $this->severity = $severity;
    }
 
    public function getMessage()
    {
        return $this->message;
    }
 
    public function setMessage($msg)
    {
        $this->message = $msg;
    }
}
 
function cntMsgs($messages)
{
    $n = 0;
    /* iterate through the messages... */
    foreach($messages as $m) {
        if ($m->getSeverity() == 'Error') {
            $n++; // add one to the result;
        }
    }
    return $n;
}
 
$messages = array(new ResultMessage("Error", "This is an error!"),
    new ResultMessage("Warning", "This is a warning!"),
    new ResultMessage("Error", "This is another error!"));
 
$errs = cntMsgs($messages);
 
echo("There are " . $errs . " errors in the result.n");
 
?>

 

良好習慣:帶註釋的函數和類

清單 6 中的註釋告訴讀者類和方法的目的。該註釋解釋了爲何代碼在作當前的工做,這對將來維護代碼十分有用。可能須要根據條件變動而修改代碼,若是可以輕鬆瞭解代碼的目的,則修改起來很容易。

 

清單 6. 良好習慣:帶註釋的函數和類

 

                <?php
/**
* The ResultMessage class holds a message that can be returned
* as a result of a process. The message has a severity and
* message.
*
* @author nagood
*
*/
class ResultMessage
{
    private $severity;
    private $message;
 
    /**
     * Constructor for the ResultMessage that allows you to assign
     * severity and message.
     * @param $sev See {@link getSeverity()}
     * @param $msg
     * @return unknown_type
     */
    public function __construct($sev, $msg)
    {
        $this->severity = $sev;
        $this->message = $msg;
    }
 
    /**
     * Returns the severity of the message. Should be one
     * "Information", "Warning", or "Error".
     * @return string Message severity
     */
    public function getSeverity()
    {
        return $this->severity;
    }
 
    /**
     * Sets the severity of the message
     * @param $severity
     * @return void
     */
    public function setSeverity($severity)
    {
        $this->severity = $severity;
    }
 
    public function getMessage()
    {
        return $this->message;
    }
 
    public function setMessage($msg)
    {
        $this->message = $msg;
    }
}
 
 
/*
* Counts the messages with the given severity in the array
* of messages.
*
* @param $messages An array of ResultMessage
* @return int Count of messages with a severity of "Error"
*/
function countErrors($messages)
{
    $matchingCount = 0;
    foreach($messages as $m) {
        if ($m->getSeverity() == "Error") {
            $matchingCount++;
        }
    }
    return $matchingCount;
}
 
$messages = array(new ResultMessage("Error", "This is an error!"),
    new ResultMessage("Warning", "This is a warning!"),
    new ResultMessage("Error", "This is another error!"));
 
$errs = countErrors($messages);
 
echo("There are " . $errs . " errors in the result.n");
 
?>



\
\
\
 



處理錯誤

根據大衆的經驗,若是要編寫健壯的應用程序,錯誤處理要遵循 80/20 規則:80% 的代碼用於處理異常和驗證,20% 的代碼用於完成實際工做。在編寫程序的基本邏輯(happy-path)代碼 時常常這樣作。這意味着編寫適用於基本條件的代碼,即全部的數據都是可用的,全部的條件符合預期。這樣的代碼在應用程序的生命週期中可能很脆弱。另外一個極端是,甚至須要花大量時間爲從未遇到過的條件編寫代碼。

這一習慣要求您編寫足夠的錯誤處理代碼,而不是編寫對付全部錯誤的代碼,以至代碼遲遲不能完成。

不良習慣:根本沒有錯誤處理代碼

清單 7 中的代碼演示了兩個不良習慣。第一,沒有檢查輸入的參數,即便知道處於某些狀態的參數會形成方法出現異常。第二,代碼調用一個可能拋出異常的方法,但沒有處理該異常。當發生問題時,代碼的做者或維護該代碼的人員只能猜想問題的根源。

 

清單 7. 不良習慣:不處理錯誤條件

 

                <?php
 
// Get the actual name of the
function convertDayOfWeekToName($day)
{
    $dayNames = array(
    "Sunday",
    "Monday",
    "Tuesday",
    "Wednesday",
    "Thursday",
    "Friday",
    "Saturday");
    return $dayNames[$day];
}
 
echo("The name of the 0 day is:  " . convertDayOfWeekToName(0) . "n");
echo("The name of the 10 day is:  " . convertDayOfWeekToName(10) . "n");
echo("The name of the 'orange' day is:  " . convertDayOfWeekToName('orange') . "n");
 
?>

 

良好習慣:處理異常

清單 8 展現了以有意義的方式拋出和處理異常。額外的錯誤處理不只使代碼更加健壯,它還提升代碼的可讀性,使代碼更容易理解。處理異常的方式很好地說明了原做者在編寫方法時的意圖。

 

清單 8. 良好習慣:處理異常

 

                <?php
 
/**
* This is the exception thrown if the day of the week is invalid.
* @author nagood
*
*/
class InvalidDayOfWeekException extends Exception { }
 
class InvalidDayFormatException extends Exception { }
 
/**
* Gets the name of the day given the day in the week. Will
* return an error if the value supplied is out of range.
*
* @param $day
* @return unknown_type
*/
function convertDayOfWeekToName($day)
{
    if (! is_numeric($day)) {
        throw new InvalidDayFormatException('The value '' . $day . '' is an ' .
            'invalid format for a day of week.');
    }
 
    if (($day > 6) || ($day < 0)) {
        throw new InvalidDayOfWeekException('The day number '' . $day . '' is an ' .
            'invalid day of the week. Expecting 0-6.');
    }
 
    $dayNames = array(
    "Sunday",
    "Monday",
    "Tuesday",
    "Wednesday",
    "Thursday",
    "Friday",
    "Saturday");
    return $dayNames[$day];
}
 
echo("The name of the 0 day is:  " . convertDayOfWeekToName(0) . "n");
 
try {
    echo("The name of the 10 day is:  " . convertDayOfWeekToName(10) . "n");
} catch (InvalidDayOfWeekException $e) {
    echo ("Encountered error while trying to convert value:  " . $e->getMessage() . "n");
}
 
try {
    echo("The name of the 'orange' day is:  " . convertDayOfWeekToName('orange') . "n");
} catch (InvalidDayFormatException $e) {
    echo ("Encountered error while trying to convert value:  " . $e->getMessage() . "n");
}
 
?>

 

雖然檢查參數是一種確認 — 若是您要求參數處於某種狀態,這將對使用方法的人頗有幫助 — 可是您應該檢查它們並拋出有意義的異常:

  • 處理異常要儘可能與出現的問題緊密相關。
  • 專門處理每一個異常。

 

\
\
\
 



切忌使用複製粘貼

您能夠從其餘地方將代碼複製粘貼到本身的代碼編輯器,但這樣作有利也有弊。好的一面是,從一個示例或模板中複製代碼可以避免不少錯誤。很差的一面是,這容易帶來大量的相似編程方式。

必定要注意,不要將代碼從應用程序的一部分複製粘貼到另外一部分。若是您採用這種方式,請中止這個不良的習慣,而後考慮將這段代碼重寫爲可重用的。通常而言,將代碼放置到一個地方便於往後的維護,由於這樣只需在一個地方更改代碼。

不良習慣:相似的代碼段

清單 9 給出了幾個幾乎同樣的方法,只是其中的值不一樣而已。有一些工具能夠幫助找到複製粘貼過來的代碼(參見 參考資料)。

 

清單 9. 不良習慣:相似的代碼段

 

                <?php
/**
* Counts the number of messages found in the array of
* ResultMessage with the getSeverity() value of "Error"
*
* @param $messages An array of ResultMessage
* @return unknown_type
*/
function countErrors($messages)
{
    $matchingCount = 0;
    foreach($messages as $m) {
        if ($m->getSeverity() == "Error") {
            $matchingCount++;
        }
    }
    return $matchingCount;
}
 
/**
* Counts the number of messages found in the array of
* ResultMessage with the getSeverity() value of "Warning"
*
* @param $messages An array of ResultMessage
* @return unknown_type
*/
function countWarnings($messages)
{
    $matchingCount = 0;
    foreach($messages as $m) {
        if ($m->getSeverity() == "Warning") {
            $matchingCount++;
        }
    }
    return $matchingCount;
}
 
/**
* Counts the number of messages found in the array of
* ResultMessage with the getSeverity() value of "Information"
*
* @param $messages An array of ResultMessage
* @return unknown_type
*/
function countInformation($messages)
{
    $matchingCount = 0;
    foreach($messages as $m) {
        if ($m->getSeverity() == "Information") {
            $matchingCount++;
        }
    }
    return $matchingCount;
}
 
$messages = array(new ResultMessage("Error", "This is an error!"),
    new ResultMessage("Warning", "This is a warning!"),
    new ResultMessage("Error", "This is another error!"));
 
$errs = countErrors($messages);
 
echo("There are " . $errs . " errors in the result.n");
?>

 

良好習慣:帶參數的可重用函數

清單 10 展現了修改後的代碼,它將複製的代碼放到一個方法中。另外一個方法也進行了更改,它如今將任務委託給新的方法。構建通用的方法須要花時間設計,而且這樣作使您能停下來思考,而不是本能地使用複製粘貼。但有必要進行更改時,對通用的方法投入的時間將獲得回報。

 

清單 10. 良好習慣:帶參數的可重用函數

 

                <?php
    /*
     * Counts the messages with the given severity in the array
     * of messages.
     *
     * @param $messages An array of ResultMessage
     * @return int Count of messages matching $withSeverity
     */
    function countMessages($messages, $withSeverity)
    {
        $matchingCount = 0;
        foreach($messages as $m) {
            if ($m->getSeverity() == $withSeverity) {
                $matchingCount++;
            }
        }
        return $matchingCount;
    }
 
    /**
     * Counts the number of messages found in the array of
     * ResultMessage with the getSeverity() value of "Error"
     *
     * @param $messages An array of ResultMessage
     * @return unknown_type
     */
    function countErrors($messages)
    {
        return countMessages($messages, "Errors");
    }
 
    /**
     * Counts the number of messages found in the array of
     * ResultMessage with the getSeverity() value of "Warning"
     *
     * @param $messages An array of ResultMessage
     * @return unknown_type
     */
    function countWarnings($messages)
    {
        return countMessages($messages, "Warning");
    }
 
    /**
     * Counts the number of messages found in the array of
     * ResultMessage with the getSeverity() value of "Warning"
     *
     * @param $messages An array of ResultMessage
     * @return unknown_type
     */
    function countInformation($messages)
    {
        return countMessages($messages, "Information");
    }
 
    $messages = array(new ResultMessage("Error", "This is an error!"),
        new ResultMessage("Warning", "This is a warning!"),
        new ResultMessage("Error", "This is another error!"));
 
    $errs = countErrors($messages);
 
    echo("There are " . $errs . " errors in the result.n");
 
?>



\
\
\
 



結束語

若是您在編寫 PHP 代碼的過程當中養成本文討論的良好習慣,您將可以構建易讀、易理解、易維護的代碼。使用這種方式構建的易維護代碼將下降調試、修復和擴展代碼所面臨的風險。

使用良好的名稱和更短的方法可以提升代碼的可讀性。註釋代碼的目的有利於代碼理解和擴展。適當地處理錯誤會使代碼更加健壯。最後,中止使用複製粘貼,保持代碼乾淨,提升可重用性。

 

 

 



相關文章
相關標籤/搜索