我個人的方法與變數取名經驗

少用Filter這方法名稱,是Filter掉什麼?留下什麼?
Filter約定成俗,常見是有保留的意思。
其實可以用其它單字,如select等等。
避免用filter
filter(year>2011)
是選取還是排除?常代表的是選取比較多
如果是選取,可以用select,如果是排除,可以用exclude

閉區間的方法or變數:用first,end來取名
半開放區間的方法or變數:用begin,end來取名
區間,如一個方法叫getRange(2,4)
到底是會抓出2,3,4,還是2,3?
通常若是抓出2,3,4的,叫閉區間 ,會用first與end
若是2,3,叫半開放區間 ,會用begin與end, 表示有起點,而不會含終點

來Size取名不好,是指什麼的大小?
delay可以改成delay_secs
size可以改成size_mb
limit可以改成max_kbps
時間最好加上單位,大小最好加上mb,kb,bytes等

像gettime,到底回傳是秒還是毫秒?
gettime_ms就又更好

password,可以改成plainttext_password
html_utf8,有編碼
但不應該所有的變數都要補上_utf8,在容易被誤解的地方補上。

我曾見過
avail,valid充滿了整個class,
當這兩個單字放在同一class,真的容易誤解。

無意義的縮寫
BackEndManager改取作BEManager,
Workspace縮寫成WS只縮寫成這樣可以減少它的困擾嗎?
連函數都不註解。自己發明一些奇怪的縮寫,
讓程式看起來神密兮兮的用處是什麼
讓別人覺得自己很厲害?
這些程式設計師背後的心態是什麼?

快速區分出是成員變數還是全域、區域變數。
成員變數的前綴字可以補個m,或是_

未處理的補上raw

一字多義。
!right是代表?不對,還是不是左邊?

clip(string str,int length)
到底是從尾端刪除length還是
只留最尾端的資料?

length到底是bytes數量,還是字元數量?還是單字數量?

有邊界的值,如你限定超過十項要有警告。
就要寫好max_xxx。
讓人一清楚看見此變數有極值。

布林值前面可用前綴字
is, has,can,should

bool read_pawword=true;
到底是需要讀,還是已讀完?

避免否定敘述
如 bool disable_ssl
而該用bool use_ssl=true。

通常人會預期get與size是輕量級的方法,應該幾秒鐘就回覆。
c++在非常早期的list容器有個關於size的問題。
當時size調用時,並不是個常數。
而真的把list串列整個走完。
當不是個常數時,應該要加上動詞,如寫成countsize,
現在的c++的list的size的複雜度現在已經是O(1)

—————註解—————–

好程式> 壞程式+註解

讓變數名稱本身就是註解。
變數名字取好就不用註解。

程式的文化是會漫延的,不註解,大小寫隨便,一堆val。
但漂亮的程式碼會有啟發性,還會激發別人去改善自己的程式碼

註解:想像讀者需要知道的東西。
註解要有價值。不要註解能很快從程式碼知道的事實。
有些不要註解,直接改掉名稱。
不要用註解補救不好的名稱。
函數名稱就要說明函數的意圖,self-documenting。
好的函數名稱比好的註解更為重要

導演評註:director commentary。
記下寫程式時重要的想法

少了註解,讀者可能會害怕改動雜亂的程式碼。

FIXME,已知的問題
HACK:承認解法方式不夠優雅
XXX:危險
TODO:作者未處理的部份
todo:小寫,小問題

註解常數為何會是特定數值的原因
設了一個莫明奇妙的常數在其中,卻沒有說明
//經實測多次調整,這效果最好
image_quality =0.72
應該要這樣註解,
而不是莫明一個常數在那裡

廣告

我自己的寫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順序描述這會造成困擾。

我自己的寫Code美學_Part1

一些新技術像是深度學習或是BigData,
一堆公司就跟青少年在宣稱他們的性經驗一樣,
每個人都在談,每個人都宣稱自己做了。

