我自己的寫Code美學_Part2

只提供給User一條路徑而不是三四條捷徑選擇。

風格之美、和諧、優雅與節奏取決於簡約。
code要有難以琢磨的美感,美感則是來自於"簡約"。
美麗的程式碼有許多相同特性,首要共通點就是簡單、簡約。
美,在簡單之中誕生,在簡單之中發現。
優雅解法,代表需要創造力。
漂亮的程式碼,應該是賞心悅目的。
寫程式比較多的時間是花在讀碼上,能越快讀懂,就越容易使用。
讓程式碼"美觀",做這件事的同時,常常不單只有改善表面,也會改善整個程式結構。
是一種編排的美感,與一致性。

只寫需要的功能。
可讀性最高的程式碼—就是完全沒有任何程式碼。

就算原本程式碼很醜,它也已經通過了測試與審查,
留住舊程式碼有其必要性,有些已歷經數年的測試,
隨便改寫,可能會造成莫明的bug出現。
不要未經考慮就拋棄"舊"程式碼。
結構與風格、自以為寫的比前一位好、新技術的出現都不該是重構的理由。

除非新的語言與框架可以顯著的提升功能,可維護性或生產效率,否則保持原狀。
新的程式碼不一定比舊的好,舊的也不一定落後。

隱藏不重要的細節。
程式設計師說話若太瑣碎,就是太多細節。

若參數是數值就要考慮到邊界值,負值,極大值,極小值,兩個相同值,0

“醜" 的程式碼。
要能辨別"醜"的程式碼與能跑的程式碼,
醜的code通常帶有隱藏的問題。

開發時間寶貴,讓code可讀性高一點是對別人的體貼。
程式碼在於"可讀性","易於理解"。
“縮短理解時間"是重點
而這個別人常常也是半年後的自己。

先解決問題,再改善效能,
優化都是放最後才在做的事。

無法用口語說明遇見的問題或是設計,
可能就是有遺漏某些東西,或是有問題還未定義。

程式設計師常高估自己的能力,低估bug處理的時間。

常見一些程式碼那種寫出來感覺就沒有打算要後續維護。

園丁常會修剪枝芽讓植物更加著壯更有生命力,
修剪用不到的程式碼也會持續影響後續的程式碼。

我曾經看過有一般的應用程式試圖在處理記憶體不足,
那應該是OS要處理的才是吧!
一般寫應用程式的為什麼要處理?
應該要直接顯示messagebox,優雅的讓程式關閉。
加了一堆code,試圖從ram不足中恢復,但恢復後呢?
實際上還是不足啊。

花時間研究一下git for win,可以免除蠻多需要撰寫程式碼的時候。

一個方法解一個問題。若一個方法在解兩個問題,另一個要抽離成為獨立方法。
這是為了讓程式碼重複利用。

等需求確定才開始動作,因為需求常再變。
倒是可以先寫那些需求怎樣變,都一定會用到的底層方法。

複雜的迴圈、大量的變數,都會增加心理負擔,需要更多思考,記憶更多變數才能理解。
當有大量心理負擔的程式碼,代表更易忽略其中的bug,更難以修改。

? : 三元運算子,看情形用,有時反讓程式碼難讀。
要把全部塞同一行。
而且也難以在除錯器中單步執行。

少弄do while,因為讓讀碼順序變的詭異,
讀碼是由上讀到下的。
“條件式"應該列在最前面,
若非必要避免使用do while。

方法盡早return。可以讓程式碼更簡單。
迴圈的話,就盡早continue;

太大塊的程式碼,{ }應該是一個螢幕的範圍。
因人一次只能思考三到四種東西。程式碼越大塊,越難消化。

Don’t repeat yourself。

減少全域變數。變數存活範圍越大,就必須記得越久。
變數越常"改變",越難記得目前數值。
若是常數就用常數,因為不可變的比較少風險。

100行可讀性佳的程式碼,比50行混亂艱澀難懂的code還好
縮短其它人理解程式所需的時間,比減少程式碼行數還好,
比較短的code不一定比較好。

理解程式碼,別人才能修改,找bug,快速知道它是怎樣與其它程式碼互動。
但多數的程式設計師的心態是,不在乎別人懂不懂,我是唯一用的人。

說明變數的目的,可以更容易抓到蟲

如果程式某個地方以ABC順序描述,
在另一個地方,若改以BCA順序描述這會造成困擾。

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s