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

[StubbornLin (Victor)]

※ 引述《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
推 james732:真的，多寫多錯就會慢慢進步了
推 yudsx:推從錯誤中學習!
推 KTFGU:原來中文註解有可能會有問題  筆記.....
推 amozartea:個人的寫法是單行敘述跟else不隔行 else  xxx; 這樣
→ firejox:寫多了 這就不會是問題...
或許你自己寫有把握不會犯這種錯
但你可能沒有考慮過程式不是自己寫就算了
很多情況你還得和別人一起合寫
別人也有可能會改寫你的程式
再說，其實寫程式寫久了就會發現
常常那些除錯最久的bug，都是很蠢的錯誤

好吧，就算犯這錯誤的機率很低
但即然多寫一對 {} 可以省去出錯的可能
那為什麼要省? 省打那兩個字元省不了幾秒
然而出錯除錯可能要花十分鐘 甚至半小時

良好的程式風格
不是只有可執行就好
或是自己看得懂方便、我自己不會弄錯就好
還得考量別人是否易懂，是否會容易造成誤解、錯誤等等
雖然是很小的細節，但是還是有強制寫括號的理由

推 elfkiller:個人會省括號 但會控制好縮排 理由是減少煩人的畫面捲動
現代的程式碼檢視工具都會有區塊折疊的功能

省一行的捲動 VS 避免可能發生的錯誤

