|
| 您的位置: 首頁 > 網站資訊 > 函數(shù)要多小才夠好——談小函數(shù)之道 |
函數(shù)要多小才夠好——談小函數(shù)之道發(fā)布日期:2017/6/17
百度權重查詢 站長交易 友情鏈接交換 網站監(jiān)控 服務器監(jiān)控 seo監(jiān)控 “設計的函數(shù)往往比較小,而過大函數(shù)的設計往往烏煙瘴氣,或者存在很大的優(yōu)化空間。” 也許你認為討論函數(shù)的大小沒有需要,原因是函數(shù)設計的本質是內聚,它的大小只是它的體現(xiàn)形式。而上面的原因有需要讓我們討論一下函數(shù)的大小問題。 我對函數(shù)的核心思路:我提出代碼好小處理單元的概念:一個基本操作(賦值,比較等),一個函數(shù)調用(包括調用后判斷返回值進行判斷)都看成一個好小處理單元。那么,一個函數(shù),好小處理單元合理的個數(shù)范圍在7以內。假如超過了7,你就要考慮把他們拆分成多個函數(shù)了(為什么是7?人同時能夠處理的信息不超過7個)。 好小數(shù)目沒有限制,即便是只有1個,也有存在的需要。 在下面的情況下我會將函數(shù)拆分為更小的函數(shù): 1、一眼不能夠看到函數(shù)所有的代碼。 假如函數(shù)過長,無法一眼看到一個函數(shù)所有的代碼,我會毫不猶豫的拆分。我不想讓讀者去翻屏,也不想讓讀者前顧后盼,顧此失彼。漂亮的函數(shù)應該讓讀者一眼就知道他在做什么以及怎么做的。 2、局部變量過多。 假如局部變量超過七個,我會考慮拆分函數(shù)。變量過多意味著我要記錄太多的狀況,這會加重我大腦的負擔,同時要考慮太多的東西。這也同時意味著我可能沒有對函數(shù)功能進行深入的思考。 3、太多的縮進。 太多的縮進意味著太多的嵌套,要么是循環(huán),要么是判斷,都會導致復雜的邏輯。 4、假如你在使用ctrl+c和ctrl+v 那你寫的代碼不夠拽(DRY,Don’t Repeat Yourself)。這個時候,你要把你復制的部分拆分為新的函數(shù)。 5、不處于統(tǒng)一抽象條理。 舉例,有一個初始化函數(shù),需要初始化配置數(shù)據,套接字,數(shù)據庫連接,通道狀況。
上個函數(shù)中對所有通道的初始化一塊代碼就和其他的不處于一個抽象條理,我們應該將它封裝起來:
函數(shù)好小可以有多小,它存在的意義 我見過的好優(yōu)異的函數(shù):
這個函數(shù)很小,只有一行,但是他存在的意義在于:在函數(shù)的調用點,我們一眼就知道是獲取a和b中的好大值,而不是分析a > b?a:b的邏輯。這樣可以節(jié)省程序員的腦力成本,從而達到一個目的:漂亮的函數(shù)應該讓讀者一眼就知道他在做什么以及怎么做的。 小函數(shù)的好大障礙:性能 對于程序員新手,小函數(shù)的好大障礙在于沒有經驗體味不到小函數(shù)的優(yōu)勢,沒有經驗拆分大函數(shù)為更小的函數(shù)。 對于有一定經驗的程序員,小函數(shù)的好大障礙也許是對性能的憂慮。 對于性能,切記,不要過早優(yōu)化。我們一般認為的程序的,一般并不是程序的:我們需要工具來確定真正的所在,20%的代碼耗費了80%的性能,優(yōu)化之前首先要找到那20%的代碼。函數(shù)調用會產生資源和性能的損耗,但是這是不是程序的性能?消費的性能占總體的性能百分比為多少?這一切在代碼編寫時并不清楚,所以,我的觀點是寧可選擇簡短的函數(shù)來獲得清晰簡單的設計,以便在項目后期能夠更快,更好的進行性能優(yōu)化。 許多人都在質疑我上面列舉的max函數(shù)的實例,假如說他在運行期間調用次數(shù)不大,則對性能的影響基本可以忽略,而獲得的可讀性,清晰性這極具價值;反過來,假如他的調用次數(shù)是否重大,以致成為了性能的,則完全可以在程序編寫完成后,很快的用其他的方法優(yōu)化。程序的不會許多。 關于函數(shù)調用產生的性能消費,我會抽時間測試一下,看到底占用多少。 好后的建議: 在對新員工培訓的過程中,發(fā)現(xiàn)程序員新手一般對函數(shù)的大小不夠敏感。所以,我建議你可以多嘗試編寫10行左右(甚至更小)的函數(shù),慢慢你會發(fā)現(xiàn)小函數(shù)原來具有大威力。 文章來源:常高偉的博客 |
| 其他相關文章 |
|
|
|
|
|||||||||
| Copyright 2012-2025 上海蒙狼網絡科技有限公司 m.tzghgk.com All Rights Reserved |