一個函數應該只有一個return語句嗎？

已鎖定 。 該問題及其答案被鎖定，由於該問題是題外話，但具備歷史意義。 它目前不接受新的答案或互動。 瞭解更多 。

是否有充分的理由說明爲何在函數中僅包含一個return語句是一種更好的作法？

仍是在邏輯上正確地從函數中返回就能夠，這意味着函數中可能有不少return語句？

---

#1樓

這多是一個不一樣尋常的觀點，可是我認爲，任何認爲支持多個return語句的人都沒必要在僅支持4個硬件斷點的微處理器上使用調試器。 ;-)

儘管「箭頭代碼」問題是徹底正確的，可是在使用多個return語句時彷佛已經消失的一個問題是使用調試器的狀況。 您沒有方便的萬能位置放置斷點以確保您將看到出口以及返回條件。

---

#2樓

我強迫本身只使用一個return語句，由於它在某種意義上會產生代碼氣味。 讓我解釋：

function isCorrect($param1, $param2, $param3) {
    $toret = false;
    if ($param1 != $param2) {
        if ($param1 == ($param3 * 2)) {
            if ($param2 == ($param3 / 3)) {
                $toret = true;
            } else {
                $error = 'Error 3';
            }
        } else {
            $error = 'Error 2';
        }
    } else {
        $error = 'Error 1';
    }
    return $toret;
}

（條件是精明的...）

條件越多，功能越大，則讀取起來就越困難。 所以，若是您習慣了代碼的味道，您就會意識到它，並但願重構代碼。 兩種可能的解決方案是：

• 屢次退貨
• 重構爲單獨的功能

屢次退貨

function isCorrect($param1, $param2, $param3) {
    if ($param1 == $param2)       { $error = 'Error 1'; return false; }
    if ($param1 != ($param3 * 2)) { $error = 'Error 2'; return false; }
    if ($param2 != ($param3 / 3)) { $error = 'Error 3'; return false; }
    return true;
}

分開的功能

function isEqual($param1, $param2) {
    return $param1 == $param2;
}

function isDouble($param1, $param2) {
    return $param1 == ($param2 * 2);
}

function isThird($param1, $param2) {
    return $param1 == ($param2 / 3);
}

function isCorrect($param1, $param2, $param3) {
    return !isEqual($param1, $param2)
        && isDouble($param1, $param3)
        && isThird($param2, $param3);
}

固然，它更長而且有點混亂，可是在以這種方式重構函數的過程當中，咱們已經

• 建立了許多可重用的功能，
• 使該功能更易於閱讀，而且
• 函數的重點在於爲何值正確。

---

#3樓

我相信屢次返回一般是好的（在我用C＃編寫的代碼中）。 單返回樣式是C的保留。可是您可能沒有使用C進行編碼。

在全部編程語言中，沒有法律只要求一個方法的一個退出點 。 有些人堅持這種風格的優越性，有時他們將其提高爲「規則」或「法律」，但這種信念沒有任何證據或研究的支持。

不止一種返回樣式在C代碼中多是一個壞習慣，在C代碼中必須顯式地取消分配資源，可是Java，C＃，Python或JavaScript之類的語言具備自動垃圾回收和try..finally塊等try..finally （並using C＃中的代碼塊），而且該參數不適用-在這些語言中，須要集中手動分配資源很是罕見。

在某些狀況下，單項退貨更具可讀性，而在某些狀況下則否則。 看看它是否減小了代碼行數，使邏輯更清晰或減小了花括號，縮進或臨時變量的數量。

所以，請使用盡量多的適合您的藝術敏感性的退貨，由於這是一種佈局和可讀性問題，而不是技術性問題。

我已經在博客上更詳細地討論了這一點 。

---

#4樓

不，由於咱們再也不生活在1970年代 。 若是您的函數足夠長而致使屢次返回是一個問題，那就太長了。

（除了如下事實外，語言中的任何多行函數（除例外狀況外）都將具備多個出口點。）

---

#5樓

你知道格言- 情人在旁觀者眼中 。

有些人對NetBeans發誓，有些人對IntelliJ IDEA發誓，有些人對Python發誓，而有些人對PHP發誓。

若是堅持這樣作，在某些商店中，您可能會失業：

public void hello()
{
   if (....)
   {
      ....
   }
}

問題全在於可見性和可維護性。

我沉迷於使用布爾代數來簡化和簡化邏輯以及使用狀態機。 可是，有些同事認爲我在編碼中使用「數學技術」是不合適的，由於它不可見且不可維護。 那將是一個壞習慣。 抱歉，我使用的技術對我來講是很是明顯和可維護的-由於六個月後我回到代碼時，我會清楚地理解代碼，而不會看到一團混亂的意大利麪條。

嘿哥們（就像之前的客戶曾經說過的）會作您想作的事情，只要您知道如何修復它，當我須要您修復它時便可。

我記得20年前，個人一位同事因採用今天稱爲敏捷開發策略的工做而被解僱。 他有一個細緻的增量計劃。 可是他的經理對他大吼：「您不能向用戶逐步發佈功能！您必須堅持瀑布式設計 。」 他對經理的迴應是，漸進式開發將更精確地知足客戶的需求。 他相信要開發知足客戶需求的產品，但經理相信要按照「客戶要求」進行編碼。

咱們常常因違反數據規範化， MVP和MVC界限而感到內gui。 咱們內聯而不是構造一個函數。 咱們採起捷徑。

我我的認爲PHP是很差的作法，可是我知道什麼。 全部理論上的爭論歸結爲試圖知足一套規則

質量=精度，可維護性和盈利能力。

全部其餘規則逐漸淡出背景。 固然，這條規則永遠不會消失：

懶惰是優秀程序員的美德。