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