03.06 什麼樣的代碼叫好代碼?

thfghfg


代碼的本質還要在機器上運行,好的代碼不單單的純粹的簡單的幾個字符的問題,好的代碼不僅僅是排版上或者語法上好看,還要能經過產品的測試驗證,這是評判代碼好壞的最準確的標準。不同水平的人對代碼的理解是不一樣的,現在就是三種水平的人分析對待代碼的不同態度,代碼能夠在表面上看到水準,深層次只能靠實踐驗證。

在初級程序員的眼裡代碼就是天了,能夠用代碼實現領導佈置的技術任務,就是最大的滿足了,幾乎所有的精力都在代碼上體現出來,拿到需求的第一時間就是會問自己代碼如何去寫,是不是會寫,如果不會寫該怎麼辦,這也是通常剛入門的程序員要克服的事情,這個階段對於程序員的要求過多也不是很現實,畢竟剛開始還在解決溫飽階段的時候,不能強求吃的非常奢侈,而且這個階段的程序員能夠實現一個基本功能就能獲得巨大的成就感,每個階段追求的層面不一樣,代碼的嚴謹程度實現方式等等都是存在巨大的優化空間,甚至還有一些廢物代碼都是存在的。

中級程序員已經能夠對代碼有基本的掌控能力了,拿到需求之後已經開始考慮用什麼方式實現起來更加穩定可靠,這個階段的程序員編碼水平屬於基本功能做的可靠紮實,已經能夠駕馭代碼了,拿到需求之後不是先問代碼如何實現,而是會從試下上看看有沒有更好的實現方式,絕大多數程序員屬於這個水準,基本上也會分成以下幾種情況,看到差不多的功能從網上找對應的代碼,看明白之後直接拷貝過來修改成適合當前框架的代碼風格,這個時候的程序員普遍上已經對編程有了感覺,覺得編程也就是這麼回事,很多程序員這個時候放鬆了對自己的要求,不像剛入行那種誠惶誠恐的樣子了,越是這個階段越是要保持一種前進的動力。因為很多年齡大的程序員後面跟不上節奏了,就是從這個階段開始的。

高級軟件工程師對於代碼的依賴性更少了,考慮不僅僅是實現功能問題了,拓展性兼容性以及跨平臺都是在考慮的範疇,甚至還會考慮輪子的使用是不是靠譜,還有再優秀點就考慮如何造輪子,即使造不出來也會嘗試去積累經驗,畢竟不是每個人都能有機會架構一個框架,但起碼在平時的工作過程中會一直準備著,所以等到有了機會之後緊緊抓住,現在能成為架構師的人基本上都是這麼出來的,說到代碼就會涉及到編程語言的範疇,編程語言也好代碼也好都是工具般的存在,工具就是為框架服務的,基本上這個層面的程序員是用這種方式對待代碼的。

當然基本的代碼需要好的規程規範,需要遵循基本的編程語法,起碼讓人能看懂,如果一個人寫的代碼只能自己看懂,這屬於比較失敗的程序員,越是複雜的功能通過代碼的實現變得簡單化,這才是程序員追求的目標,現在幾乎巨頭公司都有自己的編碼規範,就是制定一個統一的標準方便程序員去編程,對於代碼來講一年不懂可以兩年甚至三年早晚能夠搞明白。編程思想的錘鍊才是高手的晉級之路。

希望能幫到你。


大學生編程指南


編程界有句名言:“計算機程序是寫給人看的,只是順帶計算機可以執行”。程序易讀,沒有花架子、沒有不必要的提前優化,這是通用的原則。


但是在工程實踐上,什麼是好的代碼,取決於代碼滿足要的需求的領域。



上圖是一段摘自我個人項目的 C 語言代碼(業餘時間寫作,非公司資產),可以看到用到了各種教科書都極力反對的 goto 語句,但實際上,如果是 C 語言比較熟練的話,使用 goto 語句可以大大簡化函數返回時的清理代碼,達到類似 C++ 語言 RAII 的效果。


