※ 引述《workworkwork (Miyada vv)》之銘言：
: 這是我"前"公司的經驗了
: 一開始以為公司內有嚴格的coding style規定是件好事
: 我也贊成公司要有一致的coding style
: (像我以前看過apache的C code
: 全部CODE都像同一人寫出來的一樣)
: 而公司內也會有人code review你的部份
: 一切聽起來都很完美
: 一開始聽到有規定coding style和code reviewer也很開心
: 但因這一切都因為公司裡有一個奇怪的規定而毀了
: "code不可以用code formatter去掃"
: 我承認自己寫程式常會漏勾
: 所以寫完會花很多心力在檢查有沒有BUG 是否會被攻擊 資安問題等等....
: 但在這間公司發現一個很奇怪的事情
: "有資安漏洞的CODE大家會很有耐心的教 空格沒空好會被罵的狗頭淋頭"
: 搞到最後一段程式寫完我只知道檢查空格....
: 最後的最後我決定離職的原因是出在reviewer
: 和reviewer的code觀念差太多 跟本無法共事
: 例如：
: 1.
: 有時為了避免太多層出現===>
: if(a)
: {
: //do a things
: if(b)
: {
: //do b things
: if(c)
: {
: //do c things
: }
: }
: }
: 會改成====>
: if(!a)
: {
: return ;
: }
: //do a things
: if(!b)
: {
: return ;
: }
: //do b things
: if(!c)
: {
: return ;
: }
: //do c things
: 但因為這寫法code reviewer沒看過
: 她直接在辨公室裡開飆
這個我看起來 A 跟 B 根本沒什麼不同，但 B 確實比較糟糕。
因為都是 X條件觸發，處理 X條件，再繼續往下做。
但你是 X不成立，就返回。這個 !X 不是好方法，實際上對系統架構沒幫助。
你要讓系統結構很維護，避免那麼多{}層出現，
框到到底那個 } 是對應那個 { 都不知道了，應該這樣寫:
if(
fun_A() == true
&& fun_B == true
&& fun_C == true
&& .......
)
{
做某件事
}
function fun_A()
{
if(....) return(false);
return(true);
}
下略，自己補上 fun_B()..fun_C()。
這樣寫有啥好處？？
(1) 最大好處就是太多層後，真的不知道那個 } 是對應那個 {
也就是你一直在數空格數到底空對了嗎？
(2) 除錯超快，注意我是直接每個判別直接寫一行，
你寫的落落長後，除非你是天下奇杷，腦袋超清楚，
要不然肯定會錯啦~~這個地方我除錯的速度絕對比你快。
我直接一行一行 // && fun_C() == true
就找出問題了。
甚至未來你某個條件不想再用就像上面一樣 mark 掉就好了。
以上給參考，你自己去評估三種寫法哪種最好。
另外如果有人又要出來跟我戰他要用 class 寫法最好，
還是說這個寫法糟透了，那是他家的事，我不出來應戰。
我只是恰好路過，出來建議一下而已。