建站
咨詢
售后
建站咨詢
新聞中心
「代碼寫得好」是對(duì)機(jī)器學(xué)習(xí)研究者及開(kāi)發(fā)者比較好的贊揚(yáng)。其第一層意思是說(shuō)，你的模型非常好，有自己的理解與修正;第二層意思是說(shuō)代碼的結(jié)構(gòu)、命名規(guī)則、編寫邏輯都非常優(yōu)秀。
網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)建站！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、小程序開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了石林免費(fèi)建站歡迎大家使用！
我們?cè)?jīng)將寫代碼比喻成寫文章：不僅需要有一個(gè)主旨，告訴別人代碼的作用是什么，同時(shí)還應(yīng)該在精煉與易讀之間做權(quán)衡。代碼過(guò)于精煉，整體邏輯難以跟隨，代碼過(guò)于易讀，整體就顯得比較臃腫。
在精簡(jiǎn)與易讀之間做權(quán)衡，第一種方法根據(jù)列表推導(dǎo)式能獲得更精簡(jiǎn)的代碼，但第二種方法更易讀。
如果說(shuō)到什么是好代碼，我們肯定都能說(shuō)出一堆規(guī)則，例如使用一致的格式和縮進(jìn)、使用清晰的變量名和方法名、在必要時(shí)提供文檔與注釋、不要過(guò)度精簡(jiǎn)代碼等等。
但是對(duì)于什么是爛代碼，你有比較清晰的認(rèn)識(shí)嗎?
在 GitHub 上有一個(gè)新項(xiàng)目，它描述了「最佳垃圾代碼」的十九條關(guān)鍵準(zhǔn)則。從變量命名到注釋編寫。這些準(zhǔn)則將指導(dǎo)你寫出最亮眼的爛代碼。
為了保持與原 GitHub 項(xiàng)目一致的風(fēng)格，下文沒(méi)有進(jìn)行轉(zhuǎn)換。讀者們可以以相反的角度來(lái)理解所有觀點(diǎn)，這樣就能完美避免寫出垃圾代碼。
項(xiàng)目地址：https://github.com/trekhleb/state-of-the-art-shitcode
當(dāng)然，以下十九條垃圾代碼書寫準(zhǔn)則并沒(méi)有面面俱到，如果讀者們發(fā)現(xiàn)有一些難以忍受的爛代碼習(xí)慣，也可以留言發(fā)表你的看法。
第一條：打字越少越好
如果我們鍵入的東西越少，那么就有越多的時(shí)間去思考代碼邏輯等問(wèn)題。如下所示，「Good」表示遵循該規(guī)則的示例，Bad 表示沒(méi)遵循該規(guī)則的示例。
第二條：變量/函數(shù)混合命名風(fēng)格
我們需要混合命名方法與變量，這樣才能體現(xiàn)命名的多樣性。
第三條：不要寫注釋
反正代碼都看得懂，為什么要寫注釋?或者說(shuō)，反正沒(méi)人看我的代碼，為什么要寫注釋?
第四條：使用母語(yǔ)寫注釋
如果你違反了第三條規(guī)則，那么至少寫注釋需要用你的母語(yǔ)或者其它語(yǔ)言。如果你的母語(yǔ)是英語(yǔ)，那么你也算違反了這條規(guī)則。既然編程語(yǔ)言絕大多數(shù)都是用英文，那么為什么不用其它語(yǔ)言注釋一下?
第五條：盡可能混合不同的格式
同樣，為了代碼的多樣性，我們需要盡可能混合不同的格式，例如單引號(hào)或雙引號(hào)。如果它們的語(yǔ)義相同，那就應(yīng)該混用。
第六條：盡可能把代碼寫成一行
如果一系列參數(shù)與方法都是一起實(shí)現(xiàn)的，那么代碼也要寫在一起。
第七條：發(fā)現(xiàn)錯(cuò)誤要保持靜默
當(dāng)你發(fā)現(xiàn)某些錯(cuò)誤時(shí)，其他人不需要了解它，因此不需要打印出日志或 Traceback。
第八條：廣泛使用全局變量
使用全局變量，是面向「全球化」不可或缺的部分。
第九條：構(gòu)建備用變量
以防萬(wàn)一，我們需要?jiǎng)?chuàng)建一些備用變量，在需要時(shí)隨時(shí)調(diào)用它們。
第十條：Type 使用需謹(jǐn)慎
一般不要指定變量類型或者經(jīng)常做類型檢查，無(wú)類型才是最好的類型。
第十一條：準(zhǔn)備「Plan B」
你需要準(zhǔn)備一些運(yùn)行不到的代碼(unreachable code)，它們可以作為你的「Plan B」。
第十二條：嵌套的三角法則
如果代碼有一些嵌套結(jié)構(gòu)，或者說(shuō)縮進(jìn)空行的結(jié)構(gòu)，三角法則是最漂亮的。
第十三條：混合縮進(jìn)
我們需要避免采用縮進(jìn)，因?yàn)榭s進(jìn)會(huì)使復(fù)雜代碼在編輯器中占用更多的空間。如果一定要采用縮進(jìn)，那么就使用混合縮進(jìn)策略。當(dāng)然，這種策略在 Python 中是行不通的，因?yàn)樗靠s進(jìn)來(lái)確定代碼結(jié)構(gòu)。
第十四條：不要鎖住依賴項(xiàng)
每一次要安裝新庫(kù)時(shí)，更新已有的依賴項(xiàng)。為什么要維持之前的版本呢，我們需要時(shí)刻保持最新的第三方代碼庫(kù)。
第十五條：長(zhǎng)函數(shù)比短函數(shù)好
不要將程序整體邏輯分割為一些代碼塊，要是 IDE 突然不行了，它找不到必要的文件或函數(shù)怎么辦。因此把代碼寫在一個(gè)主體函數(shù)中，并且不再維護(hù)額外的函數(shù)導(dǎo)入或代碼文件，那么這樣的方法是最穩(wěn)定的。
單個(gè)文件一萬(wàn)行代碼是沒(méi)問(wèn)題的，單個(gè)函數(shù)一千行代碼也是沒(méi)問(wèn)題的。
第十六條：代碼不需要做特定測(cè)試
這些測(cè)試通常是重復(fù)且無(wú)意義的工作。
第十七條：盡量避免重復(fù)代碼
按你的想法寫代碼，尤其是在小團(tuán)隊(duì)中，畢竟這是「自由」準(zhǔn)則。
第十八條：構(gòu)建新項(xiàng)目不需要 README 文檔
在項(xiàng)目前期，我們可以暫時(shí)保持這種狀態(tài)。
第十九條：保存不必要的代碼
在寫代碼的過(guò)程中，經(jīng)常會(huì)產(chǎn)生很多測(cè)試代碼。這些代碼也是非常重要的資料，因此不能刪除掉，最多只能注釋掉。
網(wǎng)頁(yè)標(biāo)題：寫出一手爛代碼的19條準(zhǔn)則
標(biāo)題URL：http://www.5511xx.com/article/cojipid.html
