無瑕的程式碼心得記錄(一)

這篇是無瑕的程式碼的心得筆記.....

有意義的命名

• 讓名稱帶表意圖
  
  • 讓名稱名符其實
• 避免誤導
• 產生有意義的區別
• 使用能唸出來的名稱
• 使用可被搜尋的名字
• 避免編碼
• 避免思維的轉換
  
  • 清楚明白才是王道
• 類別的命名
  • 使用名詞或名詞片語命名
• 方法的命名
  • 使用動詞或動詞片語
• 不要裝可愛
  清楚闡述比起娛樂價值來的重要
• 每種概念使用一種字詞
  Ex:取得方法不要fetch、retrieve又get
• 別說雙關語
• 使用解決方案領域的命名
• 使用問題領域的命名
• 添加有意義的上下文資訊（context）
• 別添加無理由的上下文資訊

函式

• 簡短
• 只做一件事
• 每個函式只有一層抽象概念
  • 降層準則
    • 由上而下閱讀程式碼
• 使用具描述能力的名稱
• 函式的參數
  • 參數數量
    • 最理想是零個
    • 其次是一個
    • 盡量避免超過三個參數
  • 物件型態的參數
    • 可減少參數的數量
  • 輸出型的參數
    • 避免使用
• 動詞和關鍵字
  • 替函式取個好名稱可產生許多良好的附加價值
• 要無副作用
  • 一次只做一件事，不要在函式底下偷做其他事
• 指令和查詢要分離
  函式要能做某事或能回答某個問題，但二者不該同時發生
• 使用例外處理取代回傳錯誤
  • 錯誤處理就是一件事
• 不要重覆自己（DRY）
• 結構化程式設計
  • 每個函式及函式裡的區塊都應該只有一個進入點及一個離開點
  • 不能有break或continue敍述
  • 永遠不能有goto敍述
• 如何寫出這樣的函式
  • 像寫文章一樣
    • 初稿通常粗糙而雜亂無章
    • 重新組織整個文章段落，將文章改善至你要的樣子

註解

• 不要替糟糕的程式碼寫註解—重寫它
• 註解無法彌補糟糕的程式碼
• 用程式碼表達你的本意
• 有益的註解
  • 法律型註解
  • 資訊型註解
    • 透過註解提供一些基本資訊是非常有用的
  • 對意圖的解釋
  • 闡明
    • 把難解的參數或回傳值翻譯成具有可讀性的文字
  • 對後果的告誡
    • 做為一種警告
  • 待辦事項註解
  • 放大重要性
• 糟糕的註解
  • 喃喃自語
  • 多餘的註解
    • 有時候程式碼本身就可以提供明白的意圖，加了註解反而比程式碼更難理解
  • 誤導型註解
    • 不精確讓人看不懂
  • 規定型註解
    • 因為規定加上去的註解，有時候反而會產生更多困惑或造成散亂的程式結構
  • 日誌型註解
    • 現在有好的原始碼管控系統，可以不需要
  • 干擾型註解
    • 某些註解毫無用處，只會干擾
• 可以使用函式或變數時就別使用註解
• 位置的標誌物
• 右大括號後面的註解
• 出處及署名
• 被註解起來的程式碼
• 非區域性的資訊
• 過多的資訊
• 不顯著的關聯
• 函式的標頭
  • 為小型函式選一個好的名稱，通常比「將註解寫在函式標頭」來的更優

編排

• 編排的目的
  • 讓程式碼更具可讀性
• 報紙的啟發
  • 頭條的敍述
  • 概要
  • 全文細節
• 垂直的編排
  • 概念間的垂直空白區隔
    • 用空白來分隔不同的思緒
      • 宣告
      • 引用類別庫
      • 不同函式
  • 垂直密度
    • 程式密切相關的程度
      • 密切相關的程式應該垂直緊密，不要被無用的註解或其他的程式碼切開其關聯性
  • 垂直距離
    • 具類似的概念應盡可能的靠近
    • 變數宣告
      • 應盡可能靠近變數使用的地方
    • 實體變數
      • 應被宣告在類別的上方
    • 相依的函式
      • 如果A函式呼叫了B函式，那麼這二個函式在垂直編排上要盡可能靠近
    • 概念相似性
      • 概念上有相似性質的程式碼盡可能的相近
    • 垂直的順序
      • 呼叫敍述應在被呼叫函式的上方