再舉個例子來說,當你的工作是實現一個被廣泛調用的庫函數,比如 C 語言 malloc 這樣的內存分配函數,那麼,速度和內存使用效率就是就是最大的需求,函數實現可以使用各種醜陋的優化技巧甚至內嵌彙編等等,但只要滿足基本需求,這些破壞基本可讀性原則的手段就不會影響你的代碼成為一段好的代碼。


在滿足需求的前提下,我認為好的代碼還符合以下特徵:


  1. 簡單性:能用簡單實現的方法就不要用複雜的方法,越簡單的代碼越容易維護;


  2. 可讀性:無論是作者還是他人,都能很容易通過閱讀代碼瞭解到代碼實現的功能,且代碼的編寫沒有違反常理的地方;

  3. 分層與模塊化:從架構的層面讓代碼易於理解與修改;

  4. 優雅與簡潔:代碼在滿足功能需求的情況下儘量採用成熟的算法與邏輯,舉個例子,計算從 1 加到 100 的總和,優雅簡潔的方法是使用等差數列公式求和而不是用循環累加;

  5. 效率:一般來說符合上面4條的代碼效率不會差,但也應把效率問題牢記在心,比如寫 Java 程序,如果遇到多次字符串相加的情況,隨時記得用 StringBuilder 來替換簡單的字符串連接。


以上是個人對好的代碼的幾點經驗,希望對大家有用。


命叔炸機


一段好的代碼,最少要遵守基本的編程規範,比如命名方式,注視等等,就拿變量名來說,必須讓人通過字面意思大概能知道這個變量是做什麼的,代表什麼意思,閱讀性要好,否則其他人看到代碼跟看天書一樣,完全不知道是在做什麼。同樣的,方法命名也是一個道理。

以下圖舉例來說,兩個方法都是檢查用戶名與密碼是否為空,但是第一個方法明顯規範於第二個方法,變量名就是賬號與密碼的英文單詞,一看就明白,而第二個方法以a,b,c來命名,沒人知道是啥意思,這種代碼是最差的。



allen5168


本人是軟件行業從業者,也經常考慮這個問題,正好借這個機會說一下個人的一些想法。個人認為好代碼,可能需要滿足一下一些條件:

第一,實現功能,我認為這也是最重要的。如果你寫的代碼連最基本的功能都沒實現,即使再漂亮再優雅,但一點實用性都沒有,這點不滿足的話,根本談不上好代碼。所以,我認為最大的質量就是實現功能,沒有實現功能,其他的都是白扯。

第二,排版合理。必要的縮進、換行、空行、空格和括號的對齊要合理,代碼有層次感。

第三、必要的註釋。類註釋,說明類的用途,類的作者,可能還有類的用法等說明。方法註釋,方法用途,方法作者,繼承說明,參數說明,返回值說明等等。變量註釋,主要說明變量的用途。代碼塊的註釋,簡明扼要的說明代碼的作用,讓其他人清楚明白。

第四、合理的命名規則。類的命名、方法的命名、變量的命名要有意義,易懂。

第五、編碼中需要注意的一些事項和遵循的原則。比如輸入流和輸出流的關閉,需要在finally中進行操作。比如在代碼中注意判空,防止NPE的出現。比如對大文件的處理,不要一下子讀入內存,防止內存爆掉。比如注意抽取常量,統一處理,便於維護。比如對異常,最好進行精細化處理,可針對不同進行不同操作等等。還有一些基本原則,比如單一原則,方法實現功能儘量單一。比如開閉原則,比如依賴倒置原則,比如接口隔離原則,比如DRY原則等等。

第六、設計模式的使用。合理的使用設計模式,可以減少你代碼的耦合度,提高代碼的擴展性,提高可維護性。另外,可藉助框架來減少你代碼的耦合度,比如我們經常提到的spring。

