Re: [討論] 寫三元判斷式code review被打槍
三元不能用 算還好了
我還遇過
a=1;
...
...
if (xxx) a=2;
不能這樣寫 請改成
if (xxx) { //還可以戰一下這個{要不要去下一行
a=2;
}
以免有人沒看到那個一行if後面有assign value
這種事情就是看話語權啦
每個人看code習慣不同
--
什麼話語權 這是團隊規範該做的好嗎
第一種寫法正常人看到都會罵吧
第一種寫法比三元還差..
這只是coding style根本沒統一而已吧
原來不只我討厭第一種寫法
if(xxx)
a=2;
b=3;
如果是if(xxx) return、break就算了 上面這種更糟
第一種在幹嘛....為啥不直接宣告在if上面要離那麼遠
我的舉例意思是a=1跟a=2中間有別的code啦 不是所有狀況都可以先做完別的事情最後再來a=(cond)?1:2 這時候到底要寫成if (cond) a=2;一行還是拆開有大括號 啊就看有權決定的人爽就好
還跟別行程式並排在一起
style很漂亮的糞code,至少對公司說的過去
第一個太爛了吧 為了縮排而縮排比三元更沒意義
這是在講縮排嗎 這個不是講好就好
縮減行數
我們這邊只要有if就強制加大誇號就算是空body也一樣
有{}還是比較好啦 雖然現在CODE只有一行 未來要加
如過以google java style來講大夸號是必加不能省
其他行程式也比較不會出錯 沒{}的寫法真的就裝逼~
剛學程式時也喜歡那些寫短的code 好像越短越強
第一種寫法除非你以後絕對不會改到 不然維護上很常出錯
但工作久了反而覺得可讀性高的程式重要多了
之前寫個迴圈 同事還叫我把所有邏輯寫在迴圈裡 說這
我也討厭if(xxx) a=2;這種一行式的 就難看
樣只要一個迴圈就處理完 效能較快 但可讀性就很差
面試看到 if else不加大括號的 都直接先扣分... 整個看起
來有夠醜
不過這些在convention裡面定好就好
看起來有大括號是顯學?
一行分號我倒是不介意 只要a不出錯後面都可以無視
一開始可能還好 但函式在擴展時 邏輯可能會變多 然後一
旦一開始沒有大括號 後面就也不會加 最後就是 if(xxx) a;
b; c;....一直加下去 可讀性極差
if-else 有無大括號影響可以很大
其實看不爽就看ide的格式化功能幾個按鍵搞定
其實我是兩種都接受 總不能寫錯程式的時候跟老闆說那個XXX if else格式寫不對害我看錯
code就是訂定好協議 風格一致比較好看 一下{換行一下
{不換行接後面 不一致就是難看而已
第一個就算是Google 的coding style 都會把他處理掉好嗎
?
第一個我是遇過變數集中函式集中宣告強迫正 所以會離很遠
真的很討厭第一種寫法
你可以換個環境,寫 ruby 吧
Coding Style的討論我覺得很浪費時間,最近都是丟給特別有意
見的成員,讓他們自己去formatter的設定檔上面編輯戰,再讓CI
跑過後,Code review 就快多了。
大家碰到這個要換行嗎? public int Goo { get; set; }
我看過getter setter保底六七行的 全換行 好醜
加括號是習慣吧!以後裡面加code才不會生出bug難解
加一下不會花你多少時間空間,減少以後出錯debug時間
第一個確實應該改。而且 styling check 就跑不過了
寫書寫筆記為了避免排版跟篇幅問題可以那樣寫, 實際上開發
會儘量避免
笑死 這不是會寫c,就要知道的事嗎
為什麼一定要用大括號
真假啦 第一種這麼討人厭哦...
不爽括號不會用蟒蛇嗎
我都用ide把大括號設成背景色
寫一行的那種coding style應該是前端框架才有機會看到吧
我都看心情有時候第一種有時候第二種給你參考
第一種我只有return才會這樣寫
只是括號縮排講好就好 根本沒那麼重要好嗎…
大括號一定要加的 不管幾行 你不加括號 送review被嘴只
是剛好
單行不加括號是很糟糕的壞習慣
討厭不換行+1 而且還不+大括號很煩人
掛號是一定要寫的
不寫括號習慣太差
第一種真的很雷
1.a=>b+c; 2.a=>{b+c;}哪個好
寫個括號很難嗎
討厭不換行
拜託你至少斷行
if (c) a=2; 有比 if (c) a=2; 好?
※ 編輯: brucetu (220.135.153.214 臺灣), 12/14/2022 21:33:25第一種寫法等同於埋地雷給新人踩
一個55分 一個50分 不要在不及格的東西上爭論 乖乖加
括號就是 不然gerrit上肯定有人送你個紅色大叉叉
更正 gerrit->code review system
至於左括號要刮在if()後面還是跳一行 拜託你看一下原本
的repo裡面怎麼寫的 照著寫 不要標新立異(而且這是很沒
創意的標新立異 沒人會appreciate你的點)
有
自己的專案寫一行沒差,多人的專案就是埋坑給別人跳
而且 google code style 就跟你說要加大括號了
老實說 單純你自己覺得好
大括號必加
if要加大括號+1
加大括號比較好 之前Apple就有個有名bug: goto fail
如果有加大括號也能避免
這種會被罵只能說活該 自以為很簡潔= =
第一種寫法其實有人推崇,但還是第二種可讀性高
第一種寫法團隊開發不建議這樣
Google Coding Style 在某些狀況下還是允許不加大括號
上面貼錯@@ https://tinyurl.com/bda4b8wa
只有說歷史原因在特定情況下可省 但沒建議你省略
記得之前一個很有名的安全性漏洞 就是沒加大括號造成的
然後讓一堆公司忙著修補
Coding style 不過 正常啊
現代自動檢查 你這一定被抓啊
我就是不想寫大括號才寫 Python
我喜歡大括號,但不排斥 Python:)
coding style 遵守很難嗎...爭這個幹嘛
很多bug 都是沒有大括號來的
第一種不就Kotlin 常見寫法嗎?不奇怪吧
Kotlin那有第一種寫法.... 你說的kt寫法應該是 val a = i
f(true) xx else xx
原po第一種是 if(true) a = xx
就算是kt 比較穩妥的team 也都是寫 val a = if(true) { x
x } else { xx }
你不加大括號 就算是kt 裡面邏輯一旦變多 一樣是爆炸好
嗎
不加大括號本來就是給單行用的,就是讓最精簡的寫法
能夠更精簡,多行當然用括號,第一個寫法kt是能用的
,而且也常常當三用運算子用
var v = if (a) b else c
不寫括號就是為了讓單行的精簡度更高,習慣了也不會
影響閱讀甚至更流暢,多行不加括號已經不是設計本意
了,我自己理解是只有單行可以不加
連單行都會被check style 要求要加好嗎?
因為沒有大括號引發bug應該還是寫的人的問題 自己眼殘加
上測試不足
不過規定一律要加以防有人犯錯我是可以認同啦
kt style有指明可以單行不括號,不知道大家在激動啥..
還是要看Team size啦 如果只是10-20個人維護的中小型專
案 可能自己定好style 測試嚴謹就行 但如果是幾百人維護
的超大型專案 不加真的很常被後面的人越寫越醜... 畢竟你
不能保證所有人都跟你一樣 看到邏輯擴展時會reformat cod
e 加上括號抽出邏輯 等到你回頭看的時候 常常已經面目全
非
Kt style單行不加沒錯 但單行指的是你邏輯簡單到不行 而
且確認不可能會擴展 不然基本上還是加了比較安全
我也經常第1種寫法 第2種寫法是很浪費程式碼空間的
而且也並不難懂 只是習不習慣有沒有偏見
至於bug倒是不會 因為本例就是純粹指派值 如果有多餘
的設置 當然用括號 也不會有人一連串if
程度碼空間有限?
比起這個我還覺得分號比較重要
當然理論上沒上限 但你要好維護 當然要選擇當下條件
下最簡潔的寫法
boabomb說的還要糟過三元...
…這比三元還爛 把作用域包好很難嗎
在某些條件下可以接受三元,但沒有大掛號不行
樓上... Kotlin的if是表達式 所以沒有ternary operator J
ava的三元 如果純賦值且邏輯簡潔的話沒什麼問題 但Kt你要
賦值一行式就是得 if else
你if else沒有大括號 後面絕對超容易被改爛 尤其是Kotlin
這種語法 單幹就算了 幾百人寫的repo你不加 真的很容易被
新人搞爛
都要2023年了 什麼叫做浪費程式碼空間 XDDD
會在意程式碼空間多於維護性的 要嘛是在極為limited的資
源(ram, disk)下寫程式 要馬是每寫過百人以上專案 不然
就是程式寫得不好 通常是後兩者居多就是
沒寫過*
寫節省程式碼 該用的是OO技巧 而不是在這方面計較
隨便做個refactor 把duplicate code拉到一個函式 節省
的空間至少是三元運算子能節省的好幾倍
跟薪水也依樣 很多人在討論好好幹IT 年薪150沒問題
殊不知豬屎屋的起薪一堆就幹掉150了 IT怎麼努力也沒用
就跟把if else改成三元運算節省空間依樣 沒用 太侷限
同意樓上.. 程式碼空間應該靠的是oo 良好的DI 以及適當
的refactoring.. 而不是什麼非得要一行.
google apple goto fail
我被第一種寫法弄過
本來就該加括號,沒括號是在哭?
看到不加括號火都上來
擴充 會放陷阱害人
Google的Java style確實有說都要加括號,但Kt style沒有.
反正大家都按自己喜好跟公司傳統在吵,guidance沒人在乎
OO現在很多也推行少用...維護起來太煩了
leetcode 很常看到第一種寫法, 但是我不會在PROD幹這種事
在 OA 寫的時候我會先跟面試官聲明
因為 java 寫 leetcode 實在太囉嗦了
java本身就是OO 你不寫OO也得OO 把相同的功能封裝是
正常人都會做的事情 但用三元的例子本身就是單純案例
重點這種簡易判斷出現不會只有一次 出現的很頻繁 省
下的程式碼空間和看長程式碼需要的暫時記憶以及如果
找程式碼都是有幫助的
s/如果//
java也並非只有OO 也可以搭配FP 不明白這年頭為何開
口閉口OO以及DI 樓主的例子要擴充加括號就好 本身第1
種寫法也不是什麼不常見的做法
至於kt如果只能如此那就沒辦法 有沒有過譽嫌疑我不知
道 但以這例子來說確實糟糕
正常人會括號
你應該是沒做過甚麼大project
你連括號都不知道要加 才跟你提OO 怕你不知道呀
有阿 大型專案都很亂 你看一下樓主的例子 括號是否必
要 要加括號的時候自然會加
沒有人會覺得用第一種寫法 如果一樣條件要增加程式直
接放下面會能跑的...
查了一下 kt可以不用分號也可以用 但分號很好
只有shell我才不加分號 因為它同行分割需要'\'
要括號
不喜歡每次還要去幫你加括號我才能塞其他東西
不加括號以後需求改了要多加一行你不是還是要括號
那你為什麼要省那個括號
Linux kernel style是換行不加括號,看話語權沒錯XD
推樓樓上
如果要改再一起加好了不是?精簡時最精簡不是很好嗎
?
不懂少一個括號是有什麼好處?少打一些字??看了就賭爛
95
首Po小弟寫java的 以前常常寫三元判斷式 就比如說 String a; if(con) {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寫)9
"特定"情況下的確是好方式 舉個例子 以前我在調校能時候有用過這種方式 這是c#的code部分節錄 void Mem_w(ushort address, byte value) { if (address < 0x2000) NES_MEM[address & 0x7ff] = value;
40
[問卦] 程式能寫if 就不要用for loop?以前寫程式覺得要看起來厲害 明明能用if的 我會先建一個table 然後再用for loop尋找 好處是數量增加時增加的程式碼少 壞處是寫的時候和以後回來看的時候比較麻煩21
[爆卦] 急!!github壞掉怎麼下班幹肥宅就差這一版push上去就能下班了 結果GitHub壞了 網頁版9
[問卦] 寫code這麼簡單憑什麼領高薪?寫程式不就if else就打天下了嗎? 真的不會寫的功能就藍色小舖找找copy一下就好了 這麼簡單的工作到底是憑什麼領高薪啊? 有掛嗎? -----16
Re: [請益] 為何升三息 美股卻是往上噴?所以今天的美股解答到你的疑惑了嗎?? 劇本跟5/5號FED宣布升兩碼一模模一樣樣 還好上次被騙過一次這次沒被騙 順便抱怨一下已反應這個詞 今天早上很多人在說什麼已反應啊or股市不會等真的升息才反應啊~12
Re: [心得]以策略模式重構switch case或if (影片)終於有空來加入討論啦~ 這邊有 markdown 好讀版: 這邊我也來提一下我的看法。為了閱讀方便我把一些 code snippet 複製在這邊: ```java= public double shippingFee(String shipper, double length, double width, double