#純靠北工程師4ml
----------
4la 又來挑戰中文了。其實傳統行業發生得比較多吧。

同事：a>b>c>d. 我是c.
a: 又有破圖了。d 說他沒改 url，please fix. 不過現在 x 總在觀賞中，你先別碰。
c: (*看了 prod server) d 你昨晚有在改？
d: 有呀, ab 有叫我改, 我改了
c: ab 有檢查過？
d: 應該有吧。
c: 你 commit push 上去，我看一看 commit log.
c: (*看了 commit log) 那 url 不就是有改掉...
d: 喔。
c: b, 昨晚你們有叫 d 改 prod server? a 剛在找我，說到好像有事發生了，我一臉慒逼...
b: 他應該沒改吧
c: 看看 commit log 和 debugger 吧...
b: (*看了 commit log)(*看了 debugger)(*搭不通a)那先在 prod server 改吧
c: a 剛跟我說要中午才可以改
b: 喔。

如無意外劇本應該是 goto 1. a 叫 b 「叫 d 幫 c 做事」的方式真是奇特。c 太懂事了。
----------
💖 純靠北官方 Discord 歡迎在這找到你的同溫層！
👉 https://discord.gg/tPhnrs2

----------
💖 全平台留言、文章詳細內容
👉 https://kaobei.engineer/cards/show/5997

[熱門文章] 程式設計、重構、與其它任何東西的終極問答

"The Ultimate Question of Programming, Refactoring, and Everything"
網頁版： http://goo.gl/6jIcIp
PDF 版： https://yadi.sk/i/pBZqebxsr5Wyg
#Craftmanships #SoftwareEngineering #CPP #Refactoring #ProgrammingSkills

好的！遲交比不交好，今天的推薦文來了（笑）～

今天介紹這篇，是過去一個禮拜在國外鄉民聚集地 Reddit 程式設計版瘋傳的文章。標題很臭屁「The Ultimate Question of Programming, Refactoring, and Everything」（沒錯！我就在意它最後一個字 "Everything"。咬我啊！ XD）。因為轉載的人實在太多，讓我不禁努力地把它看完了。

其實這篇文章講的是 C/C++ 程式寫作者應該注意、或建議遵守的 42 個小訣竅。既不「Ultimate（終極）」，也不是涵蓋「Everthing」。不過裡面還是有不少中肯的建議，所以我還是將它介紹給大家。

為了讓英文苦手的朋友也能稍微感受一下這篇文章在講什麼，所以我不負責任地快速翻譯了每個標題一下。如果對哪個主題有興趣的，就麻煩大家直接對照標題號碼去看原文解說。原文有些標題用「戲謔」或「隱晦」寫法，我若直接翻譯，大家可能不知道原作者想表達什麼。所以我會將某些標題，用比較易懂的中文重新表達。一切以「標題編號（1~42）」為準。

接下來就請享用我這個不負責任的翻譯了。有會錯原文意思的，還請各位留言在下方、然後鞭小力一點 XD。我會馬上修正的：

1. 不要去做編譯器會做的事情
如：用迴圈能存取 a[0] ~ a[9]，就不要用「拷貝貼上」a[0], a[1], a[2]..., a[9] 來存取裡面的內容值。

2. 大於 0 不代表它等於 1
若文件告訴你某函數執行成功會傳回「大於0」的值、但目前這個大於0的值是「1」。請你寫程式的時候不要自作聰明地偵測「傳回值 == 1」當成成功，請乖乖遵照規格書用「傳回值 > 0」等於成功。因為將來的版本有可能還會傳回 2, 3...等其他值。

3. 當你拷貝貼上一段程式碼，記得檢查它的副本兩遍
有時候你拷貝貼上一段程式碼，會忘了去修改裡面一些不同的小數字，導致花了大把時間去檢查錯誤到底出現在哪裡。

4. 小心使用「? :」運算子。並記得多加括號
「? :」是 C/C++ 內常用的運算子。若您寫了一段這樣的原始碼「a - b?0:1」，您可能以為它是這樣運作的「a - (b?0:1)」，事實上，它是這樣運作的「(a-b)?0:1」。結論是，多加括號保平安。