第七、合理的設計。進行必要的設計,但不會過度設計,讓代碼滿足當前的需求。好的架構一般是演化出來的,未必是一次設計出來的。


本人具有多年的java開發經驗,熟悉多種框架,熟悉網絡編程,熟悉java安全編程,熟悉大數據,熟悉多種安全協議,熟悉併發編程,有興趣的同學可以互相關注,互相學習!!!


代碼飼養員天齊


代碼的本質還要在機器上運行,好的代碼不單單的純粹的簡單的幾個字符的問題,好的代碼不僅僅是排版上或者語法上好看,還要能經過產品的測試驗證,這是評判代碼好壞的最準確的標準。不同水平的人對代碼的理解是不一樣的,現在就是三種水平的人分析對待代碼的不同態度,代碼能夠在表面上看到水準,深層次只能靠實踐驗證。

在初級程序員的眼裡代碼就是天了,能夠用代碼實現領導佈置的技術任務,就是最大的滿足了,幾乎所有的精力都在代碼上體現出來,拿到需求的第一時間就是會問自己代碼如何去寫,是不是會寫,如果不會寫該怎麼辦,這也是通常剛入門的程序員要克服的事情,這個階段對於程序員的要求過多也不是很現實,畢竟剛開始還在解決溫飽階段的時候,不能強求吃的非常奢侈,而且這個階段的程序員能夠實現一個基本功能就能獲得巨大的成就感,每個階段追求的層面不一樣,代碼的嚴謹程度實現方式等等都是存在巨大的優化空間,甚至還有一些廢物代碼都是存在的。

中級程序員已經能夠對代碼有基本的掌控能力了,拿到需求之後已經開始考慮用什麼方式實現起來更加穩定可靠,這個階段的程序員編碼水平屬於基本功能做的可靠紮實,已經能夠駕馭代碼了,拿到需求之後不是先問代碼如何實現,而是會從試下上看看有沒有更好的實現方式,絕大多數程序員屬於這個水準,基本上也會分成以下幾種情況,看到差不多的功能從網上找對應的代碼,看明白之後直接拷貝過來修改成適合當前框架的代碼風格,這個時候的程序員普遍上已經對編程有了感覺,覺得編程也就是這麼回事,很多程序員這個時候放鬆了對自己的要求,不像剛入行那種誠惶誠恐的樣子了,越是這個階段越是要保持一種前進的動力。因為很多年齡大的程序員後面跟不上節奏了,就是從這個階段開始的。

高級軟件工程師對於代碼的依賴性更少了,考慮不僅僅是實現功能問題了,拓展性兼容性以及跨平臺都是在考慮的範疇,甚至還會考慮輪子的使用是不是靠譜,還有再優秀點就考慮如何造輪子,即使造不出來也會嘗試去積累經驗,畢竟不是每個人都能有機會架構一個框架,但起碼在平時的工作過程中會一直準備著,所以等到有了機會之後緊緊抓住,現在能成為架構師的人基本上都是這麼出來的,說到代碼就會涉及到編程語言的範疇,編程語言也好代碼也好都是工具般的存在,工具就是為框架服務的,基本上這個層面的程序員是用這種方式對待代碼的。

當然基本的代碼需要好的規程規範,需要遵循基本的編程語法,起碼讓人能看懂,如果一個人寫的代碼只能自己看懂,這屬於比較失敗的程序員,越是複雜的功能通過代碼的實現變得簡單化,這才是程序員追求的目標,現在幾乎巨頭公司都有自己的編碼規範,就是制定一個統一的標準方便程序員去編程,對於代碼來講一年不懂可以兩年甚至三年早晚能夠搞明白。編程思想的錘鍊才是高手的晉級之路。


情感小小的世界


在我看來,好的代碼分成這幾個層次:

實現功能(需求)

