Re: [討論] 因為空格~我離開了一間公司

看板Soft_Job (軟體人)作者 (guest)時間11年前 (2014/09/07 03:16), 編輯推噓3(4137)
留言42則, 13人參與, 最新討論串3/21 (看更多)
※ 引述《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 寫法最好, 還是說這個寫法糟透了,那是他家的事,我不出來應戰。 我只是恰好路過,出來建議一下而已。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.46.53.194 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410030988.A.A28.html

09/07 03:32, , 1F
好的 ide 本來就可以看出有多少層.....
09/07 03:32, 1F

09/07 04:13, , 2F
我都是以後續除錯跟修改看這件事. IDE可看出..但他無法
09/07 04:13, 2F

09/07 04:13, , 3F
辨識人的邏輯是否對, 未來要刪除某條件時,人可能會刪錯
09/07 04:13, 3F

09/07 04:15, , 4F
但IDE依然只能辨識相對應的{}數目對,但刪錯位置他不知
09/07 04:15, 4F

09/07 04:15, , 5F
1)根本不該弄錯... 2)if層數增加也是落落長啊...
09/07 04:15, 5F

09/07 04:17, , 6F
說!X不是好方法也太武斷 用來表示前題條件可是相當有用
09/07 04:17, 6F

09/07 04:21, , 7F
1)會弄錯是因為他說每個條件成立後會"先做某事"再繼續
09/07 04:21, 7F

09/07 04:22, , 8F
如果純判斷不會做某事..後續要刪某條件,確實不會弄錯阿
09/07 04:22, 8F

09/07 04:23, , 9F
要先做某事..一堆落落長的 } 真的會刪錯.
09/07 04:23, 9F

09/07 04:27, , 10F
!X 是指整個框架而言, 不是指對 X 做反運算而言
09/07 04:27, 10F

09/07 04:28, , 11F
但他寫 if(!X)return; 表示他段程式碼是在某函數內..
09/07 04:28, 11F

09/07 04:29, , 12F
所以 !X 真的是比較不好的寫法. delphi 語言他的寫法是
09/07 04:29, 12F

09/07 04:30, , 13F
最前面寫 result := false, 如果全通過在 result:=true
09/07 04:30, 13F

09/07 04:31, , 14F
這裡重點是要討論架構..不是要討論 !X 好不好
09/07 04:31, 14F

09/07 04:34, , 15F
我指的架構是這三種寫法的比較,不是指我推文補充的事
09/07 04:34, 15F

09/07 04:37, , 16F
delphi的寫法 VS !X 那是題外話了.跟本文比較無關
09/07 04:37, 16F

09/07 05:58, , 17F
guard condition 寫法很常見 沒有比較糟
09/07 05:58, 17F

09/07 05:59, , 18F
要 debug 跑 debugger 就好了
09/07 05:59, 18F

09/07 08:40, , 19F
你太武斷了吧 這樣寫法沒有比較糟 你的寫法才會讓人看不懂
09/07 08:40, 19F

09/07 09:52, , 20F
樓主的寫法比第一種還複雜且不好理解...
09/07 09:52, 20F

09/07 10:53, , 21F
short circuit 其實有些陷井 有時不小處處理
09/07 10:53, 21F

09/07 10:53, , 22F
會出問題 與其用 short circuit...
09/07 10:53, 22F

09/07 10:54, , 23F
我寧可用 guard condition
09/07 10:54, 23F

09/07 10:54, , 24F
有踩過地雷就知道了
09/07 10:54, 24F

09/07 10:54, , 25F
就跟 the one true brace style 一樣
09/07 10:54, 25F

09/07 10:58, , 26F
而且 short circuit 還有一個問題
09/07 10:58, 26F

09/07 10:59, , 27F
要判斷哪幾個 expression 會被 evalute
09/07 10:59, 27F

09/07 10:59, , 28F
並沒有 guard condition 這麼直觀
09/07 10:59, 28F

09/07 11:00, , 29F
特別是 && || 混搭的時候 得想一下
09/07 11:00, 29F

09/07 11:17, , 30F
我很討厭 條件||條件, 這部分程式碼超容易出錯,
09/07 11:17, 30F

09/07 11:17, , 31F
這除非是 sql 的code沒得改,只能用()去降低出錯
09/07 11:17, 31F

09/07 11:18, , 32F
要不然遇到 && || 混雜.."個人習慣" || 會特別處理再
09/07 11:18, 32F

09/07 11:19, , 33F
拿回來跟 && 運算
09/07 11:19, 33F

09/07 11:58, , 34F
那叫做 guard condition/clause
09/07 11:58, 34F

09/07 14:15, , 35F
我會更不想看到你這種寫法...
09/07 14:15, 35F

09/07 20:43, , 36F
沒有2可以按好難過~
09/07 20:43, 36F

09/09 12:44, , 37F
你根本完全沒搞懂第二種寫法的由來,跟 { } 視覺上對不
09/09 12:44, 37F

09/09 12:44, , 38F
對得上根本一點_關係都沒有
09/09 12:44, 38F

09/09 19:00, , 39F
老實說這點我支持原po,巢狀太深很難讀
09/09 19:00, 39F

09/12 15:06, , 40F
2
09/12 15:06, 40F

09/12 15:10, , 41F
不是每個環境都會有好的IDE協助,巢狀太深很痛苦
09/12 15:10, 41F

05/14 21:14, , 42F
可以噓ㄟ 朝聖ㄏㄏ
05/14 21:14, 42F
文章代碼(AID): #1K2rsCee (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1K2rsCee (Soft_Job)