Re: [請益] 新手請問一小片段程式

看板PHP作者neversay (子不語)時間15年前 (2010/02/12 16:39)推噓2(2推 0噓 7→)

留言9則, 2人參與討論串8/8 (看更多)

※ 引述《tkdmaf (皮皮快跑)》之銘言： : 使不使用註解這可以算是一個爭議。 : 我不能說你使用註解就不對。 : 但你也不能說我不用註解就表示我不好。 I hate XP jihadist...... 身為一個XP的愛用者，看到這種XP傳教式的言論就會讓我受不了。如果你愛這套方法，請不要用極端的斷言傷害它。註解，從組合語言時代開始就有他非常重要的意義，事實上，註解不是//或/**/或#這樣而已，程式碼本身就是一種註解，我想你讀過的 XP書籍也說過這段話，你的言論裡面也提到了code as comment的重要性。但是你將code as comment的地位提高到神聖，將#///**/貶低成危害系統的東西，甚或是一種評斷PG功力不足的有害指標，就是一種jihadist。 #///**/這種東西就跟switch一樣，用太多有壞處，但是當用的地方而不用是種無益處的事情。註解有幾個地方一定要用: 1.描述spec:尤其在weak type language，我自己在hack PEAR時就吃過好幾次 comment不足的苦頭，若是它能在某些特難用又古怪的function開頭多點comment，告訴我這坨該死的牛糞在搞些什麼，就能減少很多不必要的浪費。當然XP派能說為啥作者不refactoring這些難用的function，原因就是這些function 就是得這麼難用，才能適應各種稀奇古怪的需求。世界不是照著每個人的腦袋運轉的。 2.告訴Why:有時候一個區域的code是為了特別的business logic而寫的，本身並沒有任何技術上的意義，這邊我們就一定要用註解寫下business logic與code logic的對應，以及為什麼這樣實作，否則過了十年某個大學剛畢業的新鮮人來維護這段code，他就得花八小時研究原本用一小時就能理解的business logic，就因為你沒有提供任何說明式的進入點然後又把code寫的很自我風格。 3.為效率而做的最佳化:最佳化永遠是PG心頭的痛，為了讓執行效率增加一千倍，把一小段code改的面目全非是不得不的手段，在這種情況下一定要用comment一行一行把 [我在這裡犯了什麼code罪]老老實實自白，否則難保三個月後來個需求變動，這邊的 optimized code就成了不明懸案。只能把眼睛遮起來當作沒看到，另起爐灶，然後又重新掉到效能問題裡面。 : 但前提在於：你對於你的程式架構所表達的清楚程度有多少。 : 很多人把php的結構混雜的亂七八糟。 : 他需要靠註解告訴自己(還不是告訴別人喔！)這一段程式碼到底在處理什麼樣的功能。 why not? 就算我把PHP寫的井井有條舒服至極，在該老老實實寫comment的地方，我還是會寫，就算是告訴明天的自己昨天我幹了什麼蠢事，也好過我連昨天沾沾自喜幹了什麼天才事，但今天發現其實是蠢事都記不起來。 : 最多就是程式開頭告知這隻程式的用途為何。 : 各位有興趣去看看像是ucenter之類的軟體，看看人家的程式中寫了多少行的註解。 : (開頭的說明不算) 那您要不要去看看linux kernel檔案程式中寫了多少的註解? 重點不在要不要寫註解，而是有沒有必要寫，有必要寫，就乖乖的寫。 : 看看當人家外國人在使用良好的設計方法不斷的改善程式的設計及效率時。 : 我們花了多少的時間在其實並沒有必要的事情上。 : 這不是一個理論也不是一個高調！這不是一個理論但卻很高調，若是有人因為信了你的論點而加入XP教，就是在扯其他PG的後腿。我以前也曾經很信XP的論點，現在依然使用了很多XP的技術 (unit test, test-driven, self documentation)，但是我對於XP教不屑一顧的沙場老兵(switch, comment, int i,j,k)依然充滿敬意。 : 1.專業PHP5程式設計(不是專業PHP程式設計，也不是專業PHP5程式設計指南) : 2.重構-改善既有程式的效率 : 3.重構-向範式前進 : 4.敏捷開發原則樣式與實務 : 5.極致編程(eXtreme Programming) 專業PHP5程式設計可貴的地方不在於PHP部分，也不在business logic的經驗，而是在資訊系統建構的方法論很成熟，那裡面的sample program大部分都有 framework可以替代不用自己手造，但是他為了處理特定通用問題而實作通用架構的精神是很值得細讀的，但是你也可以看到它在程式裡面生了多少註解。在沒有註解的幫助下，您要怎麼hack他們的程式啊? (順帶一提，這本書我在天瓏買過99元本，令我大呼物超所值) 23這兩本書在沒看過Design pattern之前，是不會給PG有什麼益助的，頂多就是覺得好帥好華麗，但是在沒有經過Design pattern奠基的情況下，無法融會貫通或舉一反三，看了等於沒看。大概只能當成勵志書籍吧...... 45這兩本書，看完不等於看懂，要身體力行並且領悟這兩個方法有多麼讓人度爛之後，能體會它的缺陷與權衡，才算是看懂吧。如果以上書本都攻略完了，我也順便推薦一本書:CodeCraft (編程創藝) 雖然我覺得這本書跟創造或藝術一點也沒啥關係，但是他是一本非常實際又血腥的軟體工廠紀實，同時點出很多很小卻很重要的PG陋習。若能看完這本書的每一章然後與作者一起苦笑，那就太好了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 60.250.147.33 ※ 編輯: neversay 來自: 60.250.147.33 (02/12 16:42)