單純的把需求實現,只能算“合格”的代碼,如果要成為(初級)好代碼,我認為還需要做到下面幾點:

  • 代碼的健壯性:需要多考慮規範要求以外的可能,我經常對組員說“不要相信別人,我們要把自己的代碼考慮全面”;比如開發一個接口,雙方已經約定某個字段是必傳的,那麼是相信對方系統會傳這個字段,還是“不要相信對方”,接口中增加非空判斷。

  • 代碼效率:在工作期間,我發現很多開發人員很容易犯的一個錯誤,就是隻關注功能的實現,而不會考慮代碼執行效率;例如測試環境數據庫中有一萬的數據,隨便寫個SQL也不會發生效率問題,但是生產環境一千萬的數據,代碼一上生產就會出現問題(項目最好能提供一個準生產環境,或者生產環境的試運行)。

讓別人能看懂

一方面,軟件開發需要團隊合作,另外一方面,程序員崗位的流動性比較強,可能兩三年過後,項目組成員已經完全換了一撥人了;所以代碼容易閱讀,是很重要的。

  • 遵守代碼規範:代碼分層、起名見名知意、代碼樣式等等;

  • 準確的代碼註釋,接口必須有接口文檔;代碼修改之後,對應的註釋和文檔必須也對應修改;

少些代碼

少些代碼不代表讓你偷懶,要想寫出【好代碼】,一定不能只【看到代碼】。

  • 深入瞭解需求,不合理的需求或者重複的功能,可以拒絕,或者給出其他的建議;

  • 設計和寫代碼的時間投入,一定要合理安排,甚至有些時候,設計的時間翻到更長;

  • 能複用的儘量複用,能抽象的儘量抽象,以便以後可以複用;

  • 如果有經過實際考驗的【輪子】,那就直接拿來使用;

  • 時刻要注意“過猶不及”:千萬不要學了什麼新的技術(框架、設計模式等),一定要用到項目中,而不是考慮是否合理,是否適用。

希望我的回答,能夠幫助到你!我將持續分享Java開發、架構設計、程序員職業發展等方面的見解,希望能得到你的關注。


會點代碼的大叔


關於什麼是好代碼,軟件行業爛大街的名詞一大堆,什麼高內聚、低耦合、可複用、可擴展、健壯性等等。

一、也就是所謂設計6原則 — 迪米特法則(最少知道原則) 加上 SOLID :

1、Single Responsibility (單一職責)

2、Open Close(開閉)

3、Liskov Substitution(里氏替換)

4、Interface Segregation(接口隔離)

5、Dependency Inversion(依賴反轉)

二、函數不易太長

如果太長(一般不宜超過200行,但不絕對),你自己都不太容易讀懂,請不要猶豫,分解成模塊函數吧。

假設你的項目中有三個不同的層——內層、中層和外層。你的內容不應該從中層和外層那裡導入任何東西。中層不應該從外層導入任何東西 ,這樣做的好處是,你可以對代碼的內層進行獨立測試

三、變量名、函數名稱、類名、接口等命名含義不清晰

函數名能讓人望名知義,看名字就知道函數的功能是啥,以至於幾乎不需要多少comments最好

四、學習習慣

1,先學習業務知識,分析業務,對自己的定位是業務領域專家,能快速通曉這個領域大部分的業務知識。

2,業務建模,抽象,能反映這個業務領域的各種變化。

3,只使用JDK進行編程,概念和抽象意義上的編程(算是:瘦核心/領域驅動/微內核模式的開發習慣)。

4,使用JDBC,JMS。。。。等框架,將概念具體功能和擴展落地


大黃哥兒


好代碼,滿足兩個條件:能實現預定效果、能被人容易看懂。

代碼的差別,不在於能否實現功能,更主要是實現的好壞。

有些代碼雖然實現效果了,但換個程序員就看不懂,無法維護,也是爛代碼。

現在的軟件業,程序員加班都是普遍現象,疲勞工作,勢必影響代碼質量。

大部分都在著急實現功能需求,完成領導安排的任務,只是以完成為目標。

這種不考慮長遠的工作方式,雖然短時間內達到了目的,但長期看問題很大。

