翼前緣渦流

個人最開始只用 FREE 版，因為有在使用一個把 SQL Query 轉成 Class 的腳本(主要是參考 mrkt 大的文章 [註M])。

FREE 版並不好用，試用它無法讓我產生購買念頭，但一直有人好評，在某次特價就買了 Pro 版。

幾年過去了，我不會刻意去使用 LINQPad 但很自然地會有用它更省事的時候，想和朋友介紹一下。結果比較了 LINQPad 的有無對日常決策的差異之後，發現買地很值，就記錄一下。

羽量級資源佔用

開發 .NET 大多會使用 Visual Studio，上次安裝 VS2019 需要  9.6 GB 的 C 槽空間，即使只開啟一個 Console 專案也會佔用 6、700 MB 記憶體，是個重量級的開發工具。

相比之下，LINQPad 安裝佔用硬碟空間約 40 MB，啟動後佔用約 100 MB，顯地很輕量。

這側面驗證了一些日常使用感受，用 VS 開專案通常都可以先喝個水，想一下待會要從哪開始寫 Code，而 LINQPad 則是點開就已經把手放鍵盤上要開始把想法實現了。

以個人電腦為例，VS 開啟一個空的 Console 專案約 20 秒，而開啟 LINQPad 約 2 秒。可以看一下比較影片

Visual Studio

LINQPad

 

腳本作業

說到腳本的印象，就是簡便。通常就是開個文字檔，寫一兩行就會動了(bash, python, powershell etc.)。

C# 的語法也很簡單，例如：將資料夾第一層的 .jpg 檔清單，寫成文字檔的邏輯其實只有一行

File.WriteAllLines(@"D:\list.txt", Directory.GetFiles(@"D:\tmp","*.jpg"));

但實際操作就沒有這麼方便了，因為要先開 VS(20 秒過去) 和後續動作

1. 建專案，決定專案名稱
2. 決定專案位置
3. 寫 Code

差不多一分鐘了吧，還因為開專案多了 9 個檔案 10 個資料夾，如果只做一次那就是多了一包垃圾。

而實際的 Code 通常十行起跳(重點只有一行)。

using System.IO;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            // 只是想執行這一行 Code，做了多少動作？
            File.WriteAllLines(@"D:\list.txt", Directory.GetFiles(@"D:\tmp", "*.jpg"));
        }
    }
}

以上的種種都讓 C# 開發者，更傾向小事不寫 Code，因為確實沒帶來便利。這種狀況可以使用 LINQPad，秒開寫一行 Code，完成。這段 Code 喜歡的話，存下來也只一個 .linq 檔。

有人說 Python 自帶電池，基本函式庫就能完成幾乎任何事[註1]。而當 C# 變地像腳本語言一樣方便時，你會發現它比 Py 帶電，基本函式庫超多，還有 IntelliSense(C# 寫久就不想回去沒有自動完成的石器時代)。

我經常使用 LINQPad 協助日常任務，只要有想法馬上就能輸出，如果常重複還可以存起來。

執行力

.NET 在開發過程中，有很多主線外的小事，成本都不低。

1. 有段 Code 想確認執行結果，例如一段正則表達式
2. 去打某個 API 把某幾欄爬下來，做成清單(可能只做一次)
3. 拿到特別規格的資料，要轉成表格
4. 從 SQL Server 抓資料給別人，但要做些 SQL 不擅長的處理(字串分割、轉半形、url encode、string join、正則表達、算筆劃)

個人經驗 LINQPad 在很多時候，可以把這些小事的成本降低，當小事無法停下你的步伐，那看上去執行力就提升了。

有天找到資料說可用 string.Normalize(NormalizationForm.FormKC) 解決擾人的全形字問題，不確定效果如何，會怎麼做？

1. 開個 Console 專案來試一下
2. 先記著，下次要用到邊寫邊試

通常寫段 Code 測一下它才會變成自己的知識，但要開個專案測(2、30 秒跑不了)，有時候真的讓人覺得麻煩。記著也很容易被遺忘，就像加了就沒開過的瀏覽器書籤。但如果只要一兩秒就能試，就容易多了，而 LINQPad 做到了。

蒐集資料時，通常不會只估狗一次，而是一直搜尋，不斷地加入上一次得到的資訊進行搜尋調整，大腦高速運轉。這時候不會想被一個 30 秒以上的東西中斷，成本太高。儘量蒐集選項，挑選可行性、可能性最高的試試看，變成常見的解法。

而 LINQPad 在手，別人還在猶豫時間成本時，用 LINQPad 可能已經試過好幾個了，因為很多時候這只是舉手之勞。找完一輪資料，手上就已經有幾個試過的方法比較優劣了，