我會選擇避免可能發生的錯誤
因為少那一行對整體可讀性來說並沒有太大實質的幫助
整體長度的控制是在於函數的切割
而不是在於那一個括號所佔的一行
※ 編輯: StubbornLin     來自: 118.170.197.154      (12/10 15:06)
→ diabloevagto:我會把括號跟縮排一起弄好，就算只有一行也是
推 littleshan:我會省是因為我從來沒遇過這種bug (包括同事的code
沒遇過不代表不會出現
或許我比較龜毛，但是即然是習慣上的選擇
我會選擇較佳的那個習慣，因為兩個括號的成本遠低於出錯的成本
而且，這和我認知的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)
推 littleshan:沒有說你錯啦XD 解釋我的取捨方式而已
→ x000032001:無聊按一下格式化 就會把腦殘縮排全部還原 於是乎這個
→ x000032001:問題就沒了
→ littleshan:對我而言 打括號成本x打括號次數 > debug成本x發生次數
推 littleshan:另外，我認為 Joel 根本搞錯了 exception 的目的
→ littleshan:對 operator overload 的認知也反了
→ littleshan:正是為了讓錯的程式能看出錯 才會有這兩項設計
推 cobrasgo:我也是絕對不省這個括號，你的code不是只有你一個人看
推 cobrasgo:"常常那些除錯最久的bug，都是很蠢的錯誤"<--這句話實在
→ cobrasgo:是太認同。為了當那當初的一兩秒，最後多花幾個小時找bug
推 tonyhsie:我想bar3();跟do_st2();的問題 是在寫這兩行之時 沒看清
→ tonyhsie:楚程式 code block...而不是錯在之前的漏寫括號
→ tonyhsie:改程式時 多想、看清楚再下手 可能比較重要
→ firejox:我的意思只是說 寫久就會留意這些小地方...
→ firejox:而且Debug和寫程式都需要耐心和細心呀...
→ firejox:此外我覺得debug是一件很快樂的事呀~~~
→ loveme00835:在 C++ 裡, 你用 algorithm + lambda 可以減少一半以
→ loveme00835:上這種錯, 配上 Boost.Range Boost.Iterator
→ loveme00835:Boost.Foreach range base for, 再加上別種的縮排方式
→ loveme00835:如縮成一行, 我們公司連普通的迴圈都很少看到了...
→ loveme00835:我覺得 feature 還沒用盡, 然後說怎樣寫容易錯都太早
推 tomap41017:請善用IDE的Formatter，不要直接vim硬幹
→ tomap41017:其實我蠻不懂一堆人抗拒IDE的理由是啥...
推 littleshan:vim有formatter啊 = =
→ shadow0326:                ^^^^^ 就像這樣打 XD
→ littleshan:樓上懂我的意思！
推 tomap41017:抱歉我見識淺薄沒看過人用vim的formatter..XD
→ tomap41017:學到一課了，感謝指正！
推 qrtt1:v選好後按=
推 coldnew:我抗拒IDE的理由，就是沒有IDE的編輯器比我的emacs好用
→ firejox:....emacs也是IDE呀 = =
推 kdjf:gg=G
→ coldnew:不，emacs是OS  XD
→ tinlans:被笑過就會學比較快，我是跟別人互相嘲笑對方 code 長大的
推 yoco315:不，emacs是OS  XD
→ ykjiang:我就很喜歡省掉括號，看起來簡潔，且幾乎沒犯過你說的錯誤
→ ykjiang:如果省略括號會讓你容易犯錯，也許你寫的程式該重構了 :p
推 LoveCheer:非常同意這篇 我後來都不會省略大括號
→ diabloevagto:我加上大括號主要原因是，我不能夠確定那個if就只有
→ diabloevagto:一行，如果沒有括號之後要增加還是一樣要加上去
→ LoveCheer:沒錯 同樓上 要用的時候還是得加
推 cobrasgo:自己不會犯錯不代表讀你code的人不會犯，我相信愛喜歡省
→ cobrasgo:略的人不是學生就是很少和人co-work
推 yoco315:我是都會加,雖然我沒犯過這個錯,但是我的原因很簡單
→ yoco315:我不是考慮同事會不會看錯,而是我永遠都把自己當白痴
→ yoco315:「我很有信心，我有一天一定會犯錯」
推 Yshuan:先加上去+1 確定此份代碼達到要求 可能不需維護後才會拿掉
→ ykjiang:Avoid unnecessary curly braces,
→ ykjiang:but if one branch of an if is braced,
→ ykjiang:then the other should be too
→ ykjiang:簡潔的程式碼閱讀時可以更不費力
→ ykjiang:雖然以這種小地方來說，差異不大，大家高興就好
→ ykjiang:我相信大家應該知道優秀的程式員應該都極度討厭累贅 :)
推 ericinttu:                                          需求變更吧
→ angleevil:                                          專案壓力
推 cobrasgo:你的同事和未來的maintainer不見得和你一樣優秀
→ cobrasgo:從自己的code看世界和從long term maintain的成本來看世
→ cobrasgo:界，當然沒有交集了
→ ykjiang:long term 來說，模組的拆解方式及 API 的設計才是王道，
→ ykjiang:括不括號只是枝節～
推 cobrasgo:樓上的說法真的讓人覺得是學生或是沒大型專案經驗
推 cobrasgo:ykjiang我向你道歉，我覺得我上面這句說過頭了
推 newstar2007:我也會加括號 雖然team的規範是一行的不加
→ newstar2007:不加是省了很多行 但你怎知道那一天你會突然有需要加
推 tonyhsie:有需要加時再加即可 如果維護code的 連迴圈範圍都不懂
→ tonyhsie:那你怎麼有辦法期待 他能有維護你code的能力呢...
→ shadow0326:風格問題永遠戰不完的
→ angleevil:括號是好東西,不要因為一行就不加.這是一個習慣
→ ykjiang:我的習慣是，剛寫時，沒想清楚前可能會先加，
→ ykjiang:確定不需要括號後，事後會拿掉，是重視簡潔，而非偷懶～
→ x000032001:既一行又括號(被打)  http://codepad.org/a3XFl2pY
推 rodion:我的原則是 不管有幾行 括號都是要加的
→ rodion:原因很簡單 與其讓腦袋多記一個:if只有一行, then不加括號
→ rodion:還不如 全部都加上 而省去在維持另一個規則的麻煩
→ rodion:當然 上面很多人說的 避免錯誤 不論自己或是別人 也是原因