Re: [討論] 寫三元判斷式code review被打槍

看板Soft_Job作者 (sec)時間1年前 (2022/12/14 13:54), 1年前編輯推噓23(42推 19噓 166→)
留言227則, 70人參與, 1年前最新討論串2/15 (看更多)
三元不能用 算還好了 我還遇過 a=1; ... ... if (xxx) a=2; 不能這樣寫 請改成 if (xxx) { //還可以戰一下這個{要不要去下一行 a=2; } 以免有人沒看到那個一行if後面有assign value 這種事情就是看話語權啦 每個人看code習慣不同 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.135.153.214 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1670997244.A.3F0.html
推
12/14 14:10, 1年前 , 1F
什麼話語權 這是團隊規範該做的好嗎
12/14 14:10, 1F
→
12/14 14:24, 1年前 , 2F
第一種寫法正常人看到都會罵吧
12/14 14:24, 2F
→
12/14 14:25, 1年前 , 3F
第一種寫法比三元還差..
12/14 14:25, 3F
→
12/14 14:28, 1年前 , 4F
這只是coding style根本沒統一而已吧
12/14 14:28, 4F
噓
12/14 14:32, 1年前 , 5F
原來不只我討厭第一種寫法
12/14 14:32, 5F
→
12/14 14:33, 1年前 , 6F
if(xxx)
12/14 14:33, 6F
→
12/14 14:33, 1年前 , 7F
a=2;
12/14 14:33, 7F
→
12/14 14:33, 1年前 , 8F
b=3;
12/14 14:33, 8F
→
12/14 14:34, 1年前 , 9F
如果是if(xxx) return、break就算了 上面這種更糟
12/14 14:34, 9F
→
12/14 14:34, 1年前 , 10F
第一種在幹嘛....為啥不直接宣告在if上面要離那麼遠
12/14 14:34, 10F
我的舉例意思是a=1跟a=2中間有別的code啦 不是所有狀況都可以先做完別的事情最後再來a=(cond)?1:2 這時候到底要寫成if (cond) a=2;一行還是拆開有大括號 啊就看有權決定的人爽就好
→
12/14 14:35, 1年前 , 11F
還跟別行程式並排在一起
12/14 14:35, 11F
推
12/14 14:35, 1年前 , 12F
style很漂亮的糞code,至少對公司說的過去
12/14 14:35, 12F
→
12/14 14:35, 1年前 , 13F
第一個太爛了吧 為了縮排而縮排比三元更沒意義
12/14 14:35, 13F
→
12/14 14:37, 1年前 , 14F
這是在講縮排嗎 這個不是講好就好
12/14 14:37, 14F
→
12/14 14:38, 1年前 , 15F
縮減行數
12/14 14:38, 15F
→
12/14 14:38, 1年前 , 16F
我們這邊只要有if就強制加大誇號就算是空body也一樣
12/14 14:38, 16F
→
12/14 14:39, 1年前 , 17F
有{}還是比較好啦 雖然現在CODE只有一行 未來要加
12/14 14:39, 17F
→
12/14 14:40, 1年前 , 18F
如過以google java style來講大夸號是必加不能省
12/14 14:40, 18F
→
12/14 14:40, 1年前 , 19F
其他行程式也比較不會出錯 沒{}的寫法真的就裝逼~
12/14 14:40, 19F
→
12/14 14:41, 1年前 , 20F
剛學程式時也喜歡那些寫短的code 好像越短越強
12/14 14:41, 20F
→
12/14 14:41, 1年前 , 21F
第一種寫法除非你以後絕對不會改到 不然維護上很常出錯
12/14 14:41, 21F
→
12/14 14:41, 1年前 , 22F
但工作久了反而覺得可讀性高的程式重要多了
12/14 14:41, 22F
→
12/14 14:42, 1年前 , 23F
之前寫個迴圈 同事還叫我把所有邏輯寫在迴圈裡 說這
12/14 14:42, 23F
→
12/14 14:42, 1年前 , 24F
我也討厭if(xxx) a=2;這種一行式的 就難看
12/14 14:42, 24F
→
12/14 14:42, 1年前 , 25F
樣只要一個迴圈就處理完 效能較快 但可讀性就很差
12/14 14:42, 25F
→
12/14 14:44, 1年前 , 26F
面試看到 if else不加大括號的 都直接先扣分... 整個看起
12/14 14:44, 26F
→
12/14 14:44, 1年前 , 27F
來有夠醜
12/14 14:44, 27F
→
12/14 14:45, 1年前 , 28F
不過這些在convention裡面定好就好
12/14 14:45, 28F
看起來有大括號是顯學?
→
12/14 14:48, 1年前 , 29F
一行分號我倒是不介意 只要a不出錯後面都可以無視
12/14 14:48, 29F
→
12/14 14:49, 1年前 , 30F
一開始可能還好 但函式在擴展時 邏輯可能會變多 然後一
12/14 14:49, 30F
→
12/14 14:49, 1年前 , 31F
旦一開始沒有大括號 後面就也不會加 最後就是 if(xxx) a;
12/14 14:49, 31F
→
12/14 14:49, 1年前 , 32F
b; c;....一直加下去 可讀性極差
12/14 14:49, 32F
推
12/14 14:54, 1年前 , 33F
if-else 有無大括號影響可以很大
12/14 14:54, 33F
→
12/14 14:54, 1年前 , 34F
其實看不爽就看ide的格式化功能幾個按鍵搞定
12/14 14:54, 34F
其實我是兩種都接受 總不能寫錯程式的時候跟老闆說那個XXX if else格式寫不對害我看錯
→
12/14 15:09, 1年前 , 35F
code就是訂定好協議 風格一致比較好看 一下{換行一下
12/14 15:09, 35F
→
12/14 15:10, 1年前 , 36F
{不換行接後面 不一致就是難看而已
12/14 15:10, 36F
還有 155 則推文
還有 11 段內文
推
12/17 11:52, 1年前 , 192F
不加括號以後需求改了要多加一行你不是還是要括號
12/17 11:52, 192F
→
12/17 11:53, 1年前 , 193F
那你為什麼要省那個括號
12/17 11:53, 193F
之後加跟現在加有差這麼多嗎 一定要一開始就加在那邊? 我覺得還是可讀性問題 少了括號是真的有這麼難讀? 各位眼睛還好嗎?
推
12/17 16:16, 1年前 , 194F
Linux kernel style是換行不加括號，看話語權沒錯XD
12/17 16:16, 194F
推
12/17 17:42, 1年前 , 195F
推樓樓上
12/17 17:42, 195F
推
12/18 00:01, 1年前 , 196F
如果要改再一起加好了不是？精簡時最精簡不是很好嗎
12/18 00:01, 196F
→
12/18 00:01, 1年前 , 197F
？
12/18 00:01, 197F
我也覺得要改再一起加就好 不知道為什麼都要預設會改 有時候就是真的只需要改個狀態 寫在同一行搞定 未來改成兩行以上的機率非常小 會需要改成兩行的時候 可能需求已經大到根本可以拆出另一個service 原本的都砍掉
噓
12/18 00:20, 1年前 , 198F
不懂少一個括號是有什麼好處？少打一些字？？看了就賭爛
12/18 00:20, 198F
好處就是 我看了舒服 就像你覺得都有加大括號看了舒服
推
12/18 11:34, 1年前 , 199F
好吧，那就只是很多人看單行很不爽XD
12/18 11:34, 199F
目前看到不爽的理由 1.以後擴充還要幫你補括號 不爽 2.後面的人很容易改爛 不爽 還有一些系統guideline就是要加 不然你根本build不過 所以要加就是嚴格 大團隊 有標準 讚 至於有些知名專案沒在加的 那個我們先不要管它 ※ 編輯: brucetu (220.135.153.214 臺灣), 12/18/2022 11:39:00
推
12/18 13:04, 1年前 , 200F
既然你Que我了我只好多回一點了，我剛開始工作的時候也覺
12/18 13:04, 200F
→
12/18 13:04, 1年前 , 201F
得怎麼可能有人看不懂，但是工作就是沒有最誇張只有更誇張
12/18 13:04, 201F
→
12/18 13:05, 1年前 , 202F
你覺得if(XXX)
12/18 13:05, 202F
→
12/18 13:06, 1年前 , 203F
a=2; 後面改個需求後面人會自己加括號，但是就是
12/18 13:06, 203F
→
12/18 13:08, 1年前 , 204F
會有天兵直接在下面加一行b=XXX;你如果有加個括號我相信大
12/18 13:08, 204F
→
12/18 13:08, 1年前 , 205F
部分人都知道要加在括號裡面，這樣就減少這種天兵犯錯的機
12/18 13:08, 205F
→
12/18 13:09, 1年前 , 206F
會，你可能會覺得那是天兵的問題，可是前輩跟給講了會有天
12/18 13:09, 206F
→
12/18 13:09, 1年前 , 207F
兵這樣搞，你有機會減少天兵犯錯的時候，除非你很有自信你
12/18 13:09, 207F
→
12/18 13:10, 1年前 , 208F
的團隊只收菁英覺得不接受垃圾，不然你為什麼要挖洞給人跳
12/18 13:10, 208F
推
12/18 13:14, 1年前 , 209F
萬一很不幸的哪天你接手的專案發現之前有個天兵幹了這件事
12/18 13:14, 209F
→
12/18 13:15, 1年前 , 210F
然後你還不知道這個天兵有沒有可能在所有沒括號的地方幹同
12/18 13:15, 210F
→
12/18 13:16, 1年前 , 211F
樣的事情，你可能就知道什麼是顯學，跟你講有人會看不懂不
12/18 13:16, 211F
→
12/18 13:16, 1年前 , 212F
是因為我眼睛有問題看不懂，是我真的看過有人看不懂
12/18 13:16, 212F
推
12/19 17:36, 1年前 , 213F
推樓上~Apple的goto fail也是例子
12/19 17:36, 213F
噓
12/19 19:53, 1年前 , 214F
純噓用Leetcode的coding style來比較
12/19 19:53, 214F
→
12/19 19:56, 1年前 , 215F
*用Leetcode上看到的
12/19 19:56, 215F
推
12/19 22:46, 1年前 , 216F
有大括號才是好習慣喔...
12/19 22:46, 216F
推
12/20 02:14, 1年前 , 217F
LK 你會被挑
12/20 02:14, 217F
噓
12/21 01:53, 1年前 , 218F
單行不括號很醜 大型專案也不好維護 其他有括號突然來一
12/21 01:53, 218F
→
12/21 01:53, 1年前 , 219F
行沒有的還不是閱讀困難
12/21 01:53, 219F
→
12/21 01:55, 1年前 , 220F
這不是為了自己方便 而是為了大家方便 與其等別人眼殘改
12/21 01:55, 220F
→
12/21 01:55, 1年前 , 221F
錯再來罵不如先加
12/21 01:55, 221F
→
12/21 01:57, 1年前 , 222F
也沒什麼看不看舒服的問題 單純減少可能出錯的機會
12/21 01:57, 222F
→
12/21 02:01, 1年前 , 223F
看到你有回論對錯什麼的 大家是在共同合作才盡量減少別人
12/21 02:01, 223F
→
12/21 02:01, 1年前 , 224F
出包 而不是出包後花時間檢討誰錯 不會幫你加快進度
12/21 02:01, 224F
→
12/21 02:02, 1年前 , 225F
除非你預設新人不會眼殘 或你們團隊不收非菁英 那我沒話
12/21 02:02, 225F
→
12/21 02:02, 1年前 , 226F
說
12/21 02:02, 226F
推
12/22 17:55, 1年前 , 227F
Apple那個是被merge程式搞的吧
12/22 17:55, 227F
‣ 更多 brucetu 的文章
文章代碼(AID): #1ZcMJyFm (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 2 之 15 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共15篇)
‣ 更多 brucetu 的文章
文章代碼(AID): #1ZcMJyFm (Soft_Job)