推 buganini:架設$k的內容是'lala' $$k就是$lala 02/10 14:47
→ buganini:假 02/10 14:47
→ buganini:這個code不是很好 變數全部撒在外面 而且 02/10 14:48
→ buganini:而且要確定$k符合變數命名規則 02/10 14:48
→ tsailk:感謝b大! 我懂了 02/10 15:06
→ MOONRAKER:這是一個壞的用法 XD 02/10 16:35
推 averywu:變數的變數 02/10 17:37
推 tkdmaf:程式沒有所謂好的壞的用法。而是因地制宜而用。 02/10 18:26
推 buganini:這個用法通常是用來選擇變數或函數 02/10 18:28
推 tkdmaf:另外變數命名有時不該去省略(或許是你找到的範例是如此。) 02/10 18:28
→ tkdmaf:是我的話一定是寫 $key => $value 這樣簡單明瞭又清楚。 02/10 18:29
→ buganini:我自己用的倒是蠻常寫foreach( as $k=>$v) 的.. 02/10 20:24
→ buganini:還有$t $i $j 不過都有固定用途啦 02/10 20:24
→ tkdmaf:良好的變數命名會讓接手的工程師容易閱讀。 02/11 09:33
→ tkdmaf:就算是自己維護也更容易知道那是什麼(尤其是一年後再改) 02/11 09:34
推 clubflymf:感覺不管命名什麼，程式註解才是重點 @@ 02/11 10:18
→ MOONRAKER:這是一個有很多顧忌的用法，所以說他是壞的用法 02/11 11:34
→ MOONRAKER:看來tk先生是從來不考慮這種用法的危險性所以才那麼輕鬆 02/11 11:35
→ MOONRAKER:常常看到一些老的程式裡有人這樣來引入form變數 02/11 11:36
→ MOONRAKER:那麼我有兩個表單，裡面都有變數叫username 02/11 11:36
→ MOONRAKER:用這種方式引入時會發生什麼事？請問tk先生可有想過？ 02/11 11:36
→ MOONRAKER:唱高調的人真多。 02/11 11:37
→ tkdmaf:所以我說「因地制宜而用」。moonraker您太激動了！ 02/11 12:14
→ tkdmaf:程式註解一點都不重要。敏捷開發甚至告訴你不該去寫註解。 02/11 12:17
→ yuleen123:天阿! 誰跟你說註解不重要... 暈倒 02/11 12:25
→ tkdmaf:外國人說的！敏捷軟體開發方法說的！ 02/11 12:35
→ tkdmaf:只要變數命名原則夠清楚，程式的架構明白。 02/11 12:36
→ tkdmaf:註解根本就是多餘的。 02/11 12:36
→ tkdmaf:最多只有程式最開頭告訴你這支程式要幹嘛！ 02/11 12:37
→ tkdmaf:其他的部份根本沒有加註解的必要。 02/11 12:37
推 tkdmaf:註解寫得多，那就是打字打得多。寫程式的時間變少。 02/11 12:51
→ tkdmaf:而且……註解寫的再好，如果程式架構亂七八糟。 02/11 12:51
→ tkdmaf:一樣難以維護及修改。 02/11 12:51
推 birdhackor:註解還是很有用啦~至少我可以用中文打些附註事項 02/11 17:12
→ JeffMcBride:tk大指的是變數要像這樣嗎? $tmp_get_db_fetch_count 02/11 18:45
→ JeffMcBride:之類的吧... 02/11 18:45
→ JeffMcBride:不註解還看得懂 大概程式碼全部要重看吧... 02/11 18:47
推 asklove:沒有註解的話，不用多，五千行的程式就好，你覺得要花多久 02/13 09:59
→ asklove:一個剛接手的人才能看懂這五千行到底在做甚麼? 02/13 09:59
→ asklove:說不定重寫一個還比較快 這樣真的有節省時間? 02/13 09:59
推 tkdmaf:測試code會告訴你他測試的函式功能是做什麼的！ 02/13 21:59
→ tkdmaf:了解測式code對函式的好處的話！比看5000行的註解還快。 02/13 22:00
→ tkdmaf:講測試code也不對，應該是說測試的表單。 02/13 22:00
→ tkdmaf:因為測試的表單會指出每個程式函式是做什麼樣的功能。 02/13 22:01
→ tkdmaf:簡單來說！能用電腦幫我們找資料，為什麼要用人腦去做？ 02/13 22:01
→ tkdmaf:不在程式中寫註解，不代表我不能把功能為何寫在別的地方。 02/13 22:02
→ tkdmaf:如果我們的函式功能出來就像是一條列試的清單。 02/13 22:03
→ tkdmaf:是不是就可以從清單去了解他所代表的函式的功能？ 02/13 22:03
→ tkdmaf:所以並非「不寫註解」，而是有「絕佳的」替代方案。 02/13 22:04
→ asklove:別傻了 通常是要找程式BUG或嵌入新功能才要去看舊CODE 02/14 19:52
→ asklove:既然是當初就沒想到的東西 你覺得測試CODE會有寫到嗎? 02/14 19:52
→ asklove:今天老闆不會沒事要新人去了解舊CODE怎麼寫而已 02/14 19:53
→ asklove:通常都是為了加新功能或除BUG 這時如果只有程式使用說明 02/14 19:54
→ asklove:要想把BUG找出來，或想找出該從哪段著手改寫程式 02/14 19:54
→ asklove:得花上非常多的時間精力才行 02/14 19:55
推 tkdmaf:所以我也建議asklove來參加敏捷軟體課程。 02/15 00:53
→ tkdmaf:我還是那句話：聽我說！不如聽資深的專家怎麼說。 02/15 00:53
→ tkdmaf:專家會告訴你：電腦明明能做的事，幹嘛要用人腦去做？ 02/15 00:54
→ tkdmaf:如果大家都還不能跳脫用「眼睛」看程式的話。 02/15 00:55
→ tkdmaf:那就是每天下午15:30喝下午茶或是加班加到死二種結果。 02/15 00:55
→ tkdmaf:我覺得沒親耳聽過，或是親眼看到專業人士的程式編寫方式前 02/15 00:56
→ tkdmaf:不需要太早去下定論，當然如果你的年資有20年的話另當別論 02/15 00:56
推 tkdmaf:那位講師的抱負倒也不是什麼胸懷大志！不過就是： 02/15 00:58
→ tkdmaf:提高程式設計師的工作以及生活的品質及身體的健康。 02/15 00:58
→ tkdmaf:那位講師讓我見到曾經連想都沒想過卻非常迅速有效而確實的 02/15 01:00
→ tkdmaf:開發程式。相信是因為親眼所見所聞而非空談理論。 02/15 01:00
→ tkdmaf:去看看人家憑什麼敢簽下：超過交件期最少賠簽約金20倍。 02/15 01:02
→ tkdmaf:但是卻從來沒有賠過任何一次的專案。 02/15 01:02
→ tkdmaf:假如他所談的東西非實際經驗而是理論的話早就賠光家產了。 02/15 01:03
→ tkdmaf:很棒的一個關於test unit對軟體品質控制的文章。 02/16 12:35
→ weiyucsie:我覺得這段程式碼，可以簡單的用extract函數取代@.@ 02/16 20:52