---

Code Review 時，覺得某個方法怪怪的，怎麼測？

1. 為方法寫測試
2. 程式跑起來 Debug ，操作到要測的方法
3. 開一個空專案把方法複製過去跑

為方法寫測試是正解，但考慮一些狀況，像專案原本就沒有人懂測試、你不是核心成員都可能導致寫測試成本太高。

很常見就是把程式跑起來，這樣你還可以順便瞭解一下操作、Domain 為之後加入開發作準備。

但當專案夠大，專案 Build 起來時間也蠻可觀的(個人近期案例有 30 秒的)，而這段 Code 也常常也而要在一系統操作才會跑到(20~40秒)。而這段 Code 說不定只是五六行 && || 的交叉組合(就以往經驗這樣就夠了，只要來三四組就有足夠的 Bug 機率)。

而開一個空專案的成本足夠讓人怯步，因為還在看 Code，這樣很容易中斷思考。

機會合適的話，例如它是一個去耦合的方法，把它貼到 LINQPad 去測，基本是秒測，還能協助理解邏輯。

---

LINQPad 的 Dump 真的是很棒的功能。當在評估使用一個陌生的 Lib，只要它的物件結構有以下特徵，用 VS Debug 都有種以管窺豹的感覺

1. 物件多層導致結構複雜
2. 屬性很多
3. 陣列

那種用滑鼠一個個移上去看的方式很消耗耐心，我有時還會因為手殘建幾個變數放想看但不好找的屬性。

但用 LINQPad 的 Dump 能印出可收合的物件，見樹又見林

---

LINPad 的 F12 移至定義，會使用 ILSpy 反組譯 dll 並直接定位到 Class Member，有些時候第三方某些方法看原始碼比看文件更能理解差異。

這樣無痛反組譯的安排，很容易讓人在潛移默化之間，更加地理解底層。

例如有次 string.Contains 有時候和 string.IndexOf 的結果不一樣，有人是改用 IndexOf 說 Contains 不知道為什麼有 Bug，而我則是毫不費力地就知道了兩者的差異。

還有一些遺珠，像是

• 腳本中使用 this.Connection 來取得連線，就可以快速切換 DB 執行同樣程式碼。
• Ctrl+Shift+F 可搜尋所有腳本內容
• Clone Query 複製腳本，方便修改複用
• 直接拖曳 .dll 到視窗，即加入參考

綜上所述，當測試函數、抓 Bug、看資料的速度都變快時，看起來就是執行力變強了。

FREE 版沒有綜效

FREE 版有效用，但綜合起來幾乎沒效益，因為沒有 IntelliSense 做什麼都礙手礙腳的，搞不好還會開個 VS 在旁邊用來找 Class Member，效益都被副作用抵消了。

價格

PRO 個人版售價在 49 鎂，約台幣一千五百元，一年工作天約 240 天，只它一天能幫你 6.25 台幣，則一年即可回本。

就算只有基本工資 22k ，只它一天能為你省下  3 分鐘，就回本了。更何況付錢買的這個版本可以一直使用。

---

結論

只用 FREE 版時，很難去評估 LINQPad 是否值得購買，因為很多事情沒有 LINQPad 也做得到。例如可以固定開著 VS 並使用測試專案就能做到快速驗證某些函式；也可以嚐試自己實作 Dump、或訂閱 Ozcode(連結)；也可安裝 JustDecompile(連結) 反組譯 dll、或訂閱 ReSharper(連結)；也可以在 .config 的 connectionStrings 加各種常用的連線字串。

我覺得它給自己的定位就和名字一樣，像個記事本或便條紙，開了就能用、隨手就能寫點東西、如果覺得不錯可以存起來。不求功能完整，架 Server、開專案都不太行，但拿它做些小事情就是會幫你把流程調到順暢直覺。這種信手捻來的狀態，比起原來覺得寫點 C# 能解決，卻遲遲難動手好太多了。

VS 功能完整，是 .NET 專業開發首選(當然你也可以用 Rider)，初期很多的建置動作都會加速後續的開發。但很多輕量、一次性或嚐試性的任務，並不需要這麼完整的開發方案，用 VS 就顯得麻煩， 當你寫 C# 只有 VS 這個選項的時候，C# 就顯得笨重。這時 LINQPad 就補上了 C# 開發者的短板。有點像只能開轎車出門，那去隔壁街買個宵夜都嫌麻煩，但騎機車就方便多了。

備註及參考連結

[註M] mrkt 的「Dapper - 使用 LINQPad 快速產生相對映 SQL Command 查詢結果的類別」(連結)

[註1] 記得是歐禮箂的 Python 深入淺出

LINQPad 購買網頁(連結)