Re: [討論] 程式設計師,好吃技術的職業喔!

看板Soft_Job (軟體人)作者 (十年一夢)時間17年前 (2008/12/27 20:20), 編輯推噓9(9028)
留言37則, 10人參與, 最新討論串8/19 (看更多)
※ 引述《idleidle (賺大錢=看對&下大注&抱住)》之銘言: : 如果沒加else一定是沒被搞過 : 我一定會在else裡面加例外回報的程式碼 聽起來有點怪.... 如果是"認為condition永遠不會跑到else" 那就不該用if 該用assert 或者用try&catch 如果if是用來branch, 程式原本邏輯是如下這種 if(condition) { xxx(); } yyy(); 那麼, 一定要加上else的話, 那到底是要 if(condition) { xxx(); yyy(); }else { yyy(); } 還是 if(condition) { xxx(); }else { } yyy(); 效果相同, 出題者到底想要哪個呢? 兩者都反而把程式的閱讀性變差, 行數也拉長了不是嗎? coding style 有些規定大家都會同意, 例如"不要濫用goto", 也有些規定只要在同一家公司或同一個平台裡面約定一致就好, 例如"如何縮排", "if或else之後的{要放在同一行或是隔行"等等. 我覺得"if後面要有else"就是屬於後面那種. 有必要在找人的時候就要求對方的coding style和自己完全相同嗎? : 然後再加上自訂的編號 : 加這幾行不花幾分鐘 : 但這幾行可能在未來 : 節省你幾小時的debug時間!! : 如果是寫過硬体語言的 : 應該會習慣加上else吧 : 不加else會有什麼產生? : 科科科 : ※ 引述《cheng1989 (cheng1989)》之銘言: : : 跟我不久前去應徵過的一家公司一樣, 不會是同家吧?(凱x智慧) : : 那家公司在禮拜五跟我約隔天面試(禮拜六還上班...頭皮發麻..) : : 隔天我如期赴約, 結果一進去, : : 老闆就拿了張試題要我填, 不多, 好像才四題 : : 第一題就是要我回答某支jsp的code有沒有問題? 能再加強什麼? : : 他接著就開了一個網頁, 按右鍵檢視原始檔給我看, : : 說就是這個web page : : 看看有沒有問題, 有什麼想法就把它寫下來~ : : 然後, 天兵的我過了五分鐘後: : : 「....小姐, 我有問題」沒錯, 現場還有一位員工在那裡加班 : : 正妹走過來問我有何問題? : : 我說經理要我看看這頁的code有什麼問題 : : ...可是它是html檔欵...Orz : : (目小的我撐大眼睛看了5分鐘後總算肯定地告訴正妹, 但其實我是以為經理會再 : : 走過來開code給我看啦~) : : 正妹說, 喔, 那我去幫妳問一下經理喔! : : 我跟在正妹後面走到經理位置上.... : : ZZZzzzzz : : 正妹:「經理睡著了....」我完全能理解, 這家公司真的很操呢! : : 後來正妹就找出jsp code讓我作答, 總算完成了我的第一道題目 : : 因為是問我個人看法, 所以沒有標準答案, : : 寫了幾個我認為的問題之後, 接著再填寫其它試題, 交卷. : : 那位經理人還不錯, 看了我的答案之後告訴我說, : : 其實那頁的code有兩個大問題, 但我沒有答出來, : : 一個是它只有if : : 很多個if來判斷條件成立時要執行的動作 : : 卻沒有else : : 這意味著, : : 寫程式的人很有自信一定會有其中一個條件會成立 : : 或都不成立就什麼都不用做 : : 所以沒有else : : 但他認為這是最大的問題, : : 萬一發生意料外的事 : : 很可能就會異常 : : 他還拿cobol舉例, 說cobol就是每個if都要搭else才比較保險比較穩定(me: ????) : : 另一個問題, 好像是這些code最開始沒有先做xx判斷 : : 那個xx是什麼? 對不起我忘了Orz : : 好像是類似要處理的資料, 是否為null, 或值為0嗎? : : 這個沒先判斷就開始處理資料了 : : 大概就這兩個問題是他認為最重要的 : : 不過後來有被錄取耶~ 但我沒興趣做稽核, 就沒去了 : : 倒是我認為, 無論出這種考題的用意何在, : : 都可以努力把自己的想法表達出來, : : 即使回答的不是對方想聽的答案, : : 至少也讓他知道我的程度到那裡, 懂哪些東西 : : 絕對比交白卷好 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.136.226.5 ※ 編輯: neutrino 來自: 220.136.226.5 (12/27 20:23)

