建站
咨詢
售后
建站咨詢
新聞中心
清楚你的優(yōu)先級(jí)
代碼的寫法有很多種：有的運(yùn)行起來很快，有的只會(huì)占用少量?jī)?nèi)存，有的更容易測(cè)試，而有的代碼則有很高的可讀性。
蘄春網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)公司,蘄春網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為蘄春上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的蘄春做網(wǎng)站的公司定做！
若要編寫思路清晰的代碼，第一步就是要將可讀性放在第一位。
這也意味著勢(shì)必要降低其他因素的優(yōu)先級(jí)。如果把所有因素都作為最高優(yōu)先級(jí)，就意味著沒有優(yōu)先級(jí)。
培養(yǎng)清晰的意識(shí)
想要寫出好代碼，首先要知道什么才是好代碼，想要寫出思路清晰的代碼，也要了解什么才是思路清晰。多閱讀一些質(zhì)量上乘的代碼可以讓我們對(duì)好代碼有個(gè)大概的認(rèn)知。
了解什么才是優(yōu)秀代碼并不能杜絕我們繼續(xù)寫出糟糕的代碼，但至少能讓我們知道代碼的哪里不對(duì)勁。
修訂
編寫代碼時(shí)，我們最初所想的思路未必清晰。在大多數(shù)情況下，只有在第一次完成代碼后，我們才能找到更適合的思路。反復(fù)閱讀已完成的代碼才會(huì)帶來更改的空間。
從解釋開始
如果我們還搞不清代碼結(jié)構(gòu)，那么可以試著想象一下怎樣向他人解釋清楚或者把邏輯思路寫下來，比如“如果刪除賬戶，那么我們需要跳過 xxx。如果 xxx 的進(jìn)程還沒有結(jié)束，那么……”。然后把這套邏輯翻譯成代碼就很順了。
寫程序時(shí)，帶入人類溝通方式而不是計(jì)算機(jī)中的抽象概念要更容易。
注釋
代碼中的注釋可以解釋某段代碼的用處，或者是程序結(jié)構(gòu)為什么要這么寫。
單單是閱讀程序并不會(huì)告訴我們作者所想就是正確的邏輯。里面可能會(huì)有我們不了解的商業(yè)規(guī)則：美國(guó)境外的用戶有時(shí)會(huì)把街道名寫到地址欄第一行的最末尾。里面也可能有一些技術(shù)小技巧：以某種奇怪的方式構(gòu)造查詢，從而讓 Postgres 正確地優(yōu)化它。諸如此類的代碼細(xì)節(jié)，都是只有了解邏輯背后的背景情況下才能徹底明白為什么要這么寫的。
代碼不會(huì)說話。如果我們決定跳過某些步驟，但又懶得留下注釋解釋為什么，過兩天再回來看這段代碼恐怕就真沒人知道你當(dāng)時(shí)在想什么了。
部分代碼可能讀兩遍就能想明白個(gè)中緣由，但為了保險(xiǎn)起見，還是不要給自己的大腦添加不必要的負(fù)擔(dān)。
不要搞混層次
不要搞混函數(shù)中的抽象層次。
這段“歡迎”代碼層次混亂：
- def welcome(self):
- results = db.query(
- 'SELECT EXISTS 1 FROM emails WHERE kind = ? AND user = ?',
- 'welcome_email', self.user.id,
- )
- if results[0]:
- return
- self.send_welcome_email()
這段則是相對(duì)整齊的：
- def welcome(self):
- if not self.has_sent_welcome_email():
- self.send_welcome_email()
函數(shù)中混亂的抽象層次會(huì)讓讀者思考代碼用途和實(shí)現(xiàn)方式時(shí)被迫進(jìn)行思維跳躍。當(dāng)前抽象層次的代碼告訴我們代碼在做什么，而下一層次的代碼則是關(guān)于代碼要如何實(shí)現(xiàn)的。
在例子里的“welcome”函數(shù)中，我們首先在數(shù)據(jù)庫中查詢是否有過往郵件記錄，如果沒有則發(fā)送一封歡迎郵件。請(qǐng)注意，第二個(gè)版本中的“welcome”函數(shù)將查詢部分放到了另一個(gè)函數(shù)中，“welcome”中僅僅關(guān)注“做什么”，這就是將函數(shù)中的抽象層次保持在了同一層，邏輯也更加清晰。不同函數(shù)分散在不同抽象層次，將較低層次的實(shí)現(xiàn)細(xì)節(jié)委托給較低抽象層次的函數(shù)。
分解函數(shù)
有時(shí)，分解大體積函數(shù)到子函數(shù)會(huì)更便于閱讀。
對(duì)于分步驟執(zhí)行的函數(shù)，將函數(shù)中的每個(gè)步驟都分解成子函數(shù)效果會(huì)更好。而對(duì)于其他如決策類的函數(shù)，不同的決策會(huì)引向不同的函數(shù)：有的部分負(fù)責(zé)制定決策，有的則是負(fù)責(zé)執(zhí)行決策。分解函數(shù)的方法有很多種維度，只有通過不斷的練習(xí)才能一眼看穿哪種才是正確的。
小體積函數(shù)有以下幾點(diǎn)好處：
- 每一部分的邏輯都有自己函數(shù)名。知道每一塊邏輯負(fù)責(zé)什么更方便我們找到這些函數(shù)應(yīng)當(dāng)被放在哪
- 作用域中變量更少
- 在運(yùn)行堆棧軌跡和調(diào)試時(shí)能更清晰地看出函數(shù)的作用
- 小型函數(shù)可以被單獨(dú)測(cè)試
其實(shí)，沒有任何函數(shù)計(jì)算機(jī)也能運(yùn)行得好好的，函數(shù)的存在只是為了服務(wù)于程序員，所以還請(qǐng)多多利用它們。
不要分解函數(shù)
不要重復(fù)你自己(don't repeat yourself, DRY)的意思經(jīng)常被過度解讀。
如今，抽取魔法數(shù)常量，以及針對(duì)某類特定決策的邏輯副本，已經(jīng)算是公認(rèn)的標(biāo)準(zhǔn)答案。此類重復(fù)的代碼的確不好。而 DRY 的過度解讀是指面對(duì)區(qū)區(qū)兩行的重復(fù)代碼，便如臨大敵恨不得除之而后快。完全避免任何的重復(fù)代碼意味著我們最后將面對(duì)一堆毫無意義、令人迷惑的代碼，其存在只為了防止程序中的兩三行重復(fù)代碼。再加上由于在邏輯上毫不相干的兩段代碼被迫捆綁在一起，代碼也更加難以修改。
判斷一段代碼的重復(fù)是否可容忍很簡(jiǎn)單：修改 A 段代碼，保留 B 段不變，如果程序報(bào)錯(cuò)，那么就把 A 和 B 整理到同一段代碼;如果無事發(fā)生，那么就放著別管。DRY 并不代表我們需要手動(dòng)壓縮代碼庫，而是為了避免兩段代碼要依賴于手動(dòng)的同步。請(qǐng)記住，重復(fù)代碼和抽象創(chuàng)造并不是同一件事。
避免使用可配置函數(shù)
寧可要十個(gè)零參數(shù)的小函數(shù)，也不要一個(gè)帶十個(gè)參數(shù)的函數(shù)。
諸位對(duì)類似的事一定不陌生：初始干凈的函數(shù)，只在三個(gè)不同的地方被調(diào)用。而當(dāng)我們想要在第四處調(diào)用時(shí)，我們需要做一點(diǎn)小的調(diào)整，添加一個(gè)參數(shù)。但這樣第一個(gè) caller 就多了一個(gè)新功能，也需要多添加兩個(gè)可配置的參數(shù)。等到第五個(gè)用例，我們還要再為它添加獨(dú)特的參數(shù)，以此類推。但反過來我們就又會(huì)發(fā)現(xiàn)第二個(gè) caller 跑起來太慢了，所以只好再添加另一個(gè)參數(shù)來跳過部分繁瑣的程序。
不知不覺中，我們那個(gè)干凈整潔的、只負(fù)責(zé)一件事的函數(shù)現(xiàn)在有了五個(gè)配置參數(shù)，現(xiàn)在能做的事情甚至可以達(dá)到 2 的五次方種!
這種情況下，將這一整個(gè)復(fù)雜的函數(shù)拆分成子函數(shù)，每個(gè)函數(shù)只負(fù)責(zé)各自的事就會(huì)好上很多。
但這樣以來，又不可避免會(huì)出現(xiàn)重復(fù)。當(dāng)這些重復(fù)的部分需要保持同步時(shí)，我們可以利用 DRY 的思路，將相同的部分抽取到子函數(shù)中。這時(shí)，做決策和考慮步驟就會(huì)容易很多。
請(qǐng)記住，區(qū)區(qū)幾行重復(fù)代碼是沒問題的!像是在不同 list 上跑 for 循環(huán)的代碼，這類就是可以接受的重復(fù)。
這種方法的好處之一是當(dāng)其中一個(gè)用例被刪除時(shí)，你可以輕松刪除掉對(duì)應(yīng)的函數(shù)，而不是在復(fù)雜函數(shù)的邏輯里掘地三尺試圖找到對(duì)應(yīng)的選項(xiàng)。只關(guān)注某個(gè)特定函數(shù)的讀者也會(huì)更容易理解它們的用處。
(注意，當(dāng)你能負(fù)責(zé)所有的 caller 時(shí)，這種方法才是正確的。如果你的函數(shù)只是公共 API 的一部分，那么請(qǐng)不要考慮使用這種方法。因?yàn)槟悴⒉磺宄械挠美际鞘裁矗膊恢牢磥頃?huì)有什么樣的用例)
不要過早地進(jìn)行優(yōu)化
競(jìng)速賽車跑得比普通轎車要快，這點(diǎn)毋庸置疑。但這也是賽車在犧牲了柔軟座椅、低噪音，以及車載空調(diào)的條件下。如果我們的程序不需要做競(jìng)速賽車，那就不要過早地拆掉空調(diào)。逐漸熟悉程序的構(gòu)造，先從編寫易于人理解的代碼開始，不要一上來就試圖挑戰(zhàn)計(jì)算機(jī)的運(yùn)行速度。
同理，也不應(yīng)過早開始泛化。沒人會(huì)在不需要處理大量物品的時(shí)候就買入一輛自卸貨車，在沒有過多需求的時(shí)候，我們也不用提前編寫多余功能的代碼。
名稱欄目：怎樣寫出可讀性高的代碼？
文章出自：http://www.dlmjj.cn/article/djepseg.html
