Unity C# | Clean Code #3 註解
一、前言
這篇文章將會分享 Clean Code 關於註解的重點，內容主要以個人閱讀後心得為主，有興趣了解更多請自行購買這本書。
二、Clean Code
這本書出自於某一位程式設計的大師，他為程式設計建立了一個程式設計的流派，Clean Code 對每一位程式設計師的意義都不盡相同，對某些人來說，這是維護、命名的準則，對某些人來說，則是程式開發的架構與雛形。
1. 簡潔
這本書最為著名的就是簡潔，簡單扼要的程式邏輯、清楚易懂的程式設計知識與架構，這是它廣為流傳的核心守則，這本書不會實際教導如何寫程式，它會把寫程式要注意、要避免的事情一步步告訴設計師。
2. 直覺
其中最重要的一件事情，是Clean Code 強調程式是一種語言，因此在撰寫裡面的每一個字都要設計與思考，就像寫一本書一樣，要能讓人一看就懂，不需要經過轉化或推測，能很直覺的就理解程式碼的內容，因此也容易維護。
3. 零重複
它的一項特徵是程式碼不會有重複的內容，同一功能的程式寫完之後就不用再撰寫第二次，能讓程式碼的數量大為減少，重複利用的同時依然保持單一職責的設計模式。
三、註解
學習程式碼的過程中，自然而然的就學會了註解；在很多插件裡面也能看到註解；那我們應該怎麼使用註解比較好呢？
1. 不要替糟糕的程式碼寫註解──重寫它
我們決定對程式碼註解的原因，很有可能是我們擔心程式碼太亂，容易讓下一位讀者看不懂這段程式碼在寫什麼，因此我們添加了一個註解，告訴他們這段程式碼的一些備註。
寫程式像寫文章一樣，如果覺得看不太懂，重寫就對了；不要為了文章寫不清楚而註解，我們應該直接重寫一遍，直到我們覺得這段文章直接看就能理解功能，不需要額外備註。
2. 有益的註解概述
真正有意義的註解，剛好是那些有實際意義的註解，它們會向文章本身，缺少就會有一種空缺感，而不是缺少後依然能順利讀下去；我會挑選幾個我認為對寫程式有幫助的註解類型跟大家分享。
3. 糟糕的註解概述
有些註解去掉之後，對程式碼內容並無顯著影響；有些註解被撰寫後，反而影響程式碼的閱讀；這些註解都對程式碼都沒有正向效益，因此都是不應該存在於程式碼的內容。
四、有益的註解
有必要才要註解，因此有益的註解就是那些絕對不能少的註解。
1. 法律型註解
你可能有看過法律型的註解，它會告訴你這份程式碼腳本是來自於哪家公司所設計，請不要隨意的轉載或修正等等，總之就是告訴你這份程式碼的智慧財產權歸屬。
法律型註解是概念意義上的重要，實際上對寫程式碼沒有幫助，就像是申請商標一樣的概念，是一種對自己的保護，所以這種註解該寫還是要寫，雖然我們普通程式設計師應該不會接觸到就是了。
2. 對後果的告誡
某一些程式的存在很便捷，但不可挽回；某一些程式的效用很特殊，不能隨便亂使用；某一些程式的功能會在某些狀況銷毀；類似上述的程式碼，我們都應該要在前面註解，告訴未來的使用這這個程式碼的危害。
3. TODO註解
善用尚未存在的程式碼，或者說我們未來打算這樣做的程式碼，都很值得使用ＴＯＤＯ來註解，現在程式編輯器都能使用搜尋來找到所有的ＴＯＤＯ程式碼了，不過要記得隨時更新。
五、糟糕的註解
有哪些程式碼註解是「糟糕」的程式碼註解呢？
1. 喃喃自語
我相信有些人在寫訊息的時候總喜歡多加一些額外的備註（PS. 我很少這樣子做)；在心情不好的時候，留下一些自己的心情日誌，譬如這東西真的超級無敵難寫到爆炸之類的。
請避免這些行為，因為寫程式碼的重點在「可讀性」這件事情，請務必從寫程式的開始到專案的結束都保持這個習慣，喃喃自語的程式碼會拖延其他人閱讀程式碼的過程。
2. 干擾的註解
有些註解沒有必要，尤其是在講述程式碼怎麼運作的時候，我簡單舉例一下你就懂了（舉例是指給你一個範本，讓你比較好理解文章的內容），換成中文文章的註解，是不是有比較好理解了，所以請避免這件事情。
3. 誤導型註解
註解是有時效性的一件事情，請務必記得這一點，有一些註解在多次更新之後就失去了原本的意思，原本可能是跟註解內容相同沒錯，但是在多個版本之後就不是這麼一回事了。
4. 被註解的程式碼
我們都是有禮貌的人，不會隨意刪除看起來「很厲害」的東西，尤其是被註解起來的程式碼，你可能認為它很重要所以不敢動它，而實際上它可能早就失去當初的用途了。
5. 過多的資訊
千萬不要在程式碼裡面寫文章，哪怕寫程式與寫文章有多處雷同的地方：它們都是一種語言；它們都會敘述某些事情；它們都試圖在傳達某些概念等等，這也不是在程式碼腳本中開始寫文章的理由。
六、後記
我一直認為寫註解是一件「很酷」的事情，因為綠色搭配程式編輯器的顏色非常符合我對寫程式的印象，我認為這代表了專業，實際上並不是，寫註解是一件多於事情，尤其是為了寫註解而寫，那就更多於了。
1. 註解是很重要的事情
當然，註解是很重要的事情，它是協助程式員跟程式員之間溝通的橋樑，也是我們學程式中自然而然學會的一件基礎技能，我完全沒印象我是什麼時候知道註解這件事情的了。
2. 註解是不重要的事情
當然，註解畢竟是一種備註，所以如果能不使用註解，就盡量的不要使用註解，因為程式碼本身就具有閱讀性，請不要像對待魔法文字一樣，幫每一個盧恩文字標上註釋。
3. 程式碼本身就是文章
最後，我打算再強調一次，程式碼本身具有可讀性，寫程式跟寫文章都是為了讓讀者看懂，讓下一位閱讀這份文章的人，能理解這份程式是在做什麼，撰寫程式的根本邏輯，就是為了「可讀性」這一件事情而已。
即將進入廣告，捲動後可繼續閱讀
為什麼會看到廣告
106會員
247內容數
對設計師如何成長為設計師好奇嗎? 2020年九月，我進入大學學習當一位設計師，從開始到沉寂，再到重燃熱忱，我將在方格子紀錄我的成長歷程、理念、心情，分享我在這段旅程中所經歷的故事。
留言0
查看全部
你可能也想看
Google News 追蹤
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
深入探討變數、型別和方法
正確撰寫 C# 程式碼
基本語法規則
程式碼行就像句子一樣,需要有某種分隔或結束字符。每一行 C# 程式碼(稱為陳述式)必須以分號結尾,以便程式碼編譯器處理。
例如,一個簡單的變數可以這樣寫:
```csharp
public string FirstNam
改稿真的不是一件需要太多情緒的事，把錯的挑出來、改掉，就這麼簡單！很少有什麼「大錯」需要去爭執誰對誰錯。不過真的滿多時候鬼遮眼或是偶爾真的會發生某種「明明前一版是對的，這一版居然是錯的」的鬼故事，把問題找出來解決就好！
這本《文案的基本修煉》是一本平易近人且充滿洞見的好書。書中指出了文案的最基本要求是「辭達」，也就是能夠順暢地傳遞意思。它強調了準確性、誠摯性和價值性在文案中的重要性。作者提供了許多實用的創意工具和觀念，讓廣告人和文案工作者能夠創作出引人入勝的內容。若你熱愛文字創作，我強烈推薦這本書給你。
C#程式由一或多個檔案組成，包含命名空間、類別、結構、介面、列舉和委派等型別。Main方法是C#應用程式的進入點。在C#中，註解用於在程式碼中添加說明，有單行和多行兩種類型。變數的定義需要指定變數的類型和名稱，可以一次為多個變數賦值。
這陣子比較有空可以去天瓏書局晃晃，正好看到這本剛上市不久的書，整體上大多數守則，也是我自己一直在遵循的，是相當不錯的一本總結書。但真的要仔細看每一節的內容，理解每個原則背後的情境與想要改善的問題是什麼。如果只是把每一節的標題拿來使用，很容易就會發現衝突的部分。
列出一套完整的程式
程式設計有許多種方法，不過通常會先列出清單的再逐一執行，這樣會加快程式設計的速度。設計通常會採取順推的辦法。所以順推的程式設計方式就是經歷觀念溝通、系統分析、資料統合、權限管理、頻率與時間、後台管理、畫面設計等等階段後，將框架設計完了以後，先列出一套完整的程式，將所有使用者都確
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
對於程序式編程來說，程式是由一系列的指令組成，例如計算數值、印出訊息、修改變數、呼叫子程序、配置變數的記憶體空間等。定義函式是為了讓一些程序可以重複利用，因此稱為子程序，其中參數為子程序中特別的變數，讓我們能夠透過它們控制子程序的行為。函式的回傳值只是一種方便將結果帶回來的方法，但一般只能回傳一個值
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
深入探討變數、型別和方法
正確撰寫 C# 程式碼
基本語法規則
程式碼行就像句子一樣,需要有某種分隔或結束字符。每一行 C# 程式碼(稱為陳述式)必須以分號結尾,以便程式碼編譯器處理。
例如,一個簡單的變數可以這樣寫:
```csharp
public string FirstNam
改稿真的不是一件需要太多情緒的事，把錯的挑出來、改掉，就這麼簡單！很少有什麼「大錯」需要去爭執誰對誰錯。不過真的滿多時候鬼遮眼或是偶爾真的會發生某種「明明前一版是對的，這一版居然是錯的」的鬼故事，把問題找出來解決就好！
這本《文案的基本修煉》是一本平易近人且充滿洞見的好書。書中指出了文案的最基本要求是「辭達」，也就是能夠順暢地傳遞意思。它強調了準確性、誠摯性和價值性在文案中的重要性。作者提供了許多實用的創意工具和觀念，讓廣告人和文案工作者能夠創作出引人入勝的內容。若你熱愛文字創作，我強烈推薦這本書給你。
C#程式由一或多個檔案組成，包含命名空間、類別、結構、介面、列舉和委派等型別。Main方法是C#應用程式的進入點。在C#中，註解用於在程式碼中添加說明，有單行和多行兩種類型。變數的定義需要指定變數的類型和名稱，可以一次為多個變數賦值。
這陣子比較有空可以去天瓏書局晃晃，正好看到這本剛上市不久的書，整體上大多數守則，也是我自己一直在遵循的，是相當不錯的一本總結書。但真的要仔細看每一節的內容，理解每個原則背後的情境與想要改善的問題是什麼。如果只是把每一節的標題拿來使用，很容易就會發現衝突的部分。
列出一套完整的程式
程式設計有許多種方法，不過通常會先列出清單的再逐一執行，這樣會加快程式設計的速度。設計通常會採取順推的辦法。所以順推的程式設計方式就是經歷觀念溝通、系統分析、資料統合、權限管理、頻率與時間、後台管理、畫面設計等等階段後，將框架設計完了以後，先列出一套完整的程式，將所有使用者都確
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
對於程序式編程來說，程式是由一系列的指令組成，例如計算數值、印出訊息、修改變數、呼叫子程序、配置變數的記憶體空間等。定義函式是為了讓一些程序可以重複利用，因此稱為子程序，其中參數為子程序中特別的變數，讓我們能夠透過它們控制子程序的行為。函式的回傳值只是一種方便將結果帶回來的方法，但一般只能回傳一個值