高阶函数初探(四)

这周主要将上周讨论的方法实现了，并将十个项目进行了详细的统计，得到了第一版的数据，从数据中我们或许能看到一点东西。

主要工作

上周主要做了三个工作：

• 完善提取调用关系的代码
• 将每个函数声明和调用都与相应的作者进行匹配
• 统计了第一版较为完善的信息

提取调用关系

按照之前讨论的思路，首先遍历项目，提取所有的函数声明的信息，并保存函数的类名，方法名，参数的数量和函数参数的位置，然后再遍历一遍项目，提取每一个函数调用，并根据之前提取的信息进行匹配函数的声明，通过一次又一次的修改测试，整出来一个尚可的版本。
提取函数调用并保存到数据库，便于快速查询。

但是，提取调用关系仍然存在以下问题(每跑一个项目都会发现相应的问题，修改完以后还要重新跑一遍之前的项目，心累)。

• 如果高阶函数在声明的时候存在默认值，在函数调用时无法根据参数来判断是否为高阶函数调用。
• 创建新的对象的时候没有用new关键字，因为在匹配函数调用时，我需要知道这个调用具体属于哪个对象，属于哪个类，我将一个文件中的所有new出来的对象存在一个symbol表中，但是没有关键字new不容易识别：
  
• 一些非常奇怪的调用：
  
  
• 一些高阶函数十分相似的：
  
• 嵌套函数，有些高阶函数嵌套在一些函数里面，按照常理这些函数并不属于某些class或者object,只能在所嵌套的函数内使用，所以这些嵌套函数并没有统计。
  

除了上面的问题，提取的函数调用基本没有什么问题，还有就是在函数调用类型判断的时候，类型一的数量实际上会比实际上多，因为里面会包含那种从上层函数直接继承来的函数。因为在判断类型的时候，类型一是处于逻辑上的else语句上。

作者匹配

上周解决了提取git log困难的信息，采用了将其存入数据库的方法，现在派上了用场了，我的思路是根据函数所在文件的路径以及函数的第一行来进行匹配。

但是其中也存在一些问题，95%以上的作者都能找到，另有一些函数没有找到作者，最后通过发现，函数第一行都能匹配到，但是路径总是不对，最后通过观察发现，有些文件或者变换了路径或者修改了文件名称导致在log文件中没有找到，最后只能通过手动将剩余没有找的信息补充完整。

最终的统计结果

详细的信息(每个函数声明和调用的信息)sql文件已上传，最终的简略表格统计在这里列出。

• 基本信息
  
• 高阶函数声明代码行数信息
• 高阶函数声明类型信息
  
• 高阶函数调用类型信息
  
• 高阶函数声明调用作者信息