• 水平的編排
  • 水平的空白間隔和密度
    • 高度相關及完全不相關的事情，都可以利用水平的空白將之分開
    • 設定運算子（assignment operators）
    • 強調運算子的優先權
  • 水平的對齊
    • 沒有必要
    • 長度會太長
  • 縮排
    • 階層結構
    • 讓視野層次結構更顯而易見
    • 違反縮排的規則
      • 有時候因if、while或簡短的函式想違反縮排的規則
      • 盡量不要
    • 空視野範圍
      • While或for迴圈的程式是空白
      • 確保空白區塊也被縮排，否則很容易被誤導
• 團隊的共同準則
  • 統一的編排規則

物件及資料結構

• 資料抽象化
• 資料/物件的反對稱性
  • 結構化的程式碼容易添加新的函式，而不需要變動已有的資料結構。而物件導向的程式碼，容易添加新的類別，而不用變動已有的函式。
  • 結構化的程式碼難以添加新的資料結構，因為必須改變所有的函式。物件導向的程式碼難以添加新的函式，因為必須改變所有的類別。
• 德摩特爾法則（The Law of Demeter）
  • 類別C內的方法f，應該只能呼叫以下事項的方法
    • C
    • 任何由f所產生的物件
    • 任何當作參數傳遞給f的物件
    • C類別裡的實體變數所持有的物件
  • 方法不該呼叫「由任何函式所回傳之物件」的方法
• 資料傳輸物件（Data transfer Objects,DTO）
  • 最佳的資料結構形式
  • 類別裡只有公用變數，沒有任何函式

[MS SQL]如何透過Database Mail進行郵件發送

Microsoft SQL Server裡提供了Database Mail可以用來設定外部的email，當主機有問題或是有發送Email需求時,就可以透過Database Mail來進行發送，設定方法如下:

開啟SQL Server Management Studio並連到SQL Server上，點開管理選項找到Database Mail，在Database Mail選項上按右鍵開啟選單，選擇設定Database Mail

如果有收到Email表示Database Mail設定成功囉~~

那要如何在用SQL進行Email發送呢?

直接執行下面的SQL指令
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'mail sender', --這裡輸入Database Mail設定檔的名稱
@recipients = 'test@mail.com', --要發送的Email
@body = 'Email本文內容', --Email的本內容
@body_format = 'HTML', --本文的格式,設定為HTML,在Email的本文內可以使用HTML語法
@subject = 'Email主旨' ; --這裡設定Email 主旨

這樣就可以發送Email了，是不是很簡單呢?
如果要在網頁程式或應用程式中發送Email，可以直接在程式中EXECUTE上面的SQL語法，就可以把Email發送出去了，用Database Mail這種做法發送Email還有一個優點,就是可以查到Email發送的記錄，只要執行下面的SQL就可以查詢到Email的發送記錄

   SELECT * FROM [msdb].[dbo].[sysmail_mailitems]

改變人生，從跑步開始～讀後心得

最近從圖書館裡借了幾本有關跑步的書，最近剛好把改變人生，從跑步開始看完了，簡單的來寫一下心得，這本書不是教導跑步技巧的書，我覺得比較像一本勵志的書，作者班‧戴維斯 (Ben Davis)原來本是一個大胖子，每天的生活就是吃，因為胖讓他極度的缺乏自信，讓他無法跟人群相處，每每生活上有什麼不如意就用吃來發洩，而這是種惡性循環讓他吃更多、變更胖，活在這樣生活裡無法自拔，直到有一天家庭聚會上，奶奶問了他一句：「班，你快樂嗎？」點醒了他，讓他決定進行了do life—好活人生，開始了他的馬拉松生涯，也改變了他的人生。

書裡我得到幾個心得：

1. 家人是重要的支柱 :
   不論你在做什麼事，有家人的支持及幫忙真的是一件很重要的事，班如果沒奶奶的那句話來讓他覺悟；如果沒有父親在他已經要放棄第二次的長跑時，陪著他一起參加比賽，我想班可能又要走回頭路；如果沒有哥哥陪著他一路參加比賽，憑自已一個人的參加比賽，一定也很難撐到最後。所以家人是最重要的支柱，支持你可以努力向前的動力之一。