12/27 20:37, , 1F
以這個例子來說,效果不同。
12/27 20:37, 1F

12/27 20:38, , 2F
例如你覺得某結果應該會 mathc -> xxx() -> yyy()
12/27 20:38, 2F

12/27 20:39, , 3F
但是卻只看到yyy(),就無法判定是沒match,還是xxx()出錯
12/27 20:39, 3F

12/27 20:40, , 4F
加個 else { print something }等,會加快debug速度
12/27 20:40, 4F

12/27 20:41, , 5F
回到原PO的主管例子,應該也是範例程式碼沒作防錯處理吧
12/27 20:41, 5F

12/27 20:42, , 6F
那在if的{}裡面加一行print debug message就行了...
12/27 20:42, 6F

12/27 20:42, , 7F
加在if裡的xxx(); 之前
12/27 20:42, 7F

12/27 20:47, , 8F
這樣作決定點不在於if 有沒有 else 而在於 是否處理例外?
12/27 20:47, 8F

12/27 20:48, , 9F
是否加上適當的除錯訊息? 是否有隱含視作理所當然成立的
12/27 20:48, 9F

12/27 20:48, , 10F
條件卻沒有assertion?
12/27 20:48, 10F

12/27 20:49, , 11F
不知道原po看的程式碼內容, 無法判斷,單看"if沒配else"我
12/27 20:49, 11F

12/27 20:50, , 12F
認為沒有定論
12/27 20:50, 12F

12/27 23:25, , 13F
如果今天寫了八個條件判斷if...else if...else if...
12/27 23:25, 13F

12/27 23:26, , 14F
最後面加個else比較保險...
12/27 23:26, 14F

12/27 23:52, , 15F
看情況!像if(a==null){return;}判斷是否繼續就不用else
12/27 23:52, 15F

12/28 00:10, , 16F
樓上,如果程式裏有多處這種判斷,還是加一下好
12/28 00:10, 16F

12/28 00:11, , 17F
才知道return發生在何時,或可能都不是,是發生例外時?
12/28 00:11, 17F

12/28 00:17, , 18F
聽起來還是很奇怪, 怎麼會有人程式這樣子寫?
12/28 00:17, 18F

12/28 00:17, , 19F
如果在一個檢查input的function裡, by case去執行程式跟
12/28 00:17, 19F

12/28 00:18, , 20F
秀出input錯誤的訊息那很正常, 但怎麼可能全部都檢查
12/28 00:18, 20F

12/28 00:19, , 21F
舉個例來說 A 呼叫 B 呼叫 C 呼叫 D
12/28 00:19, 21F

12/28 00:19, , 22F
在 A 裡檢查算正常,可是到了 B, C, D...還在檢查幹嘛?
12/28 00:19, 22F

12/28 00:20, , 23F
通常都是早在A在確定輸入正確, B, C, D完全不檢查
12/28 00:20, 23F

12/28 00:21, , 24F
就算寫了 else 也100% 執行不到
12/28 00:21, 24F

12/28 00:22, , 25F
那為何補上 else 會成為一種良好的習慣? 就令人十分費解..
12/28 00:22, 25F

12/28 00:29, , 26F
都可以拉!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
12/28 00:29, 26F

12/28 01:58, , 27F
樓樓上,要這樣寫的前提是, D只會被C呼叫,C只會被B呼叫
12/28 01:58, 27F

12/28 01:59, , 28F
而B只會被A呼叫。而且要規定來B,C,D不可被其他人呼叫
12/28 01:59, 28F

12/28 01:59, , 29F
^未來
12/28 01:59, 29F

12/28 02:31, , 30F
推coding style
12/28 02:31, 30F

12/28 02:44, , 31F
雖然不認為補上else 是「一定必要」,不過認同每個支線都要
12/28 02:44, 31F

12/28 02:45, , 32F
做處理的態度。身為Coder就要掌握這條路徑上的每一個可能性.
12/28 02:45, 32F

12/28 02:46, , 33F
不然費盡千辛萬苦把程式模組化就失去其意義了.
12/28 02:46, 33F

12/28 03:14, , 34F
支線處理很重要 但並不是用了else就能天下太平
12/28 03:14, 34F

12/28 03:16, , 35F
完全不用else不能算是很好的習慣 但凡事都非else不可
12/28 03:16, 35F

12/28 03:16, , 36F
只是讓人覺得矯枉過正
12/28 03:16, 36F

12/28 08:14, , 37F
討論到這個已經到了有點無聊的地步了
12/28 08:14, 37F
文章代碼(AID): #19LXsH4j (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #19LXsH4j (Soft_Job)