聊聊如何處理程序中的“分支條件”更加合理

2019-11-17 03:49:21

字體：大中小

來源：轉載

供稿：網友

   在編寫代碼的過程中，我們編寫的類往往會有需要支持多條分支條件的情況，一般情況下，我們可能會通過設定一些參數變量的方式，來對這些分支條件進行區分，那么就引出了一個問題，我們是采取盡量少的變量來代表多種條件分支好呢，還是先根據條件性質進行區分，然后用不同變量分別代表好呢？

    本人也經常遇到這樣的情況，這兩種方式，當然各有利弊，前者可以體現簡約精神，而后者更加注重分類，前者的弊端也很明顯，就是會增加其他開發人員閱讀我們代碼的代價，相反，這正是后者的優勢！

    說到這里，這個問題就變成是按照自己的編碼習慣，還是側重于團隊的協作？個人建議還是采取后者，因為良好的代碼質量的一個很重要的前提就是能夠做到“易讀易改”，可見，在團隊協作的過程中，是有必要有一套屬于團隊的規范的，這樣雖然在初期可能會感覺有些別扭，但是其威力將體現在將不同模塊進行融合，以及在后續處理項目支持時得到體現。所謂磨刀不誤砍柴工，或許就是這個道理吧。

    與此同時，還有一種情況，就是我們一般會在頁面上添加一些隱藏的標簽，用于存放一些從后臺得出的數據，用于客戶端腳本的使用，或者用于請求提交等情況，類似地，同樣會出現一些條件分支的情況，如果我們要處理的頁面量比較多，條件分支也不只兩種的話，我們是有必要將所有頁面進行統一處理，添加所有的條件分支標簽，還是根據實際頁面需要的分支條件進行添加？

    統一處理的優勢，會使開發效率比較高，但同時可能會隱藏一些潛在的bug，而按需分配的方式呢，則不會出現隱藏的bug問題，因為一旦有問題，此頁面就會出現錯誤提示，當然，這就需要我們在開發頁面的時候更加的小心！

    可能大家發現了，很多的時候，我們遇到的都是這樣的情況，即有幾件事情需要處理，往往只是處理順序的不同，其實很少有能大幅減少這些事情的情況，僅僅是處理的先后順序，但給我們帶來的結果將會大大的不同！接著說上面的問題，個人建議采用后者進行開發，因為如果采取統一的方式，不但增加很多的冗余代碼，也不利于其他開發人員的開發和維護，與其將這些工作量放到后期，還不如消滅在開發階段，這樣的代價是最小的。

上一篇：Kenai.com將與java.net合并

下一篇：ASP.NET的SEO：使用.ashx文件——排除重復內容