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

看板Soft_Job (軟體人)作者holydc (のヮの)時間11年前 (2014/09/07 04:52)推噓2(2推 0噓 16→)

留言18則, 6人參與討論串5/21 (看更多)

用個現實的例子 http://ideone.com/gkEwk5 我是真的不知道這種寫法哪裡比較糟糕，希望有人可以指點一步步走下來一目了然，發生問題 caller 也能知道是錯在哪裡唯一我自己看不順眼的是那些 goto，不過 c 沒辦法做到 raii 似乎也只能這樣相對的寫法 http://ideone.com/sJSdO9 雖然邏輯一樣，但是我覺得這縮排很醜，而且錯誤處理離出錯的地方太遠我反倒更不喜歡看到一大堆 short circuit evaluation 以同一個例子來說 if ((socket(...) >= 0) && (bind(...) == 0) && (listen(...) == 0) && (accept(...) >= 0)) { ... } 當這段出問題的時候，有辦法馬上找出是哪個步驟造成的嗎我比較笨，要我 debug 我可能會 1. 在 socket bind listen accept 裡面加 log 看是誰沒走進去 2. 把這個 if 拆開，分別看他們的回傳值但是 1. 的情況也許我是用別人的 library，不一定能修改用 2. 的作法我想結果自然而然會變成上面連結的形式難道 debug 完再改回 short circuit evaluation 嗎想和大大們討論看看 ※ 引述《guest2008 (guest)》之銘言： : ※ 引述《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), 來自: 36.231.100.94 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410036749.A.6EF.html