5. 多用市面上有的工具來分析您的原始碼
市面上有些工具，如：原始碼靜態分析工具、原始碼排列工具...可以幫您在把原始碼送入編譯器前，就抓到錯誤。不過作者也提到，別以為倚賴這些工具，錯誤就不會發生。真正要減少錯誤還是得靠多讀規格書，增加程式寫作經驗才辦得到。

6. 確認您所有的指標，都已經轉型成整數型態
作者擔心，某些使用 64 bits 當成指標變數寬度的系統，到 32 bits 的機器內重新編譯時，會產生高位元組被截斷的慘劇。某些編譯器提供「uintptr_t」這個專門給指標變數使用的型態，會隨著編譯器所在的環境，自動調整指標寬度。

7. 別在迴圈內呼叫「alloca()」這個函數
萬一迴圈失控，alloca() 函數會霸佔大量記憶體無法釋放。建議事先在迴圈外霸佔一大塊足夠的記憶體，然後在迴圈內慢慢蠶食之。

8. 在「解構函數（Destructor）」內使用「例外處理（Exception）」是很危險的！
作者認為，在負責釋放記憶體、收尾等工作的解構函數，還去霸佔新記憶體作事情是不好的。若真的發生例外（Exception），直接「吃掉（Supress）」不要讓它出現在使用者面前可能還比較好。

9. 若你要比對字串結尾，請用 '\0' 代表
有些程式設計師因為 '\0' 其實就是數字 0，而在比對字串結尾時，直接使用 0 來比對字串結尾。作者認為這個習慣不好。

10. 請勿濫用 # ifdef
# ifdef 很好用，但很容易讓原始碼雜亂難讀。作者不會建議大家不要用，但他反對連可以用 if ~ else 解決的場合，都濫用 # ifdef。

11. 別把一堆運算子全都擠在同一列
多分成幾列，Debugger 可以比較容易指出發生錯誤的是在哪個環節。

12. 當你「拷貝貼上」程式碼時，特別注意「最後一列效應」
作者還是不太建議濫用拷貝貼上，他認為需要重複使用一段程式碼，不如好好考慮寫成稍有彈性的函數，然後重複叫用。此外，他建議大家去看「最後一列效應」這篇文章（連結在本文），並了解最後一列效應在拷貝貼上程式碼內，所扮演的角色。

13. 程式碼若很長，盡量多折幾列，然後排成像表格般一樣整齊（Table-style）

14. 好編譯器 + 好的寫碼習慣是不夠的
內文舉了個後括號「)」括錯位置，但編譯器抓不出來的例子。

15. 若有一堆意義相關的常數，請用 enum 括住它們

16. 「看我能把程式碼寫得這麼屌！」的炫耀寫碼心態不可取
寫程式碼要以「穩」「易讀」為主，不是把一些剛學不久，覺得很酷，但三個月後會忘個精光的技術用進程式碼內。

17. 想用程式碼把一塊資料清乾淨，最好把清除程式碼獨立拉出來成一個專屬函數
18. 你在一個語言行得通的方法，在另一個語言不一定行得通
19. 盡量用技巧避免在同一個類別內，建構函數彼此呼叫的情況
20. 讀檔時，只檢查有沒有讀到檔尾（EOF）似乎是不夠的
21. 正確檢查 EOF 的方法
22. 有比使用 # pragma warning(...) 來印錯誤訊息更好的方法，勿濫用
23. 如果你想取得字串長度，用函數自動幫你算，別用手算然後硬填數字上去
24. 請多使用 "override" 與 "final"，它們會是你的好朋友
25. 別再把 "this" 指標跟 "nullptr"（空指標）拿來作比較
26. 小心使用 VARIANT_BOOL 這個陰險狡猾的東西
27. BSTR（Binary STRing）這個用於微軟 COM/Automation 技術中的資料型態，請小心使用
28. 能用函數把一段程式碼包起來重複用，就別用巨集包它（使用巨集函數的缺點多於優點）
29. 在迴圈或迭代程式碼間，使用 ++i，來取代 i++（i++ 編譯後的執行效能稍微差那麼一點）
30. wprintf() 函數的使用陷阱：Win32 印寬字元字串要用 %S（大寫），Win64 要用 %s（小寫）。
31. 陣列在 C/C++ 傳給函數時，並非是「傳值呼叫」（Call by Value）
32. 要把檔案內的文字直接印在螢幕上時，請不要直接使用 printf() （怕檔案內夾雜 % 開頭的字，這些字對 printf 是有特殊意義的）
33. 想對一個指標取值（亦即：*p），記得檢查它是否為 NULL。否則你對 NULL 取值會導致系統出錯的
34. 別以為 int 的上限 21億+ 很多，在 64 bits 系統中，這個數字很容易爆掉
35. 若您把 enum 常數與 switch~case 連用，增加新元素進 enum 時也別忘了加新 case 進 switch
36. 如果有怎麼抓都抓不出來的 bugs，記得往「記憶體」的方向去思考（32bits vs. 64bits 之類的問題）
37. 在 do~while() 內用 continue 指令要小心，有可能會跳過你放在底部的「更新條件」，導致無窮迴圈
38. 對於指標，請用 nullptr 代替 NULL，這是新的 C++ 規格書希望您遵循的
39. 試著別把一列式子搞得太複雜，這樣比較不會有「咦？為何這段寫錯的程式碼居然可以運作」的問題出現
40. 開始使用「原始碼靜態分析工具」吧！
41. 別為了要使用某函式庫的一個函式，而引進整個函式庫。如果只用了一個函式，建議自己寫比較容易維護。
42. 別再用 empty 這個曖昧的字眼當函數名稱了。用 erase(), clear() 都比 empty() 好。

