iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 11
1

參數的命名規則。
基本上Parameters或Arguments的命名規則會跟者變數的命名規則走:用camelCase,在名稱上要突顯他的特徵,如果是array或collection記得改成複數型...等等。

private void MoveToArchieve(int accountId, string assignedStorage);

所以今天的分享結束(咦?)


下面才是正題 :D
也許只有我,但如果熟悉SOLID原則的人應該都會覺得,參數是個很麻煩的東西。
不知道有沒有聽過"參數不能超過七個"這種說法?意思就是一個方法的參數最好不要超過七個,這個規則連微軟都有偷偷置入這個規則喔。
https://ithelp.ithome.com.tw/upload/images/20200912/20111458gpAhs54N2r.png
也許是腦補,但這個原則其實很多地方都看得到。

其實不難理解為什麼會有這種說法:人的腦袋可以接受或記憶的數量很有限,就算在有工具輔助的情況之下,也很難處理超過一定數量的資訊。

function createAccount(userid, username, aliasName, address1, address2, address3, phoneNumber, otherArgmentWeDoNotCareAbout) {
...
}

這種寫法真的會造成疲乏,所以太多的參數也會被視作一種Code smell,應該要被避免。
理想上的方法應該不帶任何參數的,但如果一定要帶參數的話,也應該盡可能的減少參數的數量,例如上面的例子,應該重構成

function createAccount(userInfo, address, otherArgmentWeDoNotCareAbout) {
...
}

為什麼會提到SOLID原則呢?這個原則裡有一項叫"Open-closed principle,開放/關閉原則,意思是一個物件要對擴展功能開放,而對修改功能關閉。
什麼意思呢,就是如果一個方法己經寫好了,如果要修改它的行為,應該要在不修改原始碼的情況下修改。
其實也不難理解這背後的原因啦,特別是public method,如果每個需求都可以隨意的更動他的邏輯,那這個方法就會隨時處於不穩定的情況。
方法本身的處理方法這裡暫時不提,但如果是參數面的話,我個人的處理方法是:只要有參數,一律寫成類別,無論數量多寡都透過類別來處理。雖然不是個很特別的東西,但運用上可以解決不少這類的問題。其實最適合的方法應該是包成JSON物件,然後在方法裡解析所有的參數出來,然後再往下走。

有人有看過爆長的參數列表嗎?我看過20+個參數的,真的只能用傻眼來形容,有人有更好的解法法?分享一下吧!


上一篇
Day10 - [代名詞二] 複數型,Array或Collection的命名規則
下一篇
Day12 - [代名詞四] Magic Numbers
系列文
邁向專業軟體工程師必修的英文課30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言