Re: [討論] 寫三元判斷式code review被打槍
review code 的時候, 對code style 有意見的人真很呵呵,
真的要對code style 有意見,麻煩就寫進code style checker,
如果在commit 之前的 code style checking 都過了,
就不要在這上面花時間,不然會沒完沒了。
因為有更多更重要的事要討論,
如何抽象化、file strcture, time complexity, memoery complexity,
db query cost, lock...
一個人的時間有限,請妥善利用...
--
※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 219.68.121.149 (臺灣)
※ PTT 網址
→
LGTM
→
現在不就是在吵coding style checker 要發落誰的嗎?
→
挑一個合理的就好啊,重點這東西不該在code review
→
的時候拿出來討論,依經驗來說很浪費時間
→
就大頭們討論完寫進去checker就好
推
推
推
那光有coding style卻沒有checker的公司怎麼辦
→
人蠢是沒有極限的,一大堆魚目混珠的寫法列舉不完的
推
會要求code style的公司就會有checker吧
推
真的 看完整串後我也有這麼想 除非寫要在有限資源下榨效能的
→
程式 不然追究這個沒啥意思 我自己code review 比較大還是注
→
意整體架構 思路 邏輯關係
推
LGTM
95
首Po小弟寫java的 以前常常寫三元判斷式 就比如說 String a; if(con) {18
三元不能用 算還好了 我還遇過 a=1; ... ...11
Code review 檢查這些會有點太花時間,應該有更重要的東西要看。 可以用一些 Gradle plugins 卡在 CI 比較省事: 1. Checkstyle 顧名思義檢查 style。 2. SpotBugs12
從 C++ 的角度來說 三元運算子有機會改變 l-value/r-value 的性質,進而破壞最佳化 舉個簡單例子 可以看到用三元運算子的時候,回傳區域變數竟然要 copy 而不是 move 雖然說 Java 沒有這些5
沒有 沒有什麼公認 要解決coding style 最好的辦法就是CTO大頭召集全部RD開會 把這間公司的coding style全都記下來8
這種事情 不就和阿里巴巴一樣 一開始給大家一本手冊 哪些code 或是哪些style在本公司不要出現1X
隨著語法的進步 很多會寫 code 的人都很少寫判斷式了 不管是三元還是 if else 寫太多的判斷式 如果….所以…否則…如果….則又…如果..24
說到switch,想來問問你各位公司的code style是下面哪種 (1) switch Var1 { case a: xxx5
好啦 假設不是反串 我覺得滿有道理的 但有一點其實你說錯了 其實並不是語法進步 之前學 Rust 覺得哇 pattern matching 真是他媽神 好潮喔 後來跑去學 OCaml 我才發現(Rust設計者是OCaml粉 一開始的compiler就是用OCaml寫)
27
Re: [討論] 怎麼跟自以為是的同事相處提供一點不一樣的看法 ※ 引述《leo5916267 (封膜獵人)》之銘言: : 也許在軟體也蠻容易遇到類似個性的同事 : 我們是新創公司,我進去前已就有一個前端工程師,他從0建構了整個產品A 代表他能力不算差5
Re: [討論] 寫三元判斷式code review被打槍最近公司讀書會在看 Martin Fowler 的 Refactoring, 大概第九或第十章他有用到三元 sample code 大概是這樣 const price = summer()? summerPrice() : commonPrice(); 然後我們有看這串文章討論了一下