Re: [問題] 學code要看天分嗎?

看板C_and_CPP作者 (Victor)時間12年前 (2011/12/10 10:51), 編輯推噓29(29推 0噓 54→)
留言83則, 26人參與, 最新討論串3/4 (看更多)
※ 引述《FableKevinS (FableKevinS)》之銘言： : 開發平台(Platform): (Ex: VC++, GCC, Linux, ...) : 自己是初學c++ 也是相關科系生 : 每次看別人寫的code, 就覺得相當簡潔. : 相較之下,自己寫的就複雜許多. : 有些我覺得蠻難的問題. 高手也就只是while包幾個for就出來了. : 自己寫就很難看.. 我自己是這樣認為，一個人多強 是在於看他寫過多少爛程式 當然，光會寫爛程式沒有任何幫助 重點在於每次你寫完程式，覺得很糟 你多少都要能從裡面學到什麼，同樣的錯不要再犯 舉些例子 if (foo) bar1(); else bar2(); for(i = 0; i < 10; ++i) do_something(); 很多人遇到單行的句子都喜歡把括號省略 我個人是絕對不省那括號 為什麼? 因為這樣出過錯，考慮一下你改程式 if (foo) bar1(); else bar2(); bar3(); for(i = 0; i < 10; ++i) do_something(); do_something2(); 你以為你在寫Python嗎? 很可惜不是 上面的程式都會出問題，只有第一行的程式會被認為是屬於前面的code block 而且這樣很難被看出來，因為讀的時候直覺上是認縮排 這樣寫還沒有任何語法錯誤與警告 程式夠大就很難以被發現和偵錯 正因為犯過這樣的錯，後來我得到一個結論 "為了省那一行括號很容易造成修改時的錯誤，那麼寧可一律不省" if (foo) { bar1(); } else { bar2(); } 這樣就不易犯上面的錯，像這樣的認知累積起來，你寫的程式才會漸漸完善 我也遇過中文註解引起的問題，從那之後都強迫自己用英文寫註解 http://0rz.tw/MLEp0 還有很多很多，都是靠犯錯累積起來的 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.170.197.154
推
12/10 10:54, , 1F
真的，多寫多錯就會慢慢進步了
12/10 10:54, 1F
推
12/10 12:00, , 2F
推從錯誤中學習!
12/10 12:00, 2F
推
12/10 13:27, , 3F
原來中文註解有可能會有問題 筆記.....
12/10 13:27, 3F
推
12/10 13:44, , 4F
個人的寫法是單行敘述跟else不隔行 else xxx; 這樣
12/10 13:44, 4F
→
12/10 14:37, , 5F
寫多了 這就不會是問題...
12/10 14:37, 5F
或許你自己寫有把握不會犯這種錯 但你可能沒有考慮過程式不是自己寫就算了 很多情況你還得和別人一起合寫 別人也有可能會改寫你的程式 再說，其實寫程式寫久了就會發現 常常那些除錯最久的bug，都是很蠢的錯誤 好吧，就算犯這錯誤的機率很低 但即然多寫一對 {} 可以省去出錯的可能 那為什麼要省? 省打那兩個字元省不了幾秒 然而出錯除錯可能要花十分鐘 甚至半小時 良好的程式風格 不是只有可執行就好 或是自己看得懂方便、我自己不會弄錯就好 還得考量別人是否易懂，是否會容易造成誤解、錯誤等等 雖然是很小的細節，但是還是有強制寫括號的理由
推
12/10 14:58, , 6F
個人會省括號 但會控制好縮排 理由是減少煩人的畫面捲動
12/10 14:58, 6F
現代的程式碼檢視工具都會有區塊折疊的功能 省一行的捲動 VS 避免可能發生的錯誤 我會選擇避免可能發生的錯誤 因為少那一行對整體可讀性來說並沒有太大實質的幫助 整體長度的控制是在於函數的切割 而不是在於那一個括號所佔的一行 ※ 編輯: StubbornLin 來自: 118.170.197.154 (12/10 15:06)
→
12/10 15:06, , 7F
我會把括號跟縮排一起弄好，就算只有一行也是
12/10 15:06, 7F
推
12/10 15:15, , 8F
我會省是因為我從來沒遇過這種bug (包括同事的code
12/10 15:15, 8F
沒遇過不代表不會出現 或許我比較龜毛，但是即然是習慣上的選擇 我會選擇較佳的那個習慣，因為兩個括號的成本遠低於出錯的成本 而且，這和我認知的Python精神是一致的 http://www.python.org/dev/peps/pep-0020/ "There should be one-- and preferably only one --obvious way to do it." 同時，這種做法不是只有我自己這麼想，可以參考K&R風格裡 http://en.wikipedia.org/wiki/Indent_style "The One True Brace Style" Joel談軟體也有在 "讓錯的程式看得出錯" 提過 http://www.cc.ntut.edu.tw/~s4599001/docs/ErrProgSee.htm "1. 你不知道乾淨和髒有什麼分別. 2. 你對乾淨有粗淺的認知, 主要以是否符合編程規範為準. 3. 你開始能嗅出藏在表面下不對勁的蛛絲馬跡. 你會察覺這是問題並且找出來修正. 不過其實還有更高的層次, 而這也就是我真正要說的: 4. 你有計劃地架構程式碼, 藉助能察覺問題的靈眼讓程式碼更正確. 這是真正的藝術: 仔細地設計讓錯誤顯而易見的編程規範, 藉此製作出穩固的程式. " 這是程式碼風格的堅持，沒有一定對錯 但是我相信我的堅持是對的 每個人或團隊看法都不一樣 這要看團隊的狀況而定 ※ 編輯: StubbornLin 來自: 118.170.197.154 (12/10 15:25)
推
12/10 15:54, , 9F
沒有說你錯啦XD 解釋我的取捨方式而已
12/10 15:54, 9F
→
12/10 15:55, , 10F
無聊按一下格式化 就會把腦殘縮排全部還原 於是乎這個
12/10 15:55, 10F
→
12/10 15:55, , 11F
問題就沒了
12/10 15:55, 11F
→
12/10 15:57, , 12F
對我而言 打括號成本x打括號次數 > debug成本x發生次數
12/10 15:57, 12F
推
12/10 16:05, , 13F
另外，我認為 Joel 根本搞錯了 exception 的目的
12/10 16:05, 13F
→
12/10 16:06, , 14F
對 operator overload 的認知也反了
12/10 16:06, 14F
→
12/10 16:07, , 15F
正是為了讓錯的程式能看出錯 才會有這兩項設計
12/10 16:07, 15F
推
12/10 16:16, , 16F
我也是絕對不省這個括號，你的code不是只有你一個人看
12/10 16:16, 16F
推
12/10 16:18, , 17F
"常常那些除錯最久的bug，都是很蠢的錯誤"<--這句話實在
12/10 16:18, 17F
→
12/10 16:19, , 18F
是太認同。為了當那當初的一兩秒，最後多花幾個小時找bug
12/10 16:19, 18F
推
12/10 16:53, , 19F
我想bar3();跟do_st2();的問題 是在寫這兩行之時 沒看清
12/10 16:53, 19F
→
12/10 16:54, , 20F
楚程式 code block...而不是錯在之前的漏寫括號
12/10 16:54, 20F
→
12/10 16:57, , 21F
改程式時 多想、看清楚再下手 可能比較重要
12/10 16:57, 21F
→
12/10 16:57, , 22F
我的意思只是說 寫久就會留意這些小地方...
12/10 16:57, 22F
→
12/10 16:59, , 23F
而且Debug和寫程式都需要耐心和細心呀...
12/10 16:59, 23F
→
12/10 17:00, , 24F
此外我覺得debug是一件很快樂的事呀~~~
12/10 17:00, 24F
→
12/10 17:24, , 25F
在 C++ 裡, 你用 algorithm + lambda 可以減少一半以
12/10 17:24, 25F
→
12/10 17:26, , 26F
上這種錯, 配上 Boost.Range Boost.Iterator
12/10 17:26, 26F
→
12/10 17:27, , 27F
Boost.Foreach range base for, 再加上別種的縮排方式
12/10 17:27, 27F
→
12/10 17:29, , 28F
如縮成一行, 我們公司連普通的迴圈都很少看到了...
12/10 17:29, 28F
→
12/10 17:59, , 29F
我覺得 feature 還沒用盡, 然後說怎樣寫容易錯都太早
12/10 17:59, 29F
推
12/10 18:00, , 30F
請善用IDE的Formatter，不要直接vim硬幹
12/10 18:00, 30F
→
12/10 18:00, , 31F
其實我蠻不懂一堆人抗拒IDE的理由是啥...
12/10 18:00, 31F
推
12/10 18:10, , 32F
vim有formatter啊 = =
12/10 18:10, 32F
→
12/10 18:18, , 33F
^^^^^ 就像這樣打 XD
12/10 18:18, 33F
→
12/10 18:19, , 34F
樓上懂我的意思！
12/10 18:19, 34F
推
12/10 18:24, , 35F
抱歉我見識淺薄沒看過人用vim的formatter..XD
12/10 18:24, 35F
→
12/10 18:24, , 36F
學到一課了，感謝指正！
12/10 18:24, 36F
推
12/10 18:51, , 37F
v選好後按=
12/10 18:51, 37F
推
12/10 19:02, , 38F
我抗拒IDE的理由，就是沒有IDE的編輯器比我的emacs好用
12/10 19:02, 38F
→
12/10 19:26, , 39F
....emacs也是IDE呀 = =
12/10 19:26, 39F
推
12/10 19:28, , 40F
gg=G
12/10 19:28, 40F
→
12/10 19:28, , 41F
不，emacs是OS XD
12/10 19:28, 41F
→
12/10 22:26, , 42F
被笑過就會學比較快，我是跟別人互相嘲笑對方 code 長大的
12/10 22:26, 42F
推
12/11 10:09, , 43F
不，emacs是OS XD
12/11 10:09, 43F
→
12/11 21:20, , 44F
我就很喜歡省掉括號，看起來簡潔，且幾乎沒犯過你說的錯誤
12/11 21:20, 44F
→
12/11 21:24, , 45F
如果省略括號會讓你容易犯錯，也許你寫的程式該重構了 :p
12/11 21:24, 45F
推
12/11 21:51, , 46F
非常同意這篇 我後來都不會省略大括號
12/11 21:51, 46F
→
12/11 21:54, , 47F
我加上大括號主要原因是，我不能夠確定那個if就只有
12/11 21:54, 47F
→
12/11 21:55, , 48F
一行，如果沒有括號之後要增加還是一樣要加上去
12/11 21:55, 48F
→
12/11 21:57, , 49F
沒錯 同樓上 要用的時候還是得加
12/11 21:57, 49F
推
12/11 23:05, , 50F
自己不會犯錯不代表讀你code的人不會犯，我相信愛喜歡省
12/11 23:05, 50F
→
12/11 23:05, , 51F
略的人不是學生就是很少和人co-work
12/11 23:05, 51F
推
12/11 23:19, , 52F
我是都會加,雖然我沒犯過這個錯,但是我的原因很簡單
12/11 23:19, 52F
→
12/11 23:19, , 53F
我不是考慮同事會不會看錯,而是我永遠都把自己當白痴
12/11 23:19, 53F
→
12/11 23:20, , 54F
「我很有信心，我有一天一定會犯錯」
12/11 23:20, 54F
推
12/11 23:36, , 55F
先加上去+1 確定此份代碼達到要求 可能不需維護後才會拿掉
12/11 23:36, 55F
→
12/12 12:54, , 56F
Avoid unnecessary curly braces,
12/12 12:54, 56F
→
12/12 12:55, , 57F
but if one branch of an if is braced,
12/12 12:55, 57F
→
12/12 12:55, , 58F
then the other should be too
12/12 12:55, 58F
→
12/12 12:57, , 59F
簡潔的程式碼閱讀時可以更不費力
12/12 12:57, 59F
→
12/12 12:58, , 60F
雖然以這種小地方來說，差異不大，大家高興就好
12/12 12:58, 60F
→
12/12 13:04, , 61F
我相信大家應該知道優秀的程式員應該都極度討厭累贅 :)
12/12 13:04, 61F
推
12/12 18:19, , 62F
需求變更吧
12/12 18:19, 62F
→
12/12 21:24, , 63F
專案壓力
12/12 21:24, 63F
推
12/12 22:22, , 64F
你的同事和未來的maintainer不見得和你一樣優秀
12/12 22:22, 64F
→
12/12 22:23, , 65F
從自己的code看世界和從long term maintain的成本來看世
12/12 22:23, 65F
→
12/12 22:24, , 66F
界，當然沒有交集了
12/12 22:24, 66F
→
12/12 22:50, , 67F
long term 來說，模組的拆解方式及 API 的設計才是王道，
12/12 22:50, 67F
→
12/12 22:50, , 68F
括不括號只是枝節～
12/12 22:50, 68F
推
12/12 23:32, , 69F
樓上的說法真的讓人覺得是學生或是沒大型專案經驗
12/12 23:32, 69F
推
12/12 23:49, , 70F
ykjiang我向你道歉，我覺得我上面這句說過頭了
12/12 23:49, 70F
推
12/13 02:09, , 71F
我也會加括號 雖然team的規範是一行的不加
12/13 02:09, 71F
→
12/13 02:10, , 72F
不加是省了很多行 但你怎知道那一天你會突然有需要加
12/13 02:10, 72F
推
12/13 06:17, , 73F
有需要加時再加即可 如果維護code的 連迴圈範圍都不懂
12/13 06:17, 73F
→
12/13 06:18, , 74F
那你怎麼有辦法期待 他能有維護你code的能力呢...
12/13 06:18, 74F
→
12/13 10:19, , 75F
風格問題永遠戰不完的
12/13 10:19, 75F
→
12/13 10:49, , 76F
括號是好東西,不要因為一行就不加.這是一個習慣
12/13 10:49, 76F
→
12/13 12:23, , 77F
我的習慣是，剛寫時，沒想清楚前可能會先加，
12/13 12:23, 77F
→
12/13 12:24, , 78F
確定不需要括號後，事後會拿掉，是重視簡潔，而非偷懶～
12/13 12:24, 78F
→
12/13 12:35, , 79F
既一行又括號(被打) http://codepad.org/a3XFl2pY
12/13 12:35, 79F
推
04/02 23:38, , 80F
我的原則是 不管有幾行 括號都是要加的
04/02 23:38, 80F
→
04/02 23:39, , 81F
原因很簡單 與其讓腦袋多記一個:if只有一行, then不加括號
04/02 23:39, 81F
→
04/02 23:40, , 82F
還不如 全部都加上 而省去在維持另一個規則的麻煩
04/02 23:40, 82F
→
04/02 23:41, , 83F
當然 上面很多人說的 避免錯誤 不論自己或是別人 也是原因
04/02 23:41, 83F
‣ 更多 StubbornLin 的文章
文章代碼(AID): #1EuiacFj (C_and_CPP)
‣ 更多 StubbornLin 的文章
文章代碼(AID): #1EuiacFj (C_and_CPP)