Simple Is Not Easy

在網頁開發上, 處理 query stirng 是非常常見的情境, 要手動拆組 query string 也不難, 或是使用 .NET 本身就提供的相關功能讓這件事更輕鬆, 而兩種做法各有優缺點.

在C#中 const 和 readonly 都可以被當作常數來使用, 但兩者在特性上有許多的差異, 使用上也有一些需要注意的地方.

Switch-case 是一個經常被使用到的語句, 但當條件/情境過多的時候, 他會變得很肥大, 某種程度上造成維護上的困擾, 網路上也有不少人提出針對過大的 switch-case 語句的重構技巧, 例如: 策略模式.
但是策略模式會長出很多新的類別, 如果每個 case 的實作內容都很小, 這樣做似乎是有點複雜了, 所以這邊提供其他的替代方案(但會有一些限制).

C# 的 partial 修飾詞是相對少用的特性, 但在某些時候能起到很關鍵的作用, 所以還是知道一下比較好.
partial不是關鍵字但是他可以放在在class, struct, interface 以及 void method(…) 的前面作為修飾詞, 並將類型宣告或方法拆分成多個, 而編譯時會將所有區段結合起來, 所以對執行時期沒有影響.

前些日子, 收到一個小需求需要隨機產生一組帶大小寫字母和數字的亂數字串, 想說需求滿簡單的, 快速寫一下就寫完commit了, 然後過不久就爆掉了.
來看看究竟寫了些什麼鬼東西~

重拋例外有很多種方式, 包含 throw, throw ex, 使用 inner exception 以及 System.Runtime.ExceptionServices.ExceptionDispatchInfo, 或是不要重拋例外.

先總結選擇如下順序:

1. 最好不要重拋例外
2. 重拋優先選 System.Runtime.ExceptionServices.ExceptionDispatchInfo
3. 沒有框架支援則用 Inner Exception
4. throw 應該沒什麼情境需要用到了
5. throw ex 是具破壞性的作法, 除非是要刻意破壞堆疊追蹤

這篇會整理這幾種方法的使用與優缺, 並且另外提到 throw 和 throw ex 兩種方法對於堆疊追蹤的負面影響.

在設計 API 的時候, 常常會被參數過多所困擾著, 因為當方法有著過多參數時, 使用的時候容易眼花, 而需要增減參數時也很不方便, 這邊以常見的 HttpHelper 為例來說明。

情境是這樣的, 我在github上fork了一個專案過來, 並且做了一些修改, 後來發現我的上游專案有幾個pull request剛好解決的我一直解決不了的問題, 該怎麼把那些變更同步到我的fork呢?

當我們想知道目前產品的測試程式涵蓋率的時候, 可以使用Visual Studio 2017內建的功能來分析, 但只有企業版支援這個功能, 所以另外找了AxoCover來用看看。

來紀錄一下 C# 的兩個關鍵字 , explicit 以及 implicit。