Re: [討論] 寫三元判斷式code review被打槍
這讓我想到Linus本人在TED上舉的linked list例子
以下借用Jserv老師的文章內容
(https://hackmd.io/@sysprog/c-linked-list)
1. Non elegant linked list remove
https://i.imgur.com/frZ4cmO.jpg
2. Elegant version
https://i.imgur.com/JzMxI0D.jpg
第一種好讀第二種更簡潔效能更好
但到底哪一種比較好呢？
回到主題 code review 的其中一個原則是要好讀易懂
但如果當某種進階寫法已經是team members都認為很易懂時為何不行？
※ 引述《a88241050》之銘言
: 小弟寫java的
: 以前常常寫三元判斷式
: 就比如說
: String a;
: if(con) {
: a= "aaa";
: } else {
: a="bbb";
: }
: 這樣就要佔掉六行
: 所以我通常都是寫
: String a= con ? "aaa" : "bbb";
: 從五行變成一行
: 在我看來簡潔又方便
: 但最近給一個資深前輩code review的時候
: 他說不要用三元判斷式
: 因為不好閱讀
: 他工作那麼久也從來不用三元判斷式的
: 而且java有很多套件都可以用來取代三元判斷式
: 所以用三元判斷式真的不好嗎？
----
Sent from BePTT on my iPhone 14 Pro Max
--
我比較喜歡dummy prehead, indirect比較不直覺
如果你指的是team member 隨時都處在第二種coding style
下coding 當然ok, 但我想多數人的現實還是都在第一種
這是底層function不是商業邏輯，你會頻繁改動的那種
如果場景的確需要壓出這些資源，那就是用2，像nasa
如果第二種效能明顯較好我會選二。兩個都不難讀
linus 是我偶像.但我知道他已經不是大多數人的偶像了..
Linus在的團隊第二種難的寫法也都算簡單 但一般人也進不去
啊
好讀好維護的本質是為未來改動做準備，底層不會被改
到的東西當然效能優先
好不好讀是看你team member的程度
第一種比較好讀 第二種稍微要看仔細一點點 但如果兩種都
看懂，我覺得第二種倒是比較符合一般人類現實中的做法
兩種要選的話我會選第二種 XDD 純粹只是syntax稍微要細看
但邏輯上更直覺
(只是那pointer的naming....indirect好像有點不太具體)
第二種過一段時間再回來看，應該會覺得當時很厲害
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 沒有這些![Re: [討論] 寫三元判斷式code review被打槍](https://i.imgur.com/cyrFsY4b.jpg "Re: [討論] 寫三元判斷式code review被打槍")
藉這個主題問各位一個問題。 我想知道怎麼樣的語法才是公認最簡潔最沒有歧異 的語法？我在wikipedia 是看到一本暱稱「K&R 白 皮書」的C 語言教科書，這本書是C 語言的始祖等 級教科書，有些人認為這本書所寫的語法才是程式5
沒有 沒有什麼公認 要解決coding style 最好的辦法就是CTO大頭召集全部RD開會 把這間公司的coding style全都記下來8
這種事情 不就和阿里巴巴一樣 一開始給大家一本手冊 哪些code 或是哪些style在本公司不要出現![Re: [討論] 寫三元判斷式code review被打槍](https://external-preview.redd.it/6TTm4tS5pMCiq2KlgviubpGKt1QzvetOi2Z6Z3lB1Nc.jpg?width=720&height=376.963350785&auto=webp&crop=720:376.963350785,smart&s=dc5cf91d8f054bb9b0588dbda44272c6eb1e7b19 "Re: [討論] 寫三元判斷式code review被打槍")
1X
隨著語法的進步 很多會寫 code 的人都很少寫判斷式了 不管是三元還是 if else 寫太多的判斷式 如果….所以…否則…如果….則又…如果..24
說到switch，想來問問你各位公司的code style是下面哪種 (1) switch Var1 { case a: xxx![Re: [討論] 寫三元判斷式code review被打槍](https://i.imgur.com/VBSwkjeb.jpg "Re: [討論] 寫三元判斷式code review被打槍")
5
好啦 假設不是反串 我覺得滿有道理的 但有一點其實你說錯了 其實並不是語法進步 之前學 Rust 覺得哇 pattern matching 真是他媽神 好潮喔 後來跑去學 OCaml 我才發現(Rust設計者是OCaml粉 一開始的compiler就是用OCaml寫)
15
Re: [請益] 如何有效率的看code ?如果你沒寫錯的話 一年多看幾萬行code真的不多 我也是轉職仔，原本在ic house寫C做韌體，一個人負責一個.c/.h檔。一年才進三行code。 轉職後寫C++整個team大約十多人，負責的那一層有兩千萬行code。然後第一年就進快一萬行code。 我原本不會C++的，所以什麼framework，modern C++，design pattern，multithreaded 之類的都沒學過要重學。
Re: [討論] 寫三元判斷式code review被打槍這邊不針對效能，也不針對說階層太多，應該用什麼方式重構之類的 只是看到有人提到巢狀的三元運算子，閱讀性太差，應該改回用if else寫 我只是好奇兩者的可讀性有差很多嗎？ 以下只是舉例，不是指實務上會真的這樣寫 (1) 三元運算子：![Re: [討論] 寫三元判斷式code review被打槍](https://img.youtube.com/vi/CFRhGnuXG-4/mqdefault.jpg "Re: [討論] 寫三元判斷式code review被打槍")
5
Re: [討論] 寫三元判斷式code review被打槍最近公司讀書會在看 Martin Fowler 的 Refactoring， 大概第九或第十章他有用到三元 sample code 大概是這樣 const price = summer()? summerPrice() : commonPrice(); 然後我們有看這串文章討論了一下5
Re: [討論] 寫三元判斷式code review被打槍review code 的時候， 對code style 有意見的人真很呵呵， 真的要對code style 有意見，麻煩就寫進code style checker, 如果在commit 之前的 code style checking 都過了， 就不要在這上面花時間，不然會沒完沒了。 因為有更多更重要的事要討論，