Atitit.ide技術原理與實踐attilax總結
1.1. 語法著色1
1.2. 智能提示1
1.3. 類成員outline..func list1
1.4. 類型推導(type inference)： 1
1.5. Remote debug1
1.6. debugging api包一個gui就夠了 1
1.7. expression evaluation 2
1.8. 如Java Compiler API2
1.9. Ide每部分代碼數統計3
語法高亮要靠parser,跳轉到定義處編譯器要提供symbol和源碼位置字典,重構編譯器要重寫ast, 要支持調試窗口裡運行表達式甚至直接調用函數,這個要運行時支持。編譯
,attach上去調
這種黑魔法一樣的東西（僅針對編譯型語言這麼說，解釋型應該會容易很多），當初應該花了大量的精力開發；
作者:: ★(attilax)>>> 綽號:老哇的爪子 （ 全名：：Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿爾 拉帕努伊 ） 漢字名：艾龍， EMAIL:[email protected]
轉載請注明來源： http://www.cnblogs.com/attilax/
我主要關注的是編譯器，所以下面就編譯器與IDE多聊幾句。
當然，現實中開發一個IDE還真的有可能得去實現源語言的編譯器。
上面提到的SharpDevelop/MonoDevelop，目前新的版本已經改為基於微軟的Roslyn編譯器來提供C#支持，語法高亮、錯誤提示、智能提示等都做得很好了。但其早期版本其實非常弱，只有所謂“語法高亮”，可以參考這個文檔。後來為了實現智能提示等功能總算決定實現個真正的C# parser。不過它並沒有基於任何現成的編譯器來支持IDE功能，而是自己寫了一個，上面的書中第12章就是介紹這個parser的，不過寫得有點亂嗯。
以Eclipse的Java開發環境（JDT）為例，它要實現准確的語法高亮和語法錯誤提示，就得按照Java語法實現一個完整的parser；它要實現實時的語義錯誤提示，就得按照Java語義實現一個完整的語義分析器，而且為了良好的用戶體驗，它可能要內建更多的對錯誤模式的檢查和提示。做到這裡，離一個完整的Java源碼編譯器也就只剩一個很簡單直觀的代碼生成器（code generator）了。於是Eclipse做了ECJ——Eclipse Compiler for Java，整合在Eclipse JDT中。
在此基礎上，Eclipse JDT還有項目模型，將項目裡的各種資源都用一個統一的模型管理起來，從workspace到project、package、file然後裡面的class/interface這樣一直下去。在class/interface層面上這個模型用的就是ECJ的AST。
其實如果有一個現成的對IDE支持良好的編譯器的話，實現一個IDE就不必費那麼多事自己去寫編譯器。但是Eclipse誕生時，主流的Java源碼編譯器javac並不開源，而IBM當時主流的Java源碼編譯器Jikes是用C++寫的，要整合在用Java寫的Eclipse裡不太方便，所以才要自己寫。
有了這個編譯器之後，Eclipse倒是可以做許多“非常規”的事情。例如說它可以為有錯誤的源碼文件生成Class文件，而且這個Class文件可以一直執行到源碼裡有錯的地方然後拋出異常——這種事情javac就不太可能會去做。
後來javac開源了，而且開放出許多便於IDE實現自身功能的API出來（例如Java Compiler API），後來的Netbeans就干脆直接用javac來實現語法高亮、報錯等各種功能了。背後的故事可以參考這篇博文：NetBeans IDE 6.0
而一個反例就是微軟的Visual Studio裡的C++支持。Visual C++自身是個優秀的優化編譯器，但它的前端部分（詞法/語法/語義分析+中間代碼生成）的歷史非常非常“久遠”，原始設計並未考慮支持IDE的功能，所以Visual Studio IDE裡的C++支持其實用的是另一套完全不同的C++ parser（購買自EDG），既增加了復雜度又無法保證兩套parser之間完全的兼容性。
當然微軟也早就意識到了這個問題。近來，隨著對C++14的支持，微軟大幅更新了其Visual C++編譯器的前端（參考Rejuvenating the Microsoft C/C++ Compiler），按照這個路子走下去的話，在IDE裡替換掉EDG的C++ parser改為直接用Visual C++自己的，興許也是可能的未來。
分類
包含內容
源碼行數
Code Analysis
代碼模型、分析和生成相關
123957
IDE
IDE程序和界面相關
62940
Visual Editor
可視化編輯器
30760
Text Editor
文本編輯器
20264
Tools
版本控制和幫助等輔助工具
11556
Language
語言綁定，包括C#，VB等
9292
Debugger
調試器
9238
Framework
Asp.Net Mvc等框架支持
8513
Misc
雜項
2289
Builder
構建和MsBuild相關
1774
Data
數據庫支持
1396
對應的圖表：
項目分析
可見整個IDE最復雜的部分在於代碼模型的處理，代碼數量幾乎是第二名（IDE）的兩倍之多，占整個項目代碼的比例也接近 50% 了。我沒有進一步分析，不過大概可以想象，代碼編輯時的文本著色、語法提示、代碼生成、輔助分析、重構等功能應該都與此相關。如果真的想自己寫一個IDE的話，這一部分肯定是個難啃的硬骨頭。
參考資料
IDE的現實分析 - 對“開發一個IDE難度有多大”問題的回答 _ Shuhari的博客.html
開發一個IDE難度多大_ - 編程 - 知乎.html