要成為一個專家要花一萬個小時,
但要沈浸進入心流的才算,頻繁中斷的時間要在這一萬個小時的範圍中剔除。
魔術數字,一萬個小時。
每天8小時是
10000/8
Ans = 1250
Ans/365
Ans = 3.424657534
快4年,而且是專注且有效的練習。
是"自己"練習。而不是丟給前輩叫他們解。
不只重覆一遍又一遍,還要嘗試做出超出當前能力的任務,
事後分析自己的表達,並修正錯誤。
練習不單是做擅長的事,還有做自己不擅長的事。

程式碼的壞味道,寫到一定程度就會有這感覺。
壞掉的程式碼是有異味的。

過度複雜與高度耦合的區段,都是一個個骯髒的程式碼炸彈。
炸開後,犧牲品就是時程。
當意外遇見骯髒的程式碼要估出合理的時程將會變的異常困難。
而超出時程付出的代價是信譽。
公司輕視信譽,哀哉,這是台灣軟體業的通痛。

刪code是不是寫程式的一種?
寫的少,維護的也就少,出現bug的地方也就少。
多寫出來的東西,別人都要花時間讀,應該要刪除。
留住能夠剛好把工作完成的code。
額外多出的變數要刪除
刪掉那些用不著的全域變數。
簡單是因為刪簡。

是誰把糟糕的程式設計師找進來?
良好的程式碼並不會憑空冒出來。
差強人意的程式設計師與偉大的設計師之間的差異是:態度。
與心態有關。
假如你不關心同事,也就懶的在程式碼中寫下清楚的註解。
同事是看你的code來決定對你的看法。
不在乎別人對你的看法?
原來是讀了阿德勒被討厭的勇氣,而打算實作啊!

不要寫只看似能運作的程式碼
但若要趕時程就都是那種code的型態。

無論何時,接觸到一塊code,
要盡所能在離開這區段時,讓它變得比當初發現它時還要來的更好。
更好的結構,更好的命名,更好理解。

寫出code那些省下來的時間,
是為了讓我可以更多時間陪孩子,
或做我自己想做的事。
結果…又在休息時間寫code。
假鬼假怪的自己。

奮力解決一個難題,以為別人應該要連讀程式碼時也該這麼難理解與難維護。
甚至是讀的人是六個月後的自己。
不是這東西困難。
而是寫的人沒有在替後來讀碼的人想。
所花費心思所寫的每一行程式碼,都代表給一封將來給其它人看的訊息。
解釋給另一個聰明的人聽,說明是怎樣解決這棘手的問題。
在未來,有人看見這段code說,太棒了,我完全可以理解這code所完成的事情,
它是設計是如此優雅,充滿了解題的美感。

如果連簡單的事情都做不好,拼字錯誤,按鈕設計錯誤。
人家還信賴這軟體嗎?

如果code需要註解來解釋,請考慮重構到它不需要註解。
註解只註高階意圖。

單位上的錯誤。
1999年火星氣候衛星,軟體錯誤。
基地的軟體以磅為單位,但太空船使用牛頓。

限定user輸入範圍,以及預設值,避免錯誤。

有時候,解決問題的方法是放下滑鼠出去走走

要加強程式設計能力,實在用不著多讀一本書,而是去讀source code。

從中"犯錯",從錯誤中吸取經驗,得到比閱讀技術書籍所無法傳遞的體會。

看完航海相關電影不代表你就會航海了

有些程式碼留住的話,
會導致那些細小怪異的程式碼缺乏清楚的目標。

不能用一個按鈕評估事件複雜度。
google首頁只有一個按鈕。

手中的工作完成度有90%,但無盡的卡在10%的除錯。擁有的進度並不是90%,而是沒有完成。
除錯可以學習,但整個專案沒有進度。
修bug沒有進度,提升只有你自己。
沒有"能見度"的進度,等於沒有進度
我曾遇到開發報表不填的。
故意不填開發進度,讓它不可見。
隱藏自己的能力不足,避免被人知道超時了。
不填時間管理,就可以不讓別人or自己,知道逾時了。

每次Code Review時,一定讓它比之前好一點。
每次把檔案開啟來,多少要改善程式碼
或許只是改變數名稱,或是將過長的方法拆成兩個。
只是像上完廁所要洗手,垃圾要丟垃圾筒一樣的好習慣而已。

