Mystic Pieces

繼 [軟體開發] 淺談軟體開發 再接著聊聊軟體工程師如何面對這一片困境，從一個最小的面向談起 ― 自己。

條件式是程式中常見的描述句，但對於難以一眼看懂的描述邏輯無疑是增加了閱讀的困難。

人腦的暫存記憶區是有限的，當 Function 中的判斷式越「巢」，對於閱讀就更具負擔。排版上也不好看，這是應當避免的情況。此篇列出一些不佳的情況，以及提供一些避免的手段以供參考。

眾觀而言，程式碼是否好閱讀，編排、排版佔了相當大的份量。此篇列舉一些項目，提供各位參考。

沒有什麼可以比一段放對位置的註解，更能提供助益。沒有什麼可以比一段無聊教條式的註解，更能弄亂模組。也沒有什麼可以比一段陳舊而混沌不清的註解，更能傳播傷害性的謊言及提供錯誤的資訊。

曾經我以為註解多多益善，然而在閱讀完這些書籍及課程後顛覆了我原有的認知。

這又是另外一個有趣的問題，在我腦海裡，不知道哪來的錯誤認知，曾經以為只有在該段程式碼被重複使用時，才會被擷取為 Function。然而，在 Clean Code 的世界中，擷取 Function 對於改善程式碼的可讀性，是一個非常重要且必要的方式。我摘取了幾項重要的準則。

這是寫程式最基礎也最困難的問題...先撇除英文單字詞彙不足的問題，單單在命名的原則上就有很多值得注意之處。

此系列文為閱讀完 「Clean Code 無瑕的程式碼  -- Robert C. Martin (Uncle Bob.)」及 Udemy 課程 ―「C# Developers: Learn the Art of Writing Clean Code  -- Mosh Hamedani」，再加上一些團隊內部分享後的心得整理，請各位多多指教。