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

看板Soft_Job作者 (Miyada vv)時間11年前 (2014/09/07 00:40), 11年前編輯推噓19(19推 0噓 46→)
留言65則, 32人參與, 最新討論串1/21 (看更多)
這是我"前"公司的經驗了 一開始以為公司內有嚴格的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沒看過 她直接在辨公室裡開飆 2. reviewer說出了我聽說最莫名奇妙的一句話 "這function以前沒人用過 所以你不能用這function" (jquery的trigger) 不是因為效能 不是因為安全問題 而是因為公司前人沒用過.... 我第一次遇到會規定coding style的公司 一開始以為是檢到寶 後來沒想到工作沒滿試用期就離職了.... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.252.76.35 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410021607.A.DC4.html
推
09/07 00:46, , 1F
案例1你可以拿refactor的書給他看
09/07 00:46, 1F
前題是reviewer會唸
→
09/07 00:52, , 2F
案例2的意思應該是怕其他人看不懂 可能有既有慣用寫法
09/07 00:52, 2F
這倒是有可能 但是如果有既有慣用寫法 我覺得應該要寫出來給人知道 而且這樣一打範圍太大了 什麼function都能用這原因被禁止掉
→
09/07 00:53, , 3F
不可以用formatter 不過你用了他會知道嗎 @@
09/07 00:53, 3F
之前我有survey過 但是既有的online formatter都有小部份不能達到 而且公司很重規定+reviewer坐我旁邊 我非常討厭被飆 所以他們說不能用我就沒去用
→
09/07 01:02, , 4F
糟糕 我也不喜歡一的寫法orz
09/07 01:02, 4F
我在STACK OVERFLOW看過這個問題 有人說I perfer to call this question "holy war". XD 但我是覺得你要講要改OK 沒看過的CODE就直接抓人來飆....我只會覺得她心胸未免也太狹窄
→
09/07 01:13, , 5F
我也喜歡在func內做檢查 不允許就return 或者 continue
09/07 01:13, 5F
(握)
→
09/07 01:14, , 6F
我喜歡自由發揮xD，加油，總會找到適合的位置
09/07 01:14, 6F
謝謝!!
→
09/07 01:16, , 7F
我還以為1的寫法會轉成switch耶 = =a (也許個人偏好?)
09/07 01:16, 7F
對啊~已經變成個人偏好了
→
09/07 01:24, , 8F
switch 只能針對明確的result做判斷 case
09/07 01:24, 8F
→
09/07 01:25, , 9F
switch的特點在於 善用break
09/07 01:25, 9F
是啊 例如 if(A && B) { } else if(C && D) { } else { } 就不好改成switch了
推
09/07 01:40, , 10F
部門經理說，他在前一個公司，也是有規定
09/07 01:40, 10F
→
09/07 01:40, , 11F
老闆不用遞迴，你寫了遞迴去給老闆，解釋到他懂了
09/07 01:40, 11F
→
09/07 01:41, , 12F
他還是會叫你改成迴圈
09/07 01:41, 12F
→
09/07 01:41, , 13F
至於過多層是否是你那個function 職責太多呢?
09/07 01:41, 13F
功能倒是還好 那個function不超過4層 只是為了降層才寫成那樣
推
09/07 02:08, , 14F
1. 寫成這樣大概我們組上任何人review都會不過
09/07 02:08, 14F
→
09/07 02:08, , 15F
2. 新的function確實代表了風險。但是並非絕對不能承受
09/07 02:08, 15F
→
09/07 02:09, , 16F
可以設法提出: 1)這function在各種環境下可靠的證據
09/07 02:09, 16F
→
09/07 02:09, , 17F
2)若用現有function也可以完成同樣功能，用新的好處為何
09/07 02:09, 17F
1.如果說這是LINUX推薦的寫法呢? 事實上....他們最新一版的coding style規定也叫別人用我那種寫法 2.她沒有提供現有的function給我用 只有說那樣寫不行 要改掉 例如大家都用scanf 我突然間用fscanf這樣 然後我上面回文中有提到 "但是如果有既有慣用寫法 我覺得應該要寫出來給人知道"
推
09/07 02:09, , 18F
我只覺得這樣就要走人 也太兇...@@
09/07 02:09, 18F
是誰兇XD?
推
09/07 02:13, , 19F
聽你這樣描述，我會認為在那邊只是Code產生器 XD
09/07 02:13, 19F
以前我也有想過這個問題 但我聽說外國也會有code reviewer和coding style 所以後來我也被說服了Orz
→
09/07 02:28, , 20F
1.的寫法是guard condition? 是的話這樣寫應該ok
09/07 02:28, 20F
是的 ※ 編輯: workworkwork (111.252.76.35), 09/07/2014 02:30:15
→
09/07 02:31, , 21F
看來問題出在無法溝通XD
09/07 02:31, 21F
推
09/07 03:04, , 22F
不用formatter的理由是..?
09/07 03:04, 22F
→
09/07 04:41, , 23F
reviewer 不能溝通之外也不專業!一個東西能不能用居然是
09/07 04:41, 23F
→
09/07 04:43, , 24F
看前人有沒有用過?就算自己懶得看~也該叫原PO說明使用上
09/07 04:43, 24F
→
09/07 04:44, , 25F
的優缺點~再做進一步的考量~甚至是開個內部會議啊...
09/07 04:44, 25F
→
09/07 06:56, , 26F
我覺得reviewer不能溝通就算了
09/07 06:56, 26F
→
09/07 06:57, , 27F
其他那些根本就是小事y
09/07 06:57, 27F
→
09/07 09:29, , 28F
linux kernel裡面就是遇到錯可以直接return就直接return
09/07 09:29, 28F
→
09/07 09:29, , 29F
需要收屍的時候就會有goto跳到最後面反向收垃圾
09/07 09:29, 29F
→
09/07 09:30, , 30F
會這樣寫有個原因, 就是每行80字元的限制
09/07 09:30, 30F
→
09/07 09:39, , 31F
我習慣寫 if ("ABC".equals(str)) { 也曾被嫌棄過
09/07 09:39, 31F
→
09/07 09:40, , 32F
說為什麼不寫成 if (str.equals("ABC)) { ....
09/07 09:40, 32F
→
09/07 09:43, , 33F
另外常常要做null checking覺得很麻煩，不知是否有好方式
09/07 09:43, 33F
推
09/07 10:02, , 34F
如果你是用java的話..用StringUtils.equals...
09/07 10:02, 34F
→
09/07 10:03, , 35F
你就跟他們說這是Apache認證過的
09/07 10:03, 35F
推
09/07 10:04, , 36F
wes:與其說是80字元的限制，不如說是用這些規定來防巢狀
09/07 10:04, 36F
→
09/07 10:04, , 37F
if-else。另一個相關的規定就是tab width=8
09/07 10:04, 37F
推
09/07 11:09, , 38F
1.的寫法不錯啊，我避免if太多層也是這樣用的
09/07 11:09, 38F
→
09/07 12:13, , 39F
linux的寫法也和driver特性有關 初始化失敗要反向處理
09/07 12:13, 39F
推
09/07 12:57, , 40F
1.你改寫的方式,可能會有潛在的問題.
09/07 12:57, 40F
→
09/07 12:58, , 41F
主要是你的程式不只是單純的guard condition，每個codition
09/07 12:58, 41F
→
09/07 12:58, , 42F
間還有"do something".
09/07 12:58, 42F
→
09/07 12:59, , 43F
不注意的話, 有可能增加leak的機會
09/07 12:59, 43F
推
09/07 12:59, , 44F
這樣算是有作code review喔? 這樣人人都是code viewer
09/07 12:59, 44F
→
09/07 13:00, , 45F
基本上這公司的制度和人員素質都不怎樣吧...
09/07 13:00, 45F
→
09/07 13:00, , 46F
從這點來看，我不認為你的reviewer在1.的情形不對,也可能單
09/07 13:00, 46F
→
09/07 13:01, , 47F
純是關注點不同,你比較注重減少層次，他可能比較重視單一
09/07 13:01, 47F
→
09/07 13:01, , 48F
entry/exit的問題.
09/07 13:01, 48F
推
09/07 13:41, , 49F
我倒是寧願指定一款code formatter, checkin前要跑一下
09/07 13:41, 49F
→
09/07 13:42, , 50F
把時間花在formatting上真是沒效率的事.
09/07 13:42, 50F
→
09/07 14:12, , 51F
1 哪有什麼問題，這間公司... 塊陶阿
09/07 14:12, 51F
→
09/07 14:29, , 52F
= = 其實你的例子一樣能轉.有沒有價值而已...
09/07 14:29, 52F
→
09/07 14:32, , 53F
switch(true)case A&&B,!(A&&B)&&C&&D,!(A&&B)&&!(C&&D)
09/07 14:32, 53F
推
09/07 21:22, , 54F
樓上那寫法有夠醜
09/07 21:22, 54F
推
09/07 22:34, , 55F
int qq = true ? 1 : 2
09/07 22:34, 55F
推
09/07 22:53, , 56F
你覺得他說的真的沒 100% 可取性？
09/07 22:53, 56F
推
09/08 02:39, , 57F
例一明顯是原po寫法比較好吧 可讀性較高 將來維護也不
09/08 02:39, 57F
→
09/08 02:41, , 58F
會繼續在裡面增加判斷式 leak請用auto pointer
09/08 02:41, 58F
推
09/08 22:52, , 59F
不能用formatter掃有啥意義? 有車不開應要用走的
09/08 22:52, 59F
推
09/09 14:10, , 60F
trigger超好用的耶，公司沒人熟jquery嗎…
09/09 14:10, 60F
→
09/09 15:20, , 61F
很怕遇到reviewer , 以為自己是神.
09/09 15:20, 61F
→
09/10 01:38, , 62F
也不是每個reviewer都這樣啊~能不能溝通並盡量站在客觀的
09/10 01:38, 62F
→
09/10 01:38, , 63F
角度去討論才是重點...
09/10 01:38, 63F
→
09/12 00:22, , 64F
想問trigger不好嗎@@?我用了超多耶
09/12 00:22, 64F
推
09/12 14:03, , 65F
幹麻不用Formatter....
09/12 14:03, 65F
‣ 更多 workworkwork 的文章
文章代碼(AID): #1K2pZdt4 (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 21 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共21篇)
‣ 更多 workworkwork 的文章
文章代碼(AID): #1K2pZdt4 (Soft_Job)