不要拿自己的時間去證明 , svn會出錯,編譯器會出錯,
不如好好找出自己程式上的錯誤
去除那些不可能發生的,剩下的即使再不尋常,那也是真相。
曾遇見一個菜鳥,三不五時就在擔心svn會出錯。
其它人已經開始動作寫程式了,他還在把專案另外複製出一份來,
只敢寫在另外複製出來的那一份,等自己覺得沒問題時,再合併程式碼…
我制止他這種浪費時間的開發方式,他回說:他這是謹慎。
…你弄出的bug遠遠還比svn多。
公司不是有筆試有面試嗎?誰面試這傢伙且又讓他進來的?

花在讀code的時間比寫code的時間多
要花時間取好命名,因為它才能清楚表達出它的行為。
上一個花括號{與下一個},要在一個螢幕的距離內,
腦海裡可以保存更少的狀態。
程式碼方法,行數的上限是一個螢幕的距離。
這與人的認知能力有關。

盡量避免全域變數。
方法的參數的上限是4個,多的話,盡量整合成一個物件。
傳遞資訊越少,需要推論的也越少

避免先叫getter,再做物件工作。
物件應該本身自己判斷。
直接要求物件工作,而不是先幫物件判斷。

程式碼,應該是對下一個接手的程式設計師表達它自己。
可以把很難的東西簡化才是高手。
把難的東西寫的很醜,不是高手,這是在假冒高手。
這行因平庸的居多,為了不想承認自己的平庸,
面試時只會出了一些怪題目想考倒別人。
寫程式時,連註解也不寫。
面試官啊!誰又是你當時的面試官?

何時不寫註解也是技巧
程式碼已經說出的,用自然語言再說一遍不會增加事情的正確性與真實感。
註解掉的程式碼也不能執行,為何還要放在其上
應該把註解當程式碼,每段註解,都要給閱讀者價值,
沒有價值,就是浪費,應該刪除or重寫
註解應該說出程式碼表達不了的
與其為糟糕的class or方法註解,不如直接更名。
與其為一個函數中的大區段註解,不如抽出成獨立的方法。

如果方法中有And要注意。
因為你合併了兩個事。
這應該要拆開。

有些例外是客戶端設計師的錯,破壞了方法的合約,
是呼叫者自己要檢查的,合理的回應,就是拋出例外。

對於自己的東西,不要怕弄壞。
別人的東西,則要小心別弄壞 。最好別去重構別人的東西。
不要自大到認為你比他厲害。
若這人還在公司,就別重構他的東西。
你可以做的事絕對很多,因畢竟那已穩定運行了。
只能改自己的程式,
不然弄壞了還要想辦法救回別人的程式。

懶惰,但是是聰明的懶惰,不寫垃圾。

從遠處看任何事都很簡單。
沒有開發經驗的經理會認為程式設計師的工作很簡單
沒有管理經驗的程式設計師也會認為經理做的事很簡單
沒有積極參與開發的事,你就會以為事情很簡單。
像魔法一般的完成,且魔法持續在發生。
不要低估別人要做的事。
也不要低估程式的困難度。

寫程式最困難的部份是"思考",最難被人看見。
思考看起來與發呆同表情。

DRY。Don’t repeat yourself。
DRY若是在DB的話,就是正規化
開發人員辨別出有程式碼在重複用,這就是經驗了。
清除重覆的程式碼,可以讓你得到經驗。
重覆就是在浪費,因為每一行都需要維護,
重覆只是毫無必要的膨脹了程式碼,當未來有bug時,每個都要修一次。
增加了複雜度。

只給User少數選擇。
開出來的選擇與功能,都是將來要去維護的。

靠魔法coding的程式設計師,怎麼壞的不知道,壞了也不會修,
有遇見過有程式設計師連何謂好,什麼叫有執行正確也不知道。

大量的if then else
之所以會大量產生是因為封裝被破壞了!

浮點數不是實數!
實數是連續不斷、沒有縫隙,而浮點數"精度有限",所以浮點數不是實數
浮點數彼此間的分佈也不是均勻的
浮點數會有捨入誤差
浮點數是用在科學運算,不是在用金融運算。
金融c#要用decimal
二進位沒有辦法精確表示小數,所以才會有"不同精度"的浮點數型別

