推 aiyswu:發現新東西,受益了 02/12 15:17
※ 引述《MOONRAKER (㊣我愛火星人 XDDDD)》之銘言：
: : → MOONRAKER:這是一個壞的用法 XD 02/10 16:35
: : 推 averywu:變數的變數 02/10 17:37
: : 推 tkdmaf:程式沒有所謂好的壞的用法。而是因地制宜而用。 02/10 18:26
: 這是一個有很多顧忌的用法，所以說他是壞的用法
: 看來tk先生是從來不考慮這種用法的危險性所以才那麼輕鬆
: 常常看到一些老的程式裡有人這樣來引入form變數
: 那麼我有兩個表單，裡面都有變數叫username
: 用這種方式引入時會發生什麼事？
: 可能你覺得這沒有什麼，對，這倒是真的沒有什麼
: 那麼我們換個題目
: 某使用者下載了這個網頁，然後把表單內容改掉，自己加上其他的變數
: 而server端仍然用這種「變數的變數」方式引入表單
: 那麼引入時就可能取代掉程式裡面該scope下的任何一個變數。
: 改喔！UID任我改！VALID任我改！password任我改！hashkey任我改…隨便我愛改什麼。
您也是相當高調的不管別人講的因地制宜是什麼意思。
或者當別人沒再意到這種狀況？
foreach($_POST as $key => $value){
$$key => $value;
}
當然會有你說的情況發生。
但如果是：
foreach($_POST as $key => $value){
$key = "p_".$key;
$$key = $value;
}
ok！uid任您改，valid任您改，password任您改，什麼都讓你用html去改。
反正改完跑到我程式一樣拒絕處理。
方法本身有優點有缺點不管什麼情況都有可能。
因地制宜不是指當用則用。
而是指在知道他的缺點而能補齊其問題點所在的情況下。
如果他是合用的則仍然可以繼續使用。
不要一昧的去排斥各種可能的方法：如果你能確保他是安全無誤而且可以使用的話。
另外有人提到註解我就順便說了。
使不使用註解這可以算是一個爭議。
我不能說你使用註解就不對。
但你也不能說我不用註解就表示我不好。
但前提在於：你對於你的程式架構所表達的清楚程度有多少。
很多人把php的結構混雜的亂七八糟。
他需要靠註解告訴自己(還不是告訴別人喔！)這一段程式碼到底在處理什麼樣的功能。
但我們反過來說，假設你的程式架構是清楚明白的，根本上甚至以物件、函式的名稱就
足以知道這個程式的功能面在做什麼樣的事情。那註解就沒有必要去產生。
在學習UML架構圖的時候，我們就很清楚知道什麼物件是什麼功能，繼承物件是繼承什麼
功能。定義介面告訴我們需要實作什麼功能。
當你把每一段程式都切成一個一個功能面的東西時。
他就是一個功能。那既然都知道他的功能面的用途。
何必還要再為他下註解？
最多就是程式開頭告知這隻程式的用途為何。
各位有興趣去看看像是ucenter之類的軟體，看看人家的程式中寫了多少行的註解。
(開頭的說明不算)
看看當人家外國人在使用良好的設計方法不斷的改善程式的設計及效率時。
我們花了多少的時間在其實並沒有必要的事情上。
這不是一個理論也不是一個高調！
而是究竟有多少工程師會去真的在意程式設計的架構本身。
這邊我相當良心建議各位有疑慮的去找這五本書好好讀完。
我也還沒讀完，但一直在思考書中說的究竟是些什麼道理。
1.專業PHP5程式設計(不是專業PHP程式設計，也不是專業PHP5程式設計指南)
2.重構-改善既有程式的效率
3.重構-向範式前進
4.敏捷開發原則樣式與實務
5.極致編程(eXtreme Programming)
這些書全部都是外國人寫的。
但全部都有中文譯本。
看看別人怎麼說，怎麼做。又看看我們自己卻是怎麼去面對程式碼的。
順便就再提。
2/21日在台北的南港就有敏捷開發軟體座談會。
講師是從事程式設計20年的資深設計師同時也是軟體公司的老闆。
我們很期望大家都能正視程式結構所可能發生的問題。
軟體的安全性固然很重要，但是無法快速維護及修改的程式是更加可怕的。
希望各位了解，我講的東西不是說隨便說說，而是有文獻、書籍以及一些資深的
工程師他們所告訴我的設計經驗。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.43.158.77
※ 編輯: tkdmaf 來自: 114.43.158.77 (02/11 13:13)
※ 編輯: tkdmaf 來自: 114.43.158.77 (02/11 13:18)