※ 引述《walking (Rainbow)》之銘言：
: ※ 引述《hougzou (晉級！)》之銘言：
: : 不好意思潑些冷水...
: : 一個人在一定時間內閱讀一定資料，腦中所能分析的data是有一定限度的。
: : 太過於斑斕鮮豔的色彩定義，對於程式碼閱讀以及撰寫來說，其實是種雜音。
: : 當程式設計人員可以用反射思考來判斷程式碼元素的語意時，
: : 太過精細的彩色分類反而會造成判讀上的紊亂。
: 我滿能認同顏色太過精細,是容易造成閱讀上的負擔,
: 但,其實所以還要看如何去巧妙去運用這些技術或在改良,不是嗎?
: 有滿多 構想,或技術,剛出來時,還不是很好用,
: 經過使用者意見改進之後,漸漸變好用並普及..
: 比方如果有對顏色視覺人體工學等,比較有研究的人來配色,
: 應該會好許多.
: 或,某些情況才啟動,
: 比方使用者要找某段非常複雜的程式中, },) 或 #endIf 少一個時.
: 或某單行 (),[] 巢狀超過3時,
: 像C 的#define,經常看到後面是一堆.
: http://www.actionxp.com/editor/help/c.htm
: 置於範例,是我概略分配每層色,對顏色的配色,也應該有改進的空間.
: : 另外，一個好的產品設計出來，是要符合人類本性的，
: : 如果技術是要人刻意「學習」或習慣特定的辨識方法，
: : 在沒有任何協助產能增加的利基下，其實這做法是本末倒置的。
: windows 剛出來前幾年時,一些dos極熟的人,不也都嫌跟慢,多此一舉.
: code folding,或者像Delphi在左邊視窗列出各種變數常數物件的清單,
: 我想信對一些原先就已經程式設計多年的老手而言,
: 剛開始使用也會不習慣,怎麼多這些東西,可能需要幾天熟練一下.
: 或者就把它關起來.
: : 或者你認為這樣的作法的確可以增加程式產能或偵錯速度，
: : 但則那是你為了專利必須實作出來並要能去證明的。
: 這應該不然證明,比方舉個單行多()的例子,
: 巢狀<Table><Tr>等.
: 但也如你所提到,所以顏色的配置好壞,習不習慣,也就滿重要的.
: 不然可會有反效果.
事實上自從網友yoco介紹Ultimate++後我就對TheIDE以顏色分段念念不忘了:p
前些時候正打算將此功能加進Scintilla中, 只怪專案進度實在很趕.
話說雖然此idea創新性或許不足以申請專利, 但開發出一套軟體是可行的
我已經有這個構想很久了. 常用的Source Insight固然方便(不只顏色, 連字型都縮放了)
但是它屢次更新都沒有更新到重點(如:開啟Visual Studio等專案檔)
也沒有Syntax Folding(挖咧...)
Anyway, 這類工具(Code Comprehension Tool)市面上沒幾套, 或許是個值得切入之處
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.58.73.1