Atitit.ide技術原理與實踐attilax總結

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

1.1. 語法著色

語法高亮要靠parser,跳轉到定義處編譯器要提供symbol和源碼位置字典,重構編譯器要重寫ast, 要支持調試視窗里運行表達式甚至直接調用函數,這個要運行時支持。編譯

1.2. 智能提示

1.3. 類成員outline..func list

1.4. 類型推導(type inference)：

1.5. Remote debug

,attach上去調

1.6. debugging api包一個gui就夠了

1.7. expression evaluation

這種黑魔法一樣的東西（僅針對編譯型語言這麼說，解釋型應該會容易很多），當初應該花了大量的精力開發；

作者::  ★(attilax)>>>   綽號:老哇的爪子 （ 全名：：Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿爾 拉帕努伊 ） 漢字名：艾龍，  EMAIL:[email protected]

轉載請註明來源： http://www.cnblogs.com/attilax/

1.8. 如Java Compiler API

 我主要關註的是編譯器，所以下麵就編譯器與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++自己的，興許也是可能的未來。

1.9. Ide每部分代碼數統計

對應的圖表：

項目分析

可見整個IDE最複雜的部分在於代碼模型的處理，代碼數量幾乎是第二名（IDE）的兩倍之多，占整個項目代碼的比例也接近 50% 了。我沒有進一步分析，不過大概可以想象，代碼編輯時的文本著色、語法提示、代碼生成、輔助分析、重構等功能應該都與此相關。如果真的想自己寫一個IDE的話，這一部分肯定是個難啃的硬骨頭。

參考資料

IDE的現實分析 - 對“開發一個IDE難度有多大”問題的回答 _ Shuhari的博客.html

開發一個IDE難度多大_ - 編程 - 知乎.html