PTT職涯區 / Soft_Job (軟體人)

Re: [請益] 痾 遇到這種事情 是不是需要趕快離職了?

看板Soft_Job (軟體人)作者 (http://portaly.cc/tbpfs)時間4月前 (2024/07/23 14:58), 4月前編輯推噓24(24推 0噓 54→)
留言78則, 31人參與, 3月前最新討論串3/5 (看更多)
等等，我原本以為只是一個簡單的問題 居然歪樓了 推動coding conventions 可以從你我做起 像原原po的問題是 if if if if ； ； ； ； 把判斷式改過來變成 if return; if return; 即可 這個就簡單起草一份coding conventions 拿給長官review, 以後code review 看到這個問題 就直接貼連結請junior 改就好了 這種東西很多學生時期根本沒碰過 自然就會波動拳出現 跟頂不頂大沒關系 反而是senior 不知道怎麼幫助junior 才是問題 ※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言： : 我從上面的文章只看到原po說有很多if...else跟function用原本的copy過來，改一下自 : 己想修改的code : 但卻沒看到任何提到效率問題，而且if...else是O(1)，並不會拖垮速度。 : 每個人寫code的習慣不一樣， : 有的人喜歡這樣寫 : if() { : } : 有的人喜歡這樣寫 : if() : { : } : 有的人喜歡程式碼短就連在一起 : if(...) cout << "xxx"; : else cout << "bbb"; : 也有人喜歡短的程式碼連在一起 : cout << "請輸入數字月份(1~12):"; cin >> month; : 有的人喜歡命名用底線分開，如:month_arr : 有些人喜歡用小寫大寫分開，如:monthArr : 有些人不喜歡程式碼跟程式碼之間有空一行 : while { : .... : } : if() { : .... : } : for(int i = 0; i < N; i++) { : .... : } : 但有些人喜歡有空一行 : while { : .... : } : if() { : .... : } : for(int i = 0; i < N; i++) { : .... : } : 有人程式碼喜歡有空格分開 : for(int i = 0; i < N; i++) : 有人不喜歡太多空格 : for(int i=0; i<N; i++) : 以上這些都沒有錯，沒有誰的才是對的，誰才是錯的，重點流程有沒有錯，有沒有bug， : 執行會不會慢，巢狀迴圈幾層。 : 執著在那些格式很沒有意義，或誰誰誰寫code格式不符合我意的，就把別人弄走。 : 你不能說你就是標準，全部人都要跟你的寫法一模一樣，很多人寫程式想的是這個問題要 : 怎麼寫才巧妙解決，而不是十分在乎格式，太執著就有強迫症或太龜毛，合作起來也很痛 : 苦。 : 放過別人也放過自己，互相尊重。 -- https://i.imgur.com/QDN9AhN.jpeg
紫楓創作：https://portaly.cc/tbpfs 我是AI王紫楓 你可以叫我AI王 也可以叫我AI王子 也可以叫我AI王子瘋 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.205.130.61 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1721717892.A.838.html
推
07/23 15:21, 4月前 , 1F
遇到if-else完整陳述語法就沒辦法這樣偷吃步了
07/23 15:21, 1F
推
07/23 15:55, 4月前 , 2F
Conventions?
07/23 15:55, 2F
→
07/23 15:58, 4月前 , 3F
senior 最大的問題是 知識的詛咒
07/23 15:58, 3F
→
07/23 16:14, 4月前 , 4F
每個都有else就不能像你說的這樣改
07/23 16:14, 4F
→
07/23 16:17, 4月前 , 5F
真的遇到這種狀況只能把條件參數化再寫成其他形式，就像r
07/23 16:17, 5F
→
07/23 16:17, 4月前 , 6F
oute一樣，但也有可能到最後你發現還是if else最好維護，
07/23 16:17, 6F
→
07/23 16:17, 4月前 , 7F
而且在某些很在意延遲的場景，if else更好
07/23 16:17, 7F
→
07/23 16:44, 4月前 , 8F
conversation
07/23 16:44, 8F
→
07/23 16:46, 4月前 , 9F
太多層就是 邏輯不夠明確 接手的人很痛苦
07/23 16:46, 9F
→
07/23 16:53, 4月前 , 10F
沒事找事，太閒
07/23 16:53, 10F
※ 編輯: tbpfs (123.205.130.61 臺灣), 07/23/2024 17:26:54 ※ 編輯: tbpfs (123.205.130.61 臺灣), 07/23/2024 17:26:59
→
07/23 17:27, 4月前 , 11F
靠邊 手指太肥了點到conversation XD
07/23 17:27, 11F
※ 編輯: tbpfs (123.205.130.61 臺灣), 07/23/2024 17:27:52 ※ 編輯: tbpfs (123.205.130.61 臺灣), 07/23/2024 17:28:15
→
07/23 17:28, 4月前 , 12F
我記得一個func裡多個return，這種方式不是不建議使用?
07/23 17:28, 12F
→
07/23 17:29, 4月前 , 13F
你說的可能是很久以前的寫法不建議使用
07/23 17:29, 13F
→
07/23 17:29, 4月前 , 14F
但現在為了readability, 都是用這種寫法
07/23 17:29, 14F
→
07/23 17:45, 4月前 , 15F
early return現在還滿常見的
07/23 17:45, 15F
推
07/23 17:46, 4月前 , 16F
一個func多個return滿常在leetcode most vote 看到
07/23 17:46, 16F
→
07/23 18:09, 4月前 , 17F
early return 還是要看一下返回的理由是什麼比較好.
07/23 18:09, 17F
→
07/23 18:10, 4月前 , 18F
一般的建議還是用在檢視輸入的資料有沒有符合規則.
07/23 18:10, 18F
推
07/23 18:18, 4月前 , 19F
然後，下面的例子有點極端 kubernetes裡的pc_controller.go
07/23 18:18, 19F
→
07/23 18:19, 4月前 , 20F
1714行，充滿if-else，作者一開頭就告訴你:別亂改，每個
07/23 18:19, 20F
→
07/23 18:19, 4月前 , 21F
if-else都有意義.
07/23 18:19, 21F
→
07/23 18:24, 4月前 , 22F
以原發文的例子而言，有沒有可能，就是因為junior，為了避
07/23 18:24, 22F
→
07/23 18:25, 4月前 , 23F
免犯錯，才大量使用if-else去描述每一個路徑?
07/23 18:25, 23F
推
07/23 19:14, 4月前 , 24F
如果不能return必須繼續做下去怎麼辦
07/23 19:14, 24F
→
07/23 19:15, 4月前 , 25F
我在c++裡面要解析json我都會先給一個if看欄位在不在
07/23 19:15, 25F
→
07/23 19:15, 4月前 , 26F
然後再一個if看到底是array還是object 再一個if看到底是
07/23 19:15, 26F
→
07/23 19:15, 4月前 , 27F
字串還是數字 最後才開始做事
07/23 19:15, 27F
推
07/23 19:40, 4月前 , 28F
C++ json還要手寫parser？
07/23 19:40, 28F
→
07/23 19:51, 4月前 , 29F
沒看過程式碼真的別太篤定對錯。
07/23 19:51, 29F
推
07/23 22:12, 4月前 , 30F
early return 感覺還比較適合多數情境，防呆機制比起
07/23 22:12, 30F
→
07/23 22:12, 4月前 , 31F
風格是更順暢的理由
07/23 22:12, 31F
推
07/23 23:49, 4月前 , 32F
推這篇
07/23 23:49, 32F
推
07/24 00:40, 4月前 , 33F
推 剛入行也是針對這點有被前輩教育過
07/24 00:40, 33F
→
07/24 00:40, 4月前 , 34F
後來也有像是用枚舉或是switch 來取代 if else
07/24 00:40, 34F
→
07/24 00:41, 4月前 , 35F
只能說原 po可能有盡力 但不是當事人不好評論
07/24 00:41, 35F
推
07/24 00:51, 4月前 , 36F
其實若if-else或switch裡面思路清楚 不會是個問題 而且就
07/24 00:51, 36F
→
07/24 00:51, 4月前 , 37F
我少少的經驗來說一但思路清楚 大概也不太會形成很深的
07/24 00:51, 37F
→
07/24 00:52, 4月前 , 38F
if/switch 很難用例子去闡述那種if顯示出來的思路雜亂跟
07/24 00:52, 38F
→
07/24 00:53, 4月前 , 39F
跟理解/修改的困難(更難驗證邏輯正確性)
07/24 00:53, 39F
→
07/24 00:54, 4月前 , 40F
@atst2 有可能是避免犯錯 但我也跟其他人一起討論當時案
07/24 00:54, 40F
→
07/24 00:56, 4月前 , 41F
例 一旦分析好狀況 可以寫出用少量的if/switch的同樣功能
07/24 00:56, 41F
→
07/24 00:57, 4月前 , 42F
也有分享給對方...比較難理解的是 下次遇到同樣需要分析
07/24 00:57, 42F
→
07/24 00:58, 4月前 , 43F
時 還是用同樣方式描述路徑是有點意外
07/24 00:58, 43F
→
07/24 00:59, 4月前 , 44F
補充:當然也不排除有上面提到的那種極端狀況. 至少不是現
07/24 00:59, 44F
→
07/24 00:59, 4月前 , 45F
在遇到的
07/24 00:59, 45F
推
07/24 01:30, 4月前 , 46F
我之前被review也是被教early return
07/24 01:30, 46F
推
07/24 01:37, 4月前 , 47F
請愛用策略工廠
07/24 01:37, 47F
推
07/24 06:24, 4月前 , 48F
你邏輯沒理清楚才會覺得 if else 是 must
07/24 06:24, 48F
→
07/24 06:27, 4月前 , 49F
怎麼會有人問必須做下去該怎麼辦…OMG…
07/24 06:27, 49F
推
07/24 06:32, 4月前 , 50F
Guard Clauses 跟 EAFP 有空可以去了解一下
07/24 06:32, 50F
→
07/24 07:43, 4月前 , 51F
三小，就是會有if else must的狀況啊
07/24 07:43, 51F
推
07/24 08:21, 4月前 , 52F
early return能提高程式碼的可讀性、維護性，而且
07/24 08:21, 52F
→
07/24 08:21, 4月前 , 53F
也可以減少不必要的計算資源
07/24 08:21, 53F
推
07/24 10:14, 4月前 , 54F
如果該函式的行為有清楚定義並做好單元測試，裡面if迴圈
07/24 10:14, 54F
→
07/24 10:15, 4月前 , 55F
複雜一點好像也還好。
07/24 10:15, 55F
→
07/24 10:16, 4月前 , 56F
不可能會有，另外寫一個 function 在那邊 early return
07/24 10:16, 56F
→
07/24 10:16, 4月前 , 57F
而已
07/24 10:16, 57F
→
07/24 10:17, 4月前 , 58F
不然你提出一個例子我們討論看看
07/24 10:17, 58F
→
07/24 10:19, 4月前 , 59F
這東西你最終只要注意是 Passing By Pointer 還是 Pass
07/24 10:19, 59F
→
07/24 10:19, 4月前 , 60F
ing By Reference 你就能做出你要的東西了
07/24 10:19, 60F
→
07/24 12:37, 4月前 , 61F
會寫成巢狀if 也可能是歷史造成的 前人寫 後人不敢動太大
07/24 12:37, 61F
→
07/24 14:33, 4月前 , 62F
你當然可以把內層的if-else拉出去另一個function取個名字
07/24 14:33, 62F
→
07/24 14:33, 4月前 , 63F
對於要trace整個狀況的開發者來說, 邏輯的複雜性沒有降低
07/24 14:33, 63F
→
07/24 14:34, 4月前 , 64F
有時候反而跳來跳去更痛苦
07/24 14:34, 64F
推
07/24 14:38, 4月前 , 65F
guard clause 不是蠻基本的嗎
07/24 14:38, 65F
→
07/24 15:51, 4月前 , 66F
guard clause, early return 都看情況不用在那邊文人相輕
07/24 15:51, 66F
推
07/24 17:07, 4月前 , 67F
五十步笑百步 一堆early return有比較好嗎
07/24 17:07, 67F
推
07/24 18:13, 4月前 , 68F
不好嗎？ 哪個條件不要了就選起來刪掉就好，完全不用
07/24 18:13, 68F
→
07/24 18:14, 4月前 , 69F
研究那堆if else
07/24 18:14, 69F
→
07/24 19:37, 4月前 , 70F
if else 還不是一樣選起來刪掉-.-
07/24 19:37, 70F
→
07/24 19:39, 4月前 , 71F
真值表畫出來就知道你early return不會讓複雜度降低只是
07/24 19:39, 71F
→
07/24 19:39, 4月前 , 72F
程式碼語法差異而已
07/24 19:39, 72F
推
07/24 20:50, 4月前 , 73F
波動拳你怎麼選...
07/24 20:50, 73F
推
07/24 23:14, 4月前 , 74F
我之前也看過一堆goto差點自焚
07/24 23:14, 74F
推
07/25 00:07, 4月前 , 75F
坐等例子
07/25 00:07, 75F
推
07/25 18:49, 4月前 , 76F
early return 在做防呆類型好用，可以簡化if else，讓
07/25 18:49, 76F
→
07/25 18:49, 4月前 , 77F
邏輯清楚一點。
07/25 18:49, 77F
推
08/06 18:14, 3月前 , 78F
推樓上 不然光縮排就飽了
08/06 18:14, 78F
‣ 更多 tbpfs 的文章
文章代碼(AID): #1cdrI4Wu (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 tbpfs 的文章
文章代碼(AID): #1cdrI4Wu (Soft_Job)