2. 堅持 :
   做什麼事都一樣要能堅持下去，很多時候我們有滿腔熱血的要開始進行某件事，但是往往只有前面幾次可以努力做到，到後面可能因為工作忙碌或其他的藉口就不了了之，所以要能有所堅持。班一開始跑出了興趣，但是差一點又因為心裡有障礙(覺得自已無法完成十公里的賽事)差點就放棄了，還好有父親的幫忙才又再跑下去，我一開始跑步也是有同樣的狀況，前幾個星期很熱血的想天天起來晨跑，跑了幾天之後就開始慢慢的偷懶了，還好心裡一直有個聲音告訴自已，為了健康要趕快運動，督促自已要去進行，到後面變成了一種習慣，養成了興趣你就有所改變了..
   

痛苦是有限的，折磨也是有限的，只要撐下去，就會度過難關。
如果你這一輩子都活得舒舒服服，就永遠不會經歴鼓舞你的時刻。

共勉之～

[Javascript] Array操作方法

javascript中Array的幾個常用到的方法:

• concate()

在原本的array中，產生新的Array副本並將參數值加入到新的Array中，其結果不會影響到原來的Array內容。

    
  var users = ["jonn","keny","jeffrey"];
  var users2 = users.concat("frank","joe");

  //原始的array內容不受影響 ["jonn", "keny", "jeffrey"]
  console.log(users);
  //新的array為原始的array ＋ 參數內容 ["jonn", "keny", "jeffrey", "frank", "joe"]
  console.log(users2);
    

• slice()

• splice()
  splice跟slice不同，只差一個字母很容易讓人家搞混了，splice()的主要用途是
  向數組的中部插入項，但使用這種方法的方式則有如下3種。
  刪除：可以刪除任意數量的項，只需指定2個參數：要刪除的第一項的位置和要刪除的項數。例如，splice(0,2)會刪除數組中的前兩項。
  插入：可以向指定位置插入任意數量的項，只需提供3個參數：起始位置、0（要刪除的項數）和要插入的項。如果要插入多個項，可以再傳入第四、第五，以至任意多個項。例如，splice(2,0,"red","green")會從當前數組的位置2開始插入字符串"red"和"green"。
  替換：可以向指定位置插入任意數量的項，且同時刪除任意數量的項，只需指定3個參數：起始位置、要刪除的項數和要插入的任意數量的項。插入的項數不必與刪除的項數相等。例如，splice (2,1,"red","green")會刪除當前數組位置2的項，然後再從位置2開始插入字符串"red"和"green"。

晨跑新記錄～11K達成！

昨天晚上把之前看了一半的改變人生，從跑步開始：甩掉120磅、啟動新生活的汗水旅程又拿起來看，看到11點多剩下最後一章就上床睡覺了，不知道是不是受到了書的影響，今天早上五點就醒來上廁所，回到床上翻了一下睡不太著，於是就起身把書最後一章給看完了(沒想到太早起來還把老婆給吵醒了)，吃了半根的香蕉補充了一下體力，五點半左右就準備要動身出門去跑步了,一般時候我都是六點起床然後出門跑步，今天比平常多半個小時出門，心裡想著:今天應該可以多跑一點吧....

外面涼風陣陣,終於比較有秋天的感覺了，雖然這樣的天氣跑步感覺有點涼，但不過還是比大熱天好很多，跑起來也還滿順的，前5K一下子就過了，跑步的過程當中心裡還想著Do Life書中的作者都可以在一年內就完成那麼長的賽事，我想我應該也可以完成，於是心裡就燃起了要跑10K的心，一般我大概能跑到7K左右，其實這個距離讓我撞牆撞很久，一直都無法突破，參加岱宇的9.27K算是那段時間的最長距離了，而且那天跑完我整個人都虛脫了，除了吃不下飯還喝了好幾瓶運動飲料，直到上個星期我才第一次突破了10K的距離，短短的一個星期又再挑戰了第二次10K，這次其實沒有什麼覺得很困難的，過了7K之後還是很順，身體沒有什麼不舒服的感覺，但是到了8K多的時候就開始有點疲累感了，但是還是可以撐的下去，心裡想著：_都跑到這個階段了，好不容易離新記錄這麼近了，我一定可以完成的。_所以就這樣完成了11K囉～～

我覺得跑步最重要的就是意志力吧，很多時候其實我們是可以達到目標的，但也很容易因為意志不堅定一下子就放棄了，這樣子真的很可惜，跑步除了讓我體力變好，我也是在鍛鍊我的意志力，學習不要輕易的放棄，一步一腳印的跑下去，一點一滴的累積你的努力，只要撐過去就有美好的勝利果實在等待著你。