PTT數位生活區 / C_and_CPP (C/C++)

Re: [問題] 何謂寫得漂亮？

看板C_and_CPP (C/C++)作者 ( )時間16年前 (2010/01/17 20:59), 編輯推噓21(21推 0噓 72→)
留言93則, 17人參與, 最新討論串6/9 (看更多)
※ 引述《tinlans ( )》之銘言： 你說的很好，但我不完全同意 我認為寫程式還是有一些優美之處所在，用藝術這字眼來形容也不為過 還記得大一首次學寫程式的時候，要寫個作業產生費伯納西數列 (就是以 0, 1為起點，後面的每個數都是其前兩項數值的和) 當初想了老半天，打算用一個數值紀錄index，進而計算index+1所存的數字 後來發現課本用遞迴可以寫出很簡潔的程式，但缺點是速度慢 然後一個天才室友，跟我一樣也是初學，看了看題目，也沒google，想了幾秒之後 int a=0,b=1; for(...){a=a+b; b=b+a;} 兩行搞定，簡潔速度又快 雖然這題目現在看起來並不難，或許網路上也有這樣的答案 但當時我真的感受到很大的震撼，僅僅數秒鐘，竟然可以寫的這麼優美... 附帶一提，我覺得資料結構及演算法也蘊含許多藝術成份 現今，雖然這些幾乎都被視為基礎知識，lib也大量被使用 但我覺得，當初發明出這些使用方法，以至於大家將它標準化的人，真的稱得上為藝術家 -- -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.73.87 ※ 編輯: truesword 來自: 140.115.73.87 (01/17 21:00)
推
01/17 21:01, , 1F
同感
01/17 21:01, 1F
推
01/17 21:01, , 2F
說得很好
01/17 21:01, 2F
推
01/17 21:03, , 3F
這.... 有特別美嗎 @__@
01/17 21:03, 3F
→
01/17 21:04, , 4F
你不覺得這樣的想法既簡潔又能命中要害嗎XD
01/17 21:04, 4F
→
01/17 21:05, , 5F
不會耶 XD 不是一般人都會這樣寫嗎 ?
01/17 21:05, 5F
→
01/17 21:05, , 6F
遞迴的寫法反而是需要練習的
01/17 21:05, 6F
推
01/17 21:09, , 7F
是很美阿, 藝術需要你用不同的觀點去看的, 有成見的人
01/17 21:09, 7F
→
01/17 21:09, , 8F
就不覺得藝術是重要的
01/17 21:09, 8F
推
01/17 21:15, , 9F
如果到處看到的都是同等級的東西, 就不會覺得特別美了
01/17 21:15, 9F
→
01/17 21:16, , 10F
就像第一次學 functional language 時也覺得各種用法都很美
01/17 21:16, 10F
→
01/17 21:17, , 11F
現在看起來只會覺得寫得好的程式很流暢, 反而不太有驚喜
01/17 21:17, 11F
→
01/17 21:17, , 12F
因為已經成為必要的標準了
01/17 21:17, 12F
→
01/17 21:18, , 13F
樓上怎麼會想就程式碼來劃分等級呢 ?
01/17 21:18, 13F
→
01/17 21:18, , 14F
回應 tinlans 所說, 變成一種 engineer 了
01/17 21:18, 14F
→
01/17 21:19, , 15F
前一篇說很多了, 我就不獻醜了, 至少先從 patterns 開始看吧
01/17 21:19, 15F
→
01/17 21:20, , 16F
我的表達能力沒有上一篇 t 大好, 如果他的文章你看不懂...
01/17 21:20, 16F
→
01/17 21:20, , 17F
那我大概更難解釋得更好 orz
01/17 21:20, 17F
→
01/17 21:22, , 18F
"那些艱澀難懂的舊時代程式碼早就變成垃圾和毒瘤了"
01/17 21:22, 18F
→
01/17 21:23, , 19F
我最不同意這句話, 因為說話的人必須考慮時空背景
01/17 21:23, 19F
→
01/17 21:23, , 20F
以及寫程式的人的用意, 他那篇文章讓我覺得好像是現在
01/17 21:23, 20F
→
01/17 21:24, , 21F
的人笑古代拿弓箭打仗很愚蠢一樣
01/17 21:24, 21F
→
01/17 21:24, , 22F
樓上可不可以show幾段你看到的"一般人的寫法"
01/17 21:24, 22F
→
01/17 21:25, , 23F
是樓樓上
01/17 21:25, 23F
→
01/17 21:27, , 24F
我倒覺得一般人好像是是用矩陣乘法來做, 等級不同?
01/17 21:27, 24F
→
01/17 21:27, , 25F
每個人對藝術的堅持和觀點不同，team work 易起爭執和歧見
01/17 21:27, 25F
→
01/17 21:28, , 26F
往往同樣功能的 function 每個 programmer 就各自在同一個
01/17 21:28, 26F
→
01/17 21:28, , 27F
專案裡維護自己看得順眼的版本，讀的人看到明明是不同名稱
01/17 21:28, 27F
→
01/17 21:28, , 28F
的 function，但是其實做的是同一件事。
01/17 21:28, 28F
→
01/17 21:29, , 29F
藝術應用在程式裡常常帶來這些爭執。
01/17 21:29, 29F
→
01/17 21:30, , 30F
而那句話在說的是把弓箭拿到現代來打仗很愚蠢的意思。
01/17 21:30, 30F
→
01/17 21:30, , 31F
那就是不同情況下囉, 又不是工程和藝術不能共存
01/17 21:30, 31F
→
01/17 21:31, , 32F
其實工程學本身就算是門藝術
01/17 21:31, 32F
→
01/17 21:32, , 33F
我覺得思想的延續是必要的, 但是不要固執於實現就好
01/17 21:32, 33F
推
01/17 21:32, , 34F
工程學如果能當成藝術的話, 就沒有所謂的工程標準可言了
01/17 21:32, 34F
→
01/17 21:33, , 35F
畢竟藝術個型式是很難有個舉世皆準的標準的
01/17 21:33, 35F
推
01/17 21:35, , 36F
頂多是新技術進展太快 "尚未" 將標準型塑出來
01/17 21:35, 36F
→
01/17 21:36, , 37F
怎不想成大家用不同的思維, 實踐標準呢 ?
01/17 21:36, 37F
→
01/17 21:37, , 38F
用什麼思維來達成標準並不重要, 重要的是藝術沒有這種標準
01/17 21:37, 38F
→
01/17 21:37, , 39F
而這是工程和藝術最格格不入的地方
01/17 21:37, 39F
推
01/17 21:38, , 40F
不衝突啦，ㄎㄎ...
01/17 21:38, 40F
→
01/17 21:38, , 41F
簡單的說, 藝術沒有一個評分的標準, 但成熟的工程裡通常有
01/17 21:38, 41F
→
01/17 21:41, , 42F
今天如果你寫的程式出現錯誤會死十萬個人，你想選擇用自己
01/17 21:41, 42F
→
01/17 21:41, , 43F
覺得很有創意極具藝術價值的程式碼，還是已經經過千錘百鍊
01/17 21:41, 43F
→
01/17 21:41, , 44F
都沒出過問題的程式碼或設計方法？
01/17 21:41, 44F
→
01/17 21:43, , 45F
我倒是認為藝術跟工程是先後關係，工程是從早期的藝術裡挑
01/17 21:43, 45F
→
01/17 21:44, , 46F
選出最適合、通用、有效、穩定的一種，但被選上的未必讓人
01/17 21:44, 46F
→
01/17 21:44, , 47F
覺得它富有藝術價值。
01/17 21:44, 47F
→
01/17 21:47, , 48F
有時候也未必是挑選，而是妥協和結合，這點從近代 OO 的發
01/17 21:47, 48F
→
01/17 21:47, , 49F
展和演進就可以看出來。
01/17 21:47, 49F
→
01/17 22:06, , 50F
就說the art of... 的art 不應該譯成藝術了...
01/17 22:06, 50F
推
01/17 22:11, , 51F
工藝
01/17 22:11, 51F
推
01/17 22:16, , 52F
藝術本來就沒有標準可言，極致的工程也是一種美
01/17 22:16, 52F
推
01/17 22:19, , 53F
好強大的思維啊!!!!!!!!!!!!!!!!!!!!(崩潰)
01/17 22:19, 53F
推
01/17 22:30, , 54F
原波這篇的答覆跟我原本的解讀一致呀
01/17 22:30, 54F
→
01/17 23:31, , 55F
那個費柏納 你室友是用數學的方法吧
01/17 23:31, 55F
→
01/17 23:34, , 56F
其實l大是你室友?
01/17 23:34, 56F
推
01/17 23:43, , 57F
看到你這強大的室友 我開始也懷疑自己是否有天份了 ~.~
01/17 23:43, 57F
推
01/17 23:48, , 58F
個人也覺得大架構如果設計得很好也是一種美~ 但是那種
01/17 23:48, 58F
→
01/17 23:49, , 59F
美是由設計得當的架構顯現出來的~ 我覺得說一個程式架構
01/17 23:49, 59F
→
01/17 23:50, , 60F
是藝術不代表那些程式碼不工程化(?)~ 而且有些設計
01/17 23:50, 60F
→
01/17 23:50, , 61F
並不是照標準流程就可以生出來的~ 個人看法
01/17 23:50, 61F
→
01/17 23:53, , 62F
我是覺得現代的好程式，就是你的程式長得跟 pseudo code
01/17 23:53, 62F
→
01/17 23:53, , 63F
幾乎一樣，中間沒有其它冗餘的雜質，甚至能當英文文章來唸
01/17 23:53, 63F
→
01/17 23:53, , 64F
，這樣就很好了。
01/17 23:53, 64F
→
01/17 23:56, , 65F
不過要做到這樣，背後要付出的努力遠比上面三句話多。
01/17 23:56, 65F
→
01/18 00:05, , 66F
說起來這篇好像是回我的。其實不是我故意不回應對那兩行程
01/18 00:05, 66F
→
01/18 00:06, , 67F
式碼的看法，而是我苦思了很久不知道怎麼回才比較不會傷人
01/18 00:06, 67F
→
01/18 00:06, , 68F
和給人打擊...
01/18 00:06, 68F
→
01/18 00:22, , 69F
不用再漂亮了 早點下班陪老婆小孩比較"漂亮"
01/18 00:22, 69F
→
01/18 00:24, , 70F
pseudo code + 1
01/18 00:24, 70F
推
01/18 00:28, , 71F
以前我上資料結構都講到用遞廻 我沒想到 天哪不行
01/18 00:28, 71F
→
01/18 00:28, , 72F
那一行 for(...){a=a+b; b=b+a;} 一直在我腦中盤旋啊
01/18 00:28, 72F
→
01/18 00:28, , 73F
-.- ... 你在反諷嗎
01/18 00:28, 73F
→
01/18 00:36, , 74F
其實工業界解決這類效率問題真正的殺招是查表法，一行搞定
01/18 00:36, 74F
→
01/18 00:37, , 75F
而且時間複雜度 O(1)，只是 effort 都在其它地方了。
01/18 00:37, 75F
→
01/18 00:45, , 76F
有人跑迴圈寫從 1 加到 100，有人直接寫 (1+100)*100/2，
01/18 00:45, 76F
→
01/18 00:46, , 77F
這個東西其實不在「程式面」，而是在更之前的東西，跟我前
01/18 00:46, 77F
→
01/18 00:46, , 78F
篇要講的東西是在不同的點上。
01/18 00:46, 78F
推
01/18 00:50, , 79F
這個code讓你絕得? 實用? 新奇? 生氣? 無聊?
01/18 00:50, 79F
→
01/18 00:51, , 80F
等到你接觸到百萬行級的程式碼並成功駕馭它之後，你可以再
01/18 00:51, 80F
→
01/18 00:51, , 81F
回頭來看看現在寫的東西。我大概只能這樣回了...
01/18 00:51, 81F
推
01/18 00:51, , 82F
應該是說他室友想出一個比課本還簡單的那種思維讓我震撼
01/18 00:51, 82F
推
01/18 01:14, , 83F
奇怪！是我少見多怪嗎？ 我覺得它室友當時是初學者卻能想出
01/18 01:14, 83F
→
01/18 01:15, , 84F
化繁為簡的寫法 真的很了不起啊 別忘了他那時是初學者
01/18 01:15, 84F
→
01/18 01:16, , 85F
如果又讓它擁有更多看程式碼的經驗 起不是強到飛天了？
01/18 01:16, 85F
→
01/18 01:51, , 86F
我是沒有別的意思啦。只是在想，藝術這東西在每個人眼中果
01/18 01:51, 86F
→
01/18 01:53, , 87F
然有極其巨大的落差。我也不打算否定別人對藝術價值的觀感
01/18 01:53, 87F
→
01/18 01:55, , 88F
，反正這東西還是會隨著時間流逝和經驗的累積而改變的。
01/18 01:55, 88F
推
01/18 02:20, , 89F
嗯嗯 ^^
01/18 02:20, 89F
推
01/18 03:14, , 90F
遞迴只應天上有，凡人該當用迴圈。
01/18 03:14, 90F
→
01/18 03:27, , 91F
樓上...XD
01/18 03:27, 91F
推
01/18 10:21, , 92F
其實我覺得執行效率和易讀性有時不可兼得 而大量的註解和
01/18 10:21, 92F
→
01/18 10:22, , 93F
輔助圖形也可能增加理解程式碼的時間 一點淺見..
01/18 10:22, 93F
‣ 更多 truesword 的文章
文章代碼(AID): #1BKmcYeK (C_and_CPP)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 6 之 9 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共9篇)
C_and_CPP 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 truesword 的文章
文章代碼(AID): #1BKmcYeK (C_and_CPP)