售前问题

接手一份代码，通常会从函数名、配置项或一段报错文字开始查。用Source Insight搜索时，有时能找到几十处同名内容，却分不清哪一处与问题有关；有时明明在文件里看到了目标文字，工程搜索却没有结果。这些情况未必是索引损坏，也可能是搜索范围和匹配选项没有对应当前任务。找文字、找定义和找引用各有用途，分清之后，排查会少些来回尝试。

拿到一份源码，直接打开文件虽然能看内容，但跨文件查找函数、梳理调用关系时，还是需要建立工程。有时工程名称已经填好，确认后却提示无法写入；也有工程能打开，文件列表里却没有代码。这两种情况要分开判断。Source Insight需要保存工程数据，也需要把源码加入索引，目录设置、文件筛选和解析状态都会影响结果，不能只看工程窗口有没有出现。

代码扫描完成后，文件里能看到问题，却找不到相关行的作者，排查时就少了提交记录这个线索。SonarQube的代码归属信息来自版本控制历史，执行扫描的账户不能直接代替代码作者。下面以Git仓库和SonarScanner CLI为例，说明SCM配置与作者缺失的处理方法，网页操作采用英文界面名称。

阅读C/C++代码时，一个宏可能决定缓冲区长度，也可能把一段操作封装成简短的调用。点进定义后，若打开的是另一套平台的头文件，继续往下分析就容易看错。Source Insight按工程符号信息定位代码，结果还会受工程范围和解析条件影响。下面以Source Insight 4英文界面为例，说明宏定义查看和跳转排查方法，这里的宏指代码中的预处理宏。

在代码阅读和维护过程中，Source Insight通常需要根据文件类型加载对应的语法解析规则。对于项目中新增的脚本文件、自定义源码文件或者特殊后缀文件，如果没有建立正确关联，软件可能会将文件当作普通文本打开，导致关键字无法高亮、函数结构无法识别等情况。Source Insight支持自定义文件类型配置，不过后缀关联、语言选择以及项目重新解析都会影响最终显示效果。

SonarQube可以把第三方静态分析工具产生的问题导入项目，与自身检测出的Issue一起查看。对于已经适配SonarQube的工具，可以使用对应的报告参数；其他分析器可以转换成Generic Issue格式或SARIF格式再导入。报告文件已经生成但SonarQube页面没有显示问题时，要先确认Scanner实际读取到了报告，再检查报告格式、源码路径、分析范围和当前查看的分支，不能只看报告文件是否存在。