仍然看不懂自己以前寫得程式?或是別人仍然看不懂你在寫什麼?
註解說的跟程式運作的也不一樣?
如果程式能寫出如同英文子句一般的邏輯描述
那無論是程式交接,或是回顧自己一年前寫的code
豈不是更淺顯易懂?
本篇將以Clean Code 為主軸
從閱讀我們使用的SDK 的Source Code
到撰寫淺寫意懂的程式碼
並介紹為何我們會需要近代的程式碼撰寫技術與規範
範例語言為 : C# ,maybe Angular5 (此篇會盡可能減少語言之間的隔閡)
也許是開始工作時遇到的困境的緣故,在下對於程式的命名與語意有些許的研究 也嘗試使用甚至創造過各種不同的撰寫方式(當然還包括那些寫完才發現沒異議後全部刪掉的Cas...
一開始在想這個主題的時候,雖然都已經想的八九不離十了 但真的開始要寫的時候發現,怎麼寫都似乎寫的會讓人不怎麼懂 再加上過去有一些與人溝通上的問題(總是被說太過抽...
最近因為剛好幫朋友寫個爬蟲,在撰寫的過程中發現這是個好素材,所以就拿來用了. 所以我們就來寫個爬蟲吧 以下的會以 .Net Core 2.0 ~ 2.1 (就是...
把上回最後寫好的程式的註解搬出來看一下 類別名稱 : 爬蟲 方法名稱 : 依照參數網址開始運行並回傳結果 詳細內容 : 1.建立HttpC...
前篇最後提到了一個介面如下 public interface ICrawler { /// <summary> /// 依照提供的R...
前一篇最後提到了,一個有趣的方法名稱叫做 EnsureSuccessStatusCode 這個方法用名稱就讓我們確定裡面所做的事情是什麼 這也是其中一種主題相關...
接續前一篇說,我還希望他在更整齊精準一些,前篇最後爬蟲如下 public async Task<IEnumerable<HtmlElemen...
接續前篇說的介面如下 public interface IChain<T> { IChain<TNext>...
此篇為C#專屬功能介紹,其他語言可能有該語言專屬相關解決方案 我將前篇範例中的 ChainAsync/IChainAsnyc 改名為 ChainAwait/IC...
前篇最後提到,用泛行來解決最後的相同參數問題 為了避免編譯器優先選擇原始類別或介面去執行 所以考量將所有的方法移出 只留下Result,然後將方法都移出變成擴充...