如果您覺得小弟翻譯了這麼多，沒有功勞也有苦勞，那就麻煩按個讚犒賞小弟一下吧！當然歡迎轉發給您 Facebook 的朋友共同討論。最後提醒一句，上述 42 點別把它們全都當聖旨，親身體會驗證才是最重要的喔！

祝福大家假期愉快！

【攻城這回事：看別人的自學程式語言經驗分享的心得】

剛才在 Inside 硬塞的網路趨勢觀察 看到這篇文章，裡面說到這一段：

「看看我身邊的同事們，他們幾乎很少因為語法錯誤、打錯字、漏了個符號這種小事而卡關，因為他們的 IDE 都先把這些錯誤抓出來了；當遇到問題掙扎幾分鐘還解不出來時，他們會直接把問題丟給朋友，互相幫忙 debug；在開發程式時，他們總是在對方的位子隨性的來來去去互通有無。」

其實我還滿慶幸我出社會第一份工作寫的是 C#。我覺得 MSDN 真的整理得很好，無論是中文化程度或是排版、範例的豐富程度，我看官方文件與範例程式就能寫得出些什麼，再加上 Visual Studio 也是一套非常好用的 IDE，讓我的初學過程如魚得水。

加上我有許多在本行的學長姐同學學弟妹，可以一起在當時還很健壯的 MSN & Skype 上一邊說垃圾話靠腰工作環境一邊討論遇到的 bug 要怎麼解，比起單打獨鬥的學習，我工作的前幾年的確在這種互動中獲益不少。

後來在寫 PHP 時，一開始我用 Eclipse + Zend debugger，剛開始還覺得滿順利，但是不知道是專案越來越多還是怎麼著，Eclipse 一天到晚卡住、掛掉，花太多時間重新啟動 Eclipse 或等待，讓我覺得好不耐煩，我現在都是 VIM 加上比較土法鍊鋼的 debug（看 log 或 dump error message）。

有些資深社群也讓我不太習慣。我剛出社會時還是可以在網路上發菜鳥文的生態，現在大家都會用不太友善的語氣指責新手不夠用功、沒有先爬文⋯⋯但是大家一開始都很順利嗎？我一開始也是和那些新手一樣呢，連自己的問題在哪都搞不清楚！

如果剛畢業第一份工作就是寫 PHP，不知現在的我會是如何？如果一開始寫 C# 就像當時我遇到的一些人一樣，用 Notepd++ 硬寫，那又會是如何？會學得這麼開心、覺得寫程式這麼好玩嗎？

另外文章裡提到，「一名真正優秀的軟體工程師，他的知識領域應該是『T』字型的 —— 對任何領域都稍有涉獵但至少在某一方面專精到底。」理想上是這樣啦但是我覺得工作不免就是一直⋯⋯要涉獵你工作要你涉獵的內容啊！就像被抓去當客服沒時間寫程式了，也就要開始練話術，電話狂響的時候很難把程式語言技能繼續點到滿啊！XD