Atitit.ide技术原理与实践attilax总结
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:1466519819@qq.com
转载请注明来源： 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每部分代码数统计
|
分类 |
包含内容 |
源码行数 |
|
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