我一直都聽說過單個(gè)出口點(diǎn)函數(shù)是一種不好的編碼方式，因?yàn)檫@樣會降低可讀性和效率。我從未聽說過有人在爭論另一面。我以為這與CS有關(guān)，但是這個(gè)問題在cstheory stackexchange上被否決了。
3 回答
烙印99
TA貢獻(xiàn)1829條經(jīng)驗(yàn) 獲得超13個(gè)贊
有不同的思想流派，這在很大程度上取決于個(gè)人喜好。
一個(gè)是如果只有一個(gè)出口點(diǎn)，那么它會減少混亂-您在方法中只有一條路徑，并且知道在哪里尋找出口。在不利的一面，如果您使用縮進(jìn)來表示嵌套，則代碼最終將大量縮進(jìn)到右側(cè)，并且很難遵循所有嵌套作用域。
另一個(gè)是您可以檢查先決條件并在方法開始時(shí)提早退出，這樣您就可以在方法主體中知道某些條件是正確的，而整個(gè)方法主體都不會向右縮進(jìn)5英里。通常，這可以最大程度地減少您需要擔(dān)心的作用域數(shù)量，從而使代碼易于遵循。
第三點(diǎn)是您可以隨心所欲地退出。在過去，這曾經(jīng)使人更加困惑，但是現(xiàn)在我們有了語法著色的編輯器和編譯器可以檢測無法訪問的代碼，因此處理起來要容易得多。
我正好在中間營地。強(qiáng)制執(zhí)行單個(gè)出口點(diǎn)是毫無意義甚至適得其反的限制，恕我直言，盡管整個(gè)方法中的隨機(jī)出口有時(shí)會導(dǎo)致混亂的邏輯難以遵循，在邏輯上很難確定給定的代碼是否會執(zhí)行。但是“控制”您的方法可以顯著簡化方法的主體。
慕哥9229398
TA貢獻(xiàn)1877條經(jīng)驗(yàn) 獲得超6個(gè)贊
我的一般建議是，在可行的情況下，return語句應(yīng)位于具有任何副作用的第一個(gè)代碼之前，或位于具有任何副作用的最后一個(gè)代碼之后。我會考慮類似：
if（！argument）//檢查是否為非null
返回ERR_NULL_ARGUMENT;
...處理非空參數(shù)
如果（確定）
返回0;
其他
返回ERR_NOT_OK;
比：
int return_value;
if（argument）//非null
{
..處理非空參數(shù)
..適當(dāng)設(shè)置結(jié)果
}
其他
結(jié)果= ERR_NULL_ARGUMENT;
返回結(jié)果；
如果某個(gè)條件會阻止某個(gè)功能執(zhí)行任何操作，那么我寧愿在該功能可以執(zhí)行任何操作的位置上方的某個(gè)位置早點(diǎn)退出該功能。但是，一旦函數(shù)執(zhí)行了帶有副作用的操作，我更愿意從最底層開始，以明確必須處理所有的副作用。
慕無忌1623718
TA貢獻(xiàn)1744條經(jīng)驗(yàn) 獲得超4個(gè)贊
單一入口和出口點(diǎn)是結(jié)構(gòu)化編程與分步Spaghetti編碼的原始概念。人們認(rèn)為，多個(gè)出口點(diǎn)函數(shù)需要更多代碼，因?yàn)槟仨氝m當(dāng)清理分配給變量的內(nèi)存空間?？紤]一種情況，其中函數(shù)分配變量（資源），并且過早地退出該函數(shù)并且沒有適當(dāng)?shù)那謇頃?dǎo)致資源泄漏。另外，在每個(gè)出口之前構(gòu)造清理將創(chuàng)建大量冗余代碼。
- 3 回答
- 0 關(guān)注
- 732 瀏覽
添加回答
舉報(bào)
0/150
提交
取消