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

看板Soft_Job作者 (東周小星星)時間11年前 (2014/09/09 23:04), 編輯推噓13(13推 0噓 42→)
留言55則, 17人參與, 最新討論串15/21 (看更多)
我說說我對code review的想法, 我認為code review就像法律一樣, 這社會要有制度的運作,一定要有法律, 但若是這個法律是總統隨他高興說了就算的話, 那這個法律會是很爛的法律, 說穿了也不是什麼法律,根本就是命令, 那還不如不要有, 因為這種隨個人喜好而制定出的"法律"往往最後只是成為整人的工具, 一個好的法律是要一群人討論後制定出的, 那code review也是這樣, 在review之前, 先大家一起制定好code standard, 說好要尊守這個standard,也了解狀況後, 再依據standard做code review, 只要符合standard的話, 裡面怎麼寫那就是coder的自由, 不會造成"問題"的話, reviewer不應該去干涉coder的寫法, 畢竟程式這種東西還是有些地方是主觀的, 管太細會引起不必要的爭執, 我本身是很認同要有code review, 但我發現很多人,好像是想要表現出自己很強, 就會把code review弄得很像是批鬥大會... code review對我來說主要目的就兩個, 一個是確認code有沒有符合"大家約定好的"standard, 二個了解對方怎麼寫,而不是要逼對方怎麼寫, 若在code review時刁別人, 並不會讓別人覺得reviewer很強, 只會讓別人覺得這個reviewer很閒或存心找碴, 我是曾經遇過2種不好的code review, 第一種是老鳥沒有遵守code standard, 也不用被code review, 而我呢,是新人,就被code review啦, 我原本程式寫成A,被code review後, 被要求改成B,再被code review後, 被reviewer指責說為什麼要寫成B, 要我改回A... 我心裡就覺得這reviewer是來亂的... 第二種是reviewer程式功力很差, 他不會用function, 而我遇到重覆的code會寫成function, 他看到function就要我把function拿掉, 唸說寫function別人會"看不懂".. 原PO真的不用難過啦, 我自己寫case 1的時候, 我的寫法也是和你一樣的, 你前主管沒看過的話, 那真的程式看得太少了... 我自己是遇過一種狀況, 我刮號會習慣打成 if(){ XXX; } 但我有個前同事看到我這樣寫,就罵我亂寫,他只看得懂 if() { XXX; } 我也好奇大家會怎麼看待這件事, 我對code review這件事也是有些感慨, 本來是一件很好的事, 結果常常被扭曲成"政治工具" ※ 引述《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沒看過 : 她直接在辨公室裡開飆 : 2. : reviewer說出了我聽說最莫名奇妙的一句話 : "這function以前沒人用過 所以你不能用這function" : (jquery的trigger) : 不是因為效能 不是因為安全問題 而是因為公司前人沒用過.... : 我第一次遇到會規定coding style的公司 : 一開始以為是檢到寶 : 後來沒想到工作沒滿試用期就離職了.... -- 寫程式是一種信仰， 寫得出來是一種藝術， 寫不出來是一種哲學。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.224.80.33 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410275065.A.CAB.html
推
09/09 23:17, , 1F
JAVA我會把{放行尾 C++會換行
09/09 23:17, 1F
→
09/09 23:17, , 2F
為什麼呢?
09/09 23:17, 2F
→
09/09 23:18, , 3F
奇怪的習慣 不過行尾好像符合google的style
09/09 23:18, 3F
→
09/09 23:19, , 4F
主要是建立習慣時期看他人的code學下來的吧
09/09 23:19, 4F
→
09/09 23:19, , 5F
在公司是只寫過Java啦 規定是行尾
09/09 23:19, 5F
→
09/09 23:20, , 6F
你習慣真特別XD
09/09 23:20, 6F
→
09/09 23:22, , 7F
go fmt 下去大家 code 都長一樣 超棒的
09/09 23:22, 7F
推
09/09 23:27, , 8F
{放行尾就 K&R 風格啊，一堆人在用的東西說沒看過...
09/09 23:27, 8F
推
09/09 23:28, , 9F
比較喜歡換行，這樣括號才有對稱性看起來舒服
09/09 23:28, 9F
→
09/09 23:29, , 10F
叫那個阿菜reviewer查一下K&R，真的是菜蟲掉滿地XD
09/09 23:29, 10F
→
09/09 23:52, , 11F
我還以為是javascript
09/09 23:52, 11F
推
09/10 00:00, , 12F
askacis正解!!
09/10 00:00, 12F
推
09/10 00:49, , 13F
golang 讚讚
09/10 00:49, 13F
推
09/10 01:49, , 14F
我的習慣跟一樓一樣耶
09/10 01:49, 14F
推
09/10 06:05, , 15F
我是習慣用第二種，不過我是用Whitesmiths style
09/10 06:05, 15F
→
09/10 06:06, , 16F
不過這點我覺得真的就是有固定、不要混用就好...
09/10 06:06, 16F
→
09/10 08:29, , 17F
整個公司都不會用function的團隊會決定要code r ...?
09/10 08:29, 17F
推
09/10 09:18, , 18F
括號兩種都看過,我都用耶.
09/10 09:18, 18F
推
09/10 10:23, , 19F
個人覺得括號只是潔癖而已混用也無所謂在意這個很無聊
09/10 10:23, 19F
→
09/10 10:24, , 20F
如果位置會造成閱讀上的影響那代表你括號太多層了
09/10 10:24, 20F
推
09/10 10:28, , 21F
ㄓ音文也看得懂阿，不影響閱讀嗎
09/10 10:28, 21F
推
09/10 10:37, , 22F
我也支持go fmt
09/10 10:37, 22F
推
09/10 10:43, , 23F
看樣子還是需要標準化的美化工具, 工具之前人人平等 ;)
09/10 10:43, 23F
→
09/10 10:44, , 24F
至於風格什麼的, 真的就只是看得順不順眼而已, 影響才沒那
09/10 10:44, 24F
→
09/10 10:45, , 25F
麼大, code寫得夠久的話, 各種風格都會經歷過, 為這個起爭
09/10 10:45, 25F
→
09/10 10:45, , 26F
執真的是無事忙而已
09/10 10:45, 26F
→
09/10 10:47, , 27F
code review 的重點應該擺在這 code 是否符合一些資料安全
09/10 10:47, 27F
→
09/10 10:48, , 28F
還可以來戰tab還是space 我認為全形空白以外都是垃圾
09/10 10:48, 28F
→
09/10 10:48, , 29F
性, 易讀性, 結構性, 演算上的效率這些項目上, 而不是在搞
09/10 10:48, 29F
→
09/10 10:48, , 30F
形式
09/10 10:48, 30F
→
09/10 10:55, , 31F
沒錯，有各種風格，沒什麼好壞，只是從中選一個，但糟
09/10 10:55, 31F
→
09/10 10:55, , 32F
糕的是有人的心態變成是去瞧不起別人
09/10 10:55, 32F
→
09/10 11:02, , 33F
看了大家的討論，好像愛review 別人的人，coding 就不
09/10 11:02, 33F
→
09/10 11:02, , 34F
怎麼樣的感覺，半瓶水響叮噹
09/10 11:02, 34F
→
09/10 11:03, , 35F
因為講不出東西的時候挑剔風格最容易啊XD
09/10 11:03, 35F
→
09/10 11:05, , 36F
見過大陣仗看過許多code 的人，只會在意bug 和效能這
09/10 11:05, 36F
→
09/10 11:05, , 37F
種比較實際的東西，而非雞皮蒜毛，也沒空管小事
09/10 11:05, 37F
推
09/10 12:33, , 38F
其實現在很多code都是從網路上抓下來安裝引用, 甚至是直接
09/10 12:33, 38F
→
09/10 12:33, , 39F
嵌入到自己的code當中, 若真的要求code style的風格一致的
09/10 12:33, 39F
→
09/10 12:34, , 40F
話, 那天天就改這些code就飽啦 :P
09/10 12:34, 40F
→
09/10 12:36, , 41F
而這些公開發佈的code已有一定的可信度了, 為了code style
09/10 12:36, 41F
→
09/10 12:36, , 42F
是否一致而改code, 衍生出一些莫名其妙的bug 又要debug,那
09/10 12:36, 42F
→
09/10 12:36, , 43F
真的是補鍋師傅在幹的事
09/10 12:36, 43F
→
09/10 13:42, , 44F
同一樓 其實就是看現在寫的程式碼通用的習慣是什麼
09/10 13:42, 44F
→
09/10 13:42, , 45F
像kernel的function不放尾行 但if放尾行這種也是有呀
09/10 13:42, 45F
→
09/10 13:43, , 46F
無法接受 bobju 說的 "目前很多 code 都直接抓下來引用"
09/10 13:43, 46F
→
09/10 13:44, , 47F
的說法, 抓下來的東西的 code 長什麼樣子我是管不著, 但
09/10 13:44, 47F
→
09/10 13:44, , 48F
要使用這種像 open source 的東西一定都會先 build 成
09/10 13:44, 48F
→
09/10 13:45, , 49F
library 的型式, 不然出事了怎麼切分問題或責任所在呢?
09/10 13:45, 49F
→
09/10 16:37, , 50F
沒build 是還ok ，但要獨立成不同檔案，不要和自己的co
09/10 16:37, 50F
→
09/10 16:37, , 51F
de 混在一起
09/10 16:37, 51F
→
09/10 17:48, , 52F
抓下來的code不build要怎麼用XD 一般都直接build library
09/10 17:48, 52F
→
09/10 17:49, , 53F
在自己的code裡呼叫library，很少數情況下才會抽code出來
09/10 17:49, 53F
→
09/10 17:49, , 54F
跟自己的Code綁在一起build~
09/10 17:49, 54F
→
09/10 17:51, , 55F
通常都是嵌入式環境下求快以及減少flash size才會考慮~
09/10 17:51, 55F
‣ 更多 littlethe 的文章
文章代碼(AID): #1K3nRvoh (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 15 之 21 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共21篇)
‣ 更多 littlethe 的文章
文章代碼(AID): #1K3nRvoh (Soft_Job)