程序員一旦離職,新來的需要花很久才能接手,項目的擴展性和穩定性都沒保證。

尤其一些外行的領導,一味地只知道做出來給上級邀功,不能科學的排期。

功能需求說改就改,新功能拍腦袋就來,導致項目設計不斷調整,損傷整體的架構穩定。

整個行業還沒意識到代碼質量的重要性,對代碼沒有敬畏之心,只看眼前不顧長遠。

只有行業人員達到飽和,把不合格的程序員和產品經理都淘汰下去,好代碼才能形成風氣。


臺哥彩鈴


面對這個問題,可能大多數程序員想到的是:高內聚,低耦合,可維護,易擴展。這些是對的,對於大部分IT從業者(尤其是剛入行,缺乏足夠知識和經驗的新人)來說,並不能通過一個具體的標準去衡量。

什麼樣的代碼才是好代碼?衡量代碼的好壞的指標或者維度有很多,比如性能好、架構好、高內聚等,這些指標的側重點各不相同,不同的開發人員的關注的重點也各不相同。

一方面是缺乏編程方面的經驗,在寫代碼時考慮的不夠全面,另一方面也有可能是需求的更改導致代碼的變動,這些都能影響代碼的質量,而代碼的質量會影響到產品的性能和好壞,接下來筆者與大家分享一些優質代碼的標準。

優質代碼就好比一本書,主旨貫穿全文,容易理解分章明確,要想寫出好的代碼,需要滿足以下標準:

1.明確性 ------ 代碼能夠做到不解自明。

2.可讀性 ------ 讓其它開發人員能夠看懂。

3.簡潔性 ------ 減少不必要的冗餘。

4.效率性 ------ 使代碼運行速度快。

5.維護性 ------ 容易修改升級。

一、代碼標準

1 明確性

明確性,質量較好的代碼,邏輯性相對比較的清晰,bug難以隱藏。要知道你所寫的每一段代碼是要幹什麼用的,有目的的去編寫程序,使程序整體有邏輯,在一些方法和屬性的命名時,儘可能的給予明瞭易懂的名稱,就像方法名採用動名詞組合一樣,從而提高可讀性。

2 可讀性

軟件開發往往不是一個人就能完成的,需要團隊的通力合作。可讀性,不只是你自己,還要讓其他開發、測試和運維人員能夠對所寫的代碼一目瞭然,儘可能的減少或不寫註釋。在出手之前先思考,不要寫出自己所不能理解的代碼,那樣只會加速系統的腐爛,做為一名程序員很有必要對自己所寫代碼進行思考和理解,從而對代碼進行整理提高簡潔性,好的代碼本身就是最好的說明文檔。

3 簡潔性

代碼中類和方法的長度要相對簡短,簡短的代碼活的更長久,沒有程序員不喜歡簡短的代碼,而且這樣出來的產品問題相對就會較少。

在一些方法中我們可能會遇到方法體過長的情況,一般來說高效的方法它的方法體不會過於太長,而太長的方法體,我們從中將其抽取分為兩個方法來進行調用,並且修飾符應該為private不能公開化,這樣做不僅能劃分業務邏輯,還能減少閱讀壓力,美化代碼,在下面樣例中如果不將方法體進行拆分,那麼代碼就會變得很臃腫,閱讀壓力大大增加,而進行規劃拆分後,就能很清晰明瞭的閱讀:

4 效率性

效率性,從一開始就要考慮程序性能,不要期待在開發結束後再做一些快速調整,在滿足正確性、明確性、可讀性等質量因素的前提下,設法提高程序的效率,在程序執行時讓代碼的執行速度較快,應以提高程序的全局效率為主,提高局部效率為輔。

5 維護性

所謂的維護性,就是指在系統發生故障後,在排查改正、改動、改進時的難易程度,維護性實際上也是對系統性能的一種不可缺少的評價體系。保證你所寫的代碼維護性相對較高,讓你和其他人修改起來比較簡單,而不是牽一髮而動全身。

