寫(xiě)好代碼的10個(gè)技巧2017-09-04 15:18程序設(shè)計(jì)

　　《h2》寫(xiě)好代碼的10個(gè)技巧《/h2》《blockquote》 《p》原文：《a href=“https://cdiggins.github.io/blog/programming-tips.html”》10 Tips for Writing Better Code《/a》 《br》 作者：Christopher Diggins 《br》 譯者：Teixeira10《/p》 《/blockquote》《p》【譯者注】在本文中，作者介紹了10個(gè)寫(xiě)好代碼的建議，以自己切身編寫(xiě)代碼的體會(huì)和經(jīng)驗(yàn)來(lái)告訴開(kāi)發(fā)者這10個(gè)建議的好處，并指導(dǎo)讀者成為一個(gè)優(yōu)秀而高效的程序員。 《br》 以下為譯文：《/p》《p》那么怎樣才可以使代碼變得優(yōu)秀呢？《/p》《p》好的代碼可以被認(rèn)為是易于閱讀、理解、調(diào)試和修改的，而且最重要的是很少有缺陷。顯然，編寫(xiě)良好的代碼需要花費(fèi)更多的時(shí)間，但從長(zhǎng)期看會(huì)有更多的價(jià)值，因?yàn)榫S護(hù)和重用代碼的成本會(huì)變的更低?！?p》《p》事實(shí)上，我們可以將好代碼與可重用的代碼等同起來(lái)，這是許多技巧背后的統(tǒng)一原則。作為一個(gè)開(kāi)發(fā)特定功能的程序員，代碼可能會(huì)實(shí)現(xiàn)你的短期目標(biāo)，但是如果沒(méi)有其他人想重用它的話(huà)（包括你自己），那么它一定是有缺點(diǎn)的，要么它太復(fù)雜，要么太具體，而且很可能在不同的情況下崩潰，從而導(dǎo)致其他程序員不相信這些代碼?！?p》《p》我發(fā)現(xiàn)，嘗試將下列最佳實(shí)踐應(yīng)用于你所編寫(xiě)的所有代碼（包括你的實(shí)驗(yàn)和原型代碼），可以讓你寫(xiě)出更好的代碼，而不用考慮你的經(jīng)驗(yàn)水平?！?p》《h3》1. 遵循單一責(zé)任原則《/h3》《p》在程序員的代碼庫(kù)中，函數(shù)是最重要的抽象形式。可以重用的代碼越多，編寫(xiě)的代碼就越少，它們的可靠性也就越高。遵循《a href=“https://en.wikipedia.org/wiki/Single_responsibility_principle”》單一責(zé)任原則《/a》的小功能代碼就更有可能被重用?！?p》《h3》2.最小化共享狀態(tài)《/h3》《p》你應(yīng)該最小化函數(shù)之間的隱式共享狀態(tài)，無(wú)論它是文件作用域變量還是對(duì)象的成員字段，都支持顯式的值作為參數(shù)。當(dāng)代碼明確了該函數(shù)需要什么來(lái)產(chǎn)生期望的結(jié)果時(shí)，代碼就變得更容易理解和重用?！?p》《p》這種情況下，你應(yīng)該優(yōu)先選擇靜態(tài)無(wú)狀態(tài)變量，而不應(yīng)該選擇對(duì)象上的成員變量?！?p》《h3》3.本地化的副作用《/h3》《p》理想的副作用（例如：控制臺(tái)打印、日志記錄、改變?nèi)譅顟B(tài)、文件系統(tǒng)操作等等）應(yīng)該放在單獨(dú)的模塊中，而不是分散在整個(gè)代碼中。功能上的副作用常常違反單一責(zé)任原則?！?p》《h3》4. 優(yōu)先使用不可變對(duì)象《/h3》《p》如果一個(gè)對(duì)象的狀態(tài)在其構(gòu)造函數(shù)中被設(shè)置一次，并且再也不會(huì)發(fā)生變化，那么調(diào)試就變得容易得多了，因?yàn)橐坏?gòu)造正確，它仍然有效。這是減少軟件項(xiàng)目復(fù)雜性的最簡(jiǎn)單方法之一?！?p》《h3》5.多用接口少用類(lèi)《/h3》《p》使用接口（或在C++中使用模板參數(shù)或概念）的函數(shù)比在類(lèi)上運(yùn)行的函數(shù)更容易被重用?！?p》《h3》6. 將好的原則應(yīng)用于模塊《/h3》《p》尋找機(jī)會(huì)，將軟件項(xiàng)目分解為更小的模塊（例如：庫(kù)和應(yīng)用程序），以鼓勵(lì)模塊級(jí)的重用。模塊的一些關(guān)鍵原則是：《/p》《pre》《code》1.依賴(lài)最小化 2.每個(gè)項(xiàng)目都應(yīng)該有一個(gè)明確的功能 3.不要重復(fù) 《/code》《/pre》《p》你應(yīng)該努力使你的項(xiàng)目小而明確。《/p》《h3》7. 避免繼承《/h3》《p》在面向?qū)ο?a target='_blank' class='arckwlink_none'>編程中，特別是在虛函數(shù)中，繼承在可重用性方面往往是一個(gè)死死穴。我?guī)缀鯖](méi)有成功地編寫(xiě)或使用那些能覆蓋類(lèi)的庫(kù)?！?p》《h3》8. 在設(shè)計(jì)和開(kāi)發(fā)過(guò)程中進(jìn)行測(cè)試《/h3》《p》我并不是測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的鐵桿擁護(hù)者，但隨著開(kāi)始編寫(xiě)代碼，測(cè)試代碼會(huì)自然而然地遵循許多指導(dǎo)原則。它還可以幫助我們更早地發(fā)現(xiàn)很多錯(cuò)誤。但是，要避免編寫(xiě)無(wú)用的測(cè)試代碼，良好的編碼意味著更高級(jí)別的測(cè)試（例如：集成測(cè)試或單元測(cè)試以及功能測(cè)試），而且在揭示缺陷方面更有效。《/p》《h3》9.優(yōu)先選擇而不是手寫(xiě)標(biāo)準(zhǔn)庫(kù)《/h3》《p》我無(wú)法告訴你我多久才能見(jiàn)到一個(gè)std：：vector 或std：：string更好的聲明，但這幾乎總是浪費(fèi)時(shí)間和精力的。除了顯而易見(jiàn)的事實(shí)，你正在引入一個(gè)bug（參見(jiàn)技巧10），其他程序員不太可能重用你的代碼，因?yàn)檫@不是那些被廣泛理解、支持和測(cè)試的代碼。《/p》《h3》10. 避免編寫(xiě)新的代碼《/h3》《p》這是每個(gè)程序員都應(yīng)該遵循的：“The best code is the code that isn’t written”（最好的代碼是不用被復(fù)寫(xiě)的代碼）。你擁有的代碼行數(shù)越多，你的缺陷就越多，發(fā)現(xiàn)和修復(fù)bug的難度就越大。《/p》《p》在編寫(xiě)一行代碼之前，問(wèn)自己，是否有一個(gè)工具、函數(shù)或庫(kù)已經(jīng)完成了你所需要的工作？你真的需要那個(gè)功能而不是調(diào)用另一個(gè)已經(jīng)存在的函數(shù)嗎？《/p》《h3》最后《/h3》《p》編程是一種非常類(lèi)似于學(xué)習(xí)的一種藝術(shù)形式或一種運(yùn)動(dòng)的技能，通過(guò)用心練習(xí)，不斷地從別人那里學(xué)習(xí)，才會(huì)編寫(xiě)的更好。不斷提高代碼質(zhì)量將有助于你成為一個(gè)更高效的程序員