當API暴露自己,違反了封裝原則,重構就也痛苦。
API若讓User能繼承就會很麻煩,有些物件不能由外部建立物件。

菜鳥亂問問題,提問題時也不說自己的測試路徑與當時的使用情境,
期待一個魔法師出現。

高手是多年來專注於學習與"精煉思維"的過程。
高手其實就是擁有無窮好奇心的聰明人
跟比你聰明的人共事的時候,做好打雜的工作,提供充份的"情境脈絡",
讓他有效率的發揮技巧。
但要庸材承認另一個人比他聰明是困難的,庸材反倒有著更多的驕傲。

在程式領域,有些人努力加班,僅是欺騙自己與同事,
讓人相信花了很長時間在辦公室,就代表為專案做了許多貢獻。
事實上,少做一點貢獻度可能更高,不可能坐滿8小時後,還能思考複雜的東西。
與其3個小時的加班,說不定早點回家,休息一下,明天早上可能只花1小時就解決了。
八小時之後已經沒有什麼生產力了。
努力過頭反而是成效不彰。
寫code不是短期衝剌。
但老板卻認為加班才是認真。
腦外科醫生每周60小時都在開刀,飛行員每週飛六十小時?
工作前的準備與教育還是他們職業的核心。
尋找聰明的工作方法。超過每周60小時,代表你沒生產力。
但在台灣?既然被叫鬼島是名符其實的。

除非是開發嵌入式,不然我自己認為學vim,
真的是蠻假鬼假怪的一種行為。
用vi耶!啊不就好棒棒。

你是程式設計師,不是使用者,不要假裝你是使用者

先懷疑client端的設定

在自己寫的範圍中別怕弄壞東西,別人已寫好,正常運作的,
不要自大的想替他重構。

下班不開機

在做好與快速做完之間選擇,一堆擱置下來的問題,就成了技術債
儘快償還技術債,否則將因"草率的行為"嘗到苦果。

怒氣

意識到自己心理的長期狀態竟是"生氣"

比較多的時候是充滿了怒氣,
因為…時間不為我掌控。
要去哪,不為我掌控。
在家裡,想看個書、想看個電影不停被中斷。
一部影片要分4次看,要融入電影中情感時又被中斷。
不想參加的家庭聚餐得參加。
工作上,也不停被中斷,連個google都不想用的菜鳥,
也都可以輕易中斷我手邊的工作。
時間不停被拿走,留給自己的時間是這麼少。
因為時間一直被拿走,而充滿怒氣,
想要有更多自己時間所以晚睡。
但越晚睡,越是莫明的怒氣油然而生。
那些怒氣,又無從發洩。
隱而未現,無從疏通的怒氣,導致我自己想跟自己為難。

下坡請打低速檔

下阿里山一路上都有這下坡請打低速檔的標誌。
每台車低速檔的英文代碼都不一樣吧!
我怎知低速檔對應我的車縮寫是DS?
低速檔到底是哪一檔啊!我都開自排了,代表我開車技術普普,
也不是很想了解那麼複雜的東西。
其實可以多寫一下坡打空檔可能會害死你
差點用生命記下下坡請打低速檔是指DS。

Folder Marker移除後,造成資料夾Icon消失

Folder Marker是套將OS預設的資料夾Icon改變顏色的軟體,但將之移除後,

原始OS的資料夾Icon反而無法顯示。

到下列兩個機碼位置,刪除 Folder Marker的相關機碼值,再重開機即可。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\Shell Icons
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\explorer\Shell Icons

匯出幾百MB的Log中的特定區段

反正寫Log只是浪費硬碟空間,多寫避免到時有問題找不到原因。

但有時log太大,需要切割。這批次檔可以幫你匯出特定哪行到哪行的資料即可。

當你log有800mb,你只需要其中6mb來看,就可以使用這工具。

log小小的話,直接開記事本看就可以了吧!

下載點

很簡單,都只是調用一些Linux平台常見的工具而已,感謝這些好心人,將它們移值到Win平台。

要怎樣開百mb的log檔?有個叫emeditor的可以解。