6、命名

命名在一個項目工程中也影響著代碼的好壞,無論是包名、類名、方法名、變量名,命名的時候都應該考慮周全,實際開發過程中,我們的工程通常都會進行分包,其中一個功能模塊可能是一個或多個包組成的,這也就要求我們對包進行劃分同時還要規範命名

二、架構設計

1、代碼的高內聚

內聚是從功能角度來度量模塊內的聯繫,代碼關聯性比較強的代碼應該放在內聚在一起,形成一個獨立的功能模塊,可以是一個獨立的類,也可以是一個微服務。其實判斷代碼是否內聚一個比較簡單的方法就是看你能否給代碼或者服務給一個貼切的名字,如果代碼功能不內聚,我們是很難用一個簡短的名字來表示它的含義的。

2、代碼的低耦合

耦合性(Coupling),也叫耦合度,是對模塊間關聯程度的度量。耦合的強弱取決與模塊間接口的複雜性、調用模塊的方式以及通過界面傳送數據的多少。模塊間的耦合度是指模塊之間的依賴關係,包括控制關係、調用關係、數據傳遞關係。模塊間聯繫越多,其耦合性越強,同時表明其獨立性越差。

耦合比較高的代碼危害比較大,最常見的表現就是改一個模塊的代碼會影響許多其它模塊,最終必然導致大家不敢修改舊的代碼,只能不停的添加新的接口,系統的可維護性非常差。

三、好代碼好處

1.功能模塊相對完整獨立,實現的邏輯性清晰,可讀性強。

2.多人合作開發的分工更加明確,開發速度較快,同時軟件質量高。

3.可以將模塊公用接口提升,充分利用可以複用的代碼。

4.可維護性強,避免修改一處代碼牽扯許多模塊,容易控制。


IT老田


我是雪鹿,是一名科技領域創作者,希望我的回答可以對你有幫助。

什麼樣的代碼叫好代碼?

我認為要滿足三點要求就可以稱為好代碼。第一是能準確無誤的運行並且實現目標功能。第二就是一個實習生程序員都可以看明白的代碼。第三就是高效明瞭。雖然只有這三點,但是我覺感覺要求還是挺高的。

第一是能準確無誤的運行並且實現目標功能。

一段代碼,不能實現某一個模塊的功能,或者能實現,但是Bug一堆,問題一片,那可能不叫代碼,就是一堆垃圾。更別提是好的代碼了。

第二就是一個實習生程序員都可以看明白的代碼。

實習生程序員都能看懂的代碼,也就是新手都能看懂。這不僅要要求代碼排版合理,還要有關鍵的註釋,以及很好的命名規範。這一點也是非常重要的,尤其對於軟件企業而言,一款軟件絕不是一個程序員可以完成的,符合代碼規範,才能多人高效的協調合作開發完成軟件的開發。如果你寫出的軟件,別人都看不懂,變量的命名甚至還用a,b,c,或者中文的拼音,那就沒啥意思了。

第三就是高效明瞭。

之前我做開發的時候,看過一個工程,功能都挺好的,看了下代碼模塊,發現了一個重複運行10次的程序塊,然後上面就是複製了10遍的代碼塊。簡直爆炸,一個for循環不就可以了嗎。所以程序一定不要看起來像一個沒技術的寫的一樣,有時候申明變量沒有必要就不用申明,直接用現成的,算法結構能很優化,這樣才符合我對好代碼的要求。

最後總結:每個程序員都有自己的代碼風格,但是能保證簡單易讀,是基本要求,寫代碼時加上註釋,日後好維護,與人方便與己方便。

最後說一句,PHP是這個世界上最好的語言(評論區決戰到天亮)

以上是我對這個問題的解答和觀點,純手打,實屬不易,也僅表達個人觀點,希望能給讀者很好的參考,若是覺得寫的還可以就給個贊吧。


分享到:


相關文章: