CN112631894A - 代码检测方法、装置、存储介质及计算机设备 - Google Patents

Abstract

本发明公开了一种代码检测方法、装置、存储介质及计算机设备，涉及程序开发技术领域。其中方法包括：在待检测项目中引入代码检测插件，并将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中；在待检测项目的编译阶段，通过代码检测类文件对代码检测路径下的代码文件和资源文件进行代码检测；输出代码文件和资源文件的代码检测结果。上述方法通过在待检测项目中引入代码检测插件和配置自定义的代码检测类文件，可以在编译阶段自动实现定制化的源代码检测功能，代码检测效率较高，此外，上述方法还通过在待检测项目中配置代码检测路径，进一步提高了源代码文件的检测效率，并且提高了源代码文件检测的针对性。

Description

代码检测方法、装置、存储介质及计算机设备

技术领域

本发明涉及程序开发技术领域，尤其是涉及一种代码检测方法、装置、存储介质及计算机设备。

背景技术

开发人员在进行项目开发时，通常需要在编写代码的过程中不断检测自身的源代码文件是否符合团队制定的编码规范，这就需要随时对源代码文件进行编写规范的检测，以确保源代码文件的可用性。

通常来说，源代码文件的检测主要包括开发环境检测、代码文件检测和资源文件检测等多个环节，现有的代码检测方法主要是单独针对开发环境进行检测，单独针对代码文件进行检测，以及单独针对资源文件进行检测，这样的代码检测方法极大的降低了源代码文件的检测效率，并且，现有的代码检测方法也无法有效的实现定制化的编码规范检测需求，这也导致了源代码文件的编码规范检测的局限性较大。

发明内容

有鉴于此，本申请提供了一种代码检测方法、装置、存储介质及计算机设备，主要目的在于解决现有技术中源代码文件的编码规范检测效率较低以及检测局限性较大的技术问题。

根据本发明的第一个方面，提供了一种代码检测方法，该方法包括：

在待检测项目中引入代码检测插件，并将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中；

在待检测项目的编译阶段，通过代码检测类文件对代码检测路径下的代码文件和资源文件进行代码检测；

输出代码文件和资源文件的代码检测结果。

可选的，将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中，包括：将代码检测插件中的至少一个代码检测类文件和至少一个代码检测类文件对应的代码检测路径配置到待检测项目中，其中，至少一个代码检测类文件包括代码文件检测类文件和/或资源文件检测类文件。

可选的，将代码检测路径配置到待检测项目中，包括：将待检测项目中待排除的的代码检测路径配置到待检测项目中；和/或将待检测项目中待排除的代码文件和/或资源文件配置到待检测项目中。

可选的，通过代码检测类文件对代码检测路径下的代码文件和资源文件进行代码检测，包括：通过XML分析和JSON对象分析，扫描出代码检测路径下所有的代码文件和资源文件；通过代码检测类文件中的字节码校验规则和正则匹配规则，对代码文件和资源文件中的内容进行逐一检测。

可选的，输出代码文件和资源文件的代码检测结果，包括：若代码文件和资源文件中的内容与代码检测类文件中的预设规则相符，则输出编译通过的检测结果；若代码文件和资源文件中的内容与代码检测类文件中的预设规则不相符，则输出不相符的提示信息以及编译不通过的检测结果。

可选的，在待检测项目中引入代码检测插件之前，该方法还包括：基于开发环境检测插件构建代码检测项目，并在代码检测项目中添加代码检测类文件；将构建好的代码检测项目进行打包处理，得到代码检测插件。

可选的，基于开发环境检测插件构建代码检测项目，并在代码检测项目中添加代码检测类文件，包括：基于开发环境检测插件的基础套件和基础架构套件，构建代码检测项目；在代码检测项目中添加基础检测类文件，其中，基础检测类文件中封装有代码检测路径排除属性和文件检索方法；在代码检测项目中添加代码检测类文件，其中，代码检测类文件继承基础检测类文件并实现代码检测方法。

根据本发明的第二个方面，提供了一种代码检测装置，该装置包括：

检测配置模块，用于在待检测项目中引入代码检测插件，并将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中；

代码检测模块，用于在待检测项目的编译阶段，通过代码检测类文件对代码检测路径下的代码文件和资源文件进行代码检测；

结果输出模块，用于输出代码文件和资源文件的代码检测结果。

根据本发明的第三个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述代码检测方法。

根据本发明的第四个方面，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述代码检测方法。

本发明提供的一种代码检测方法、装置、存储介质及计算机设备，首先在待检测项目中引入代码检测插件，并将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中，然后在待检测项目的编译阶段，通过配置好的代码检测类文件自动对代码检测路径下的代码文件和资源文件进行代码检测，最后输出代码文件和资源文件的代码检测结果，呈现给开发人员或测试人员。上述方法通过在待检测项目中引入代码检测插件和配置自定义的代码检测类文件，可以在编译阶段自动实现定制化的源代码检测功能，代码检测效率较高，此外，上述方法还通过在待检测项目中配置代码检测路径，实现了对指定路径下的代码文件和资源文件进行同步检测，进一步提高了源代码文件的检测效率，并且提高了源代码文件检测的针对性。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1示出了本发明实施例提供的一种代码检测方法的流程示意图；

图2示出了本发明实施例提供的另一种代码检测方法的流程示意图；

图3示出了本发明实施例提供的一种代码检测装置的结构示意图；

图4示出了本发明实施例提供的另一种代码检测装置的结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在一个实施例中，如图1所示，提供了一种代码检测方法，以该方法应用于客户端或服务器等计算机设备为例进行说明，包括以下步骤：

101、在待检测项目中引入代码检测插件，并将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中。

其中，项目指的是正在开发中或者开发完成待发布的源代码文件，源代码文件通常包括多个代码文件和资源文件，其中，类文件是代码文件中的一种，代码检测类文件则是指用于代码检测的类文件。在程序开发领域，一份源代码文件通常也称为一个项目，进一步的，待检测项目指的是需要进行编写规范检测的源代码文件，在本实施例中，源代码文件具体可以是用java语言编写的。

进一步的，代码检测插件指的是代码检测项目经过打包处理后生成的插件，在代码检测项目中，可以根据实际项目需要建立一个或多个代码检测类文件，每一个代码检测类文件都可以对应检测一个或多个文件并记录有一条或多条规范判断语句，以对待检测项目中的代码文件和资源文件进行针对性的语句规范化检测。

具体的，在进行代码规范检测之前，可以首先在待检测项目中引入代码检测插件，其中，代码检测插件可以通过依赖jar包的方式引入到待检测项目中，然后可以将代码检测插件中的代码检测类文件以及代码检测类文件的检测路径配置到待检测项目的资源文件中，其中，代码检测类文件的数量可以为一个或多个，且每一个代码检测类文件都可以配置一个与其对应的检测路径，当然，代码检测类文件也可以不配置对应的检测路径，在这种情况下，该代码检测类文件的检测路径就是待检测项目的全路径。

102、在待检测项目的编译阶段，通过代码检测类文件对代码检测路径下的代码文件和资源文件进行代码检测。

具体的，在代码检测插件和代码检测类文件配置完成后，计算机设备可以对待检测项目进行编译，在编译阶段，计算机设备会根据配置的代码检测类文件对与代码检测类文件相对应的检测路径下的所有资源文件和代码文件进行代码的规范性检测，而对于代码检测类文件未指定的路径，则可以直接跳过检测，以缩短检测时间，提高检测效率。在此阶段，计算机设备会对代码检测类文件中记录的文件名称对应的文件进行检测，并逐一判断该文件中的每一条语句是否违反了代码检测类文件中记录的语句编写规范，通过这种方式，计算机设备可以逐一根据多个代码检测类文件对待检测项目中的多个文件进行针对性的代码检测。

在本实施例中，通过在待检测项目中配置代码检测类文件的代码检测路径，可以实现同步的对待检测项目中的代码文件和资源文件进行代码检测，而不是单一的只对代码文件进行检测，此外，在现有技术中将源代码文件中的各文件与多个代码检测规则进行逐一比对的方式也是非常耗时的，并且往往需要较多的额外操作，会浪费开发人员的宝贵时间，而本实施例提供的方案则可以有效的避免额外操作，减少比对时间。

103、输出代码文件和资源文件的代码检测结果。

具体的，在逐一的通过所有代码检测类文件对代码检测路径下的代码文件和资源文件进行检测之后，计算机设备会在编译结果中输出代码文件和资源文件的代码检测结果，其中，如果代码文件或资源文件中出现了违反代码检测类文件中记录的规则，编译结果中就输出相应的检测结果，并在检测结果中输出对应的文件名称或方法名称等信息，以便于开发人员进行及时修改，通过在编译过程中进行代码规范化检测，可以减少不必要的检测流程，缩短代码检测所需的时间，从而提高代码检测的效率。

本实施例提供的代码检测方法，首先在待检测项目中引入代码检测插件，并将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中，然后在待检测项目的编译阶段，通过配置好的代码检测类文件自动对代码检测路径下的代码文件和资源文件进行代码检测，最后输出代码文件和资源文件的代码检测结果，呈现给开发人员或测试人员。上述方法通过在待检测项目中引入代码检测插件和配置自定义的代码检测类文件，可以在编译阶段自动实现定制化的源代码检测功能，代码检测效率较高，此外，上述方法还通过在待检测项目中配置代码检测路径，实现了对指定路径下的代码文件和资源文件进行同步检测，进一步提高了源代码文件的检测效率，并且提高了源代码文件检测的针对性。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的实施过程，提供了代码检测方法，如图2所示，该方法包括以下步骤：

201、基于开发环境检测插件构建代码检测项目，并在代码检测项目中添加代码检测类文件。

具体的，开发环境检测插件指的是用于检测项目开发环境的插件，例如，开发环境检测插件可以用于检测待检测项目的JDK版本或依赖jar包的版本等。通常来说，开发环境检测插件可以直接引入到待检测项目中进行检测，因此，代码检测项目基于通用的基础架构套件并引用开发环境检测插件的基础套件进行构建可以减少代码检测项目的开发难度，提高代码检测项目的稳定性和可用性。进一步的，在构建好的检测项目中，可以添加一个或多个代码检测类文件，每一个代码检测类文件都可以对应检测一个或多个文件并记录一条或多条规范判断语句，以对各代码文件和资源文件进行规范性检测。

在一个可选的实施方式中，步骤201具体可以通过以下步骤来实现：首先基于开发环境检测插件的基础套件和基础架构套件，构建代码检测项目，然后在代码检测项目中添加基础检测类文件，其中，基础检测类文件中封装有代码检测路径排除属性和文件检索方法，最后在代码检测项目中添加代码检测类文件，其中，代码检测类文件继承基础检测类文件并实现代码检测方法。在上述实施方式中，代码检测路径排除属性可以用于配置代码检测类文件的检测路径，文件检索方法可以用于检索与代码检测类文件相对应的待检测文件，通过建立基础检测类文件，可以降低代码检测类文件的编写难度，提高代码检测项目的稳定性。

举例来说，代码检测项目可以基于Maven-Enforcer-Plugin插件构建而成。其中，Maven-Enforcer-Plugin是一款开发环境检测插件，它可以用于校验开发环境和约定遵守情况，例如，Maven-Enforcer-Plugin插件可以用于校验JDK的版本，Maven的版本，开发环境(Linux,Windows等)的版本，以及依赖jar包的版本等。但是Maven-Enforcer-Plugin插件只能检测通用的编码规范，无法满足特定的编码规范检测需求，因此，本实施例基于Maven-Enforcer-Plugin插件构建的代码检测插件，可以与Maven-Enforcer-Plugin插件形成互补，可以检测代码文件和资源文件的文件信息是否符合设定的编码规范，通过这种方式，可以实现同时对开发环境、代码文件和资源文件进行规范性检测。

进一步的，在构建好代码检测项目之后，可以在代码检测项目中添加基础检测类文件BaseRule.java，BaseRule类中封装了一些通用方法和属性，如排除文件的exclude属性以及文件检索方法，BaseRule.java缩略后的代码如下：

public class BaseRule{

protected String exclude＝“”；//排除项

protected String excludePath＝“”；//排除目录，定位到相应目录的父目录

Protected List<File>getListFiles(File directory){...}//排除的文件

protected Set<String>getExcludes(){...}//检测路径

添加好基础检测类文件之后，可以编写自定义的代码检测类文件，假设该代码检测类文件为MapperCheckRule，则MapperCheckRule需要继承BaseRule类，且MapperCheckRule需要实现Maven-Enforcer-Plugin提供的一个通用接口EnforcerRule的execute方法进行代码检测。其中，MapperCheckRule.java缩略后的代码如下：

由上述代码可知，MapperCheckRule可用于检测mybatis mapper文件中是否存在delete sql语句，此外，MapperCheckRule还可用于检测mybatis mapper文件中的其他语句规范，如select语句中是否有is_delete＝0等等，在此不一一列举。

除MapperCheckRule之外，继承BaseRule类的代码检测类文件还有LongToIntRule代码检测类文件、ValueRule检测类文件和LoggerRule检测类文件等等。其中，LongToIntRule检测类文件可用于检测以下内容：不允许Long转Interger；ValueRule检测类文件可用于检测以下内容：必须要有默认值，不允许没有默认值的情况；LoggerRule检测类文件可用于检测以下内容：log.error("代码检测x")：不打印异常，不行；log.error(e)：直接打印异常，不行；log.error(e.getMessage())：只打印异常名字，不行；log.error("代码检测x{}",e)：刚好有一个占位符为e，不行；log.error("代码检测x{}{}",args1,args2,e)：正确！。

202、将构建好的代码检测项目进行打包处理，得到代码检测插件。

具体的，对构建好的代码检测项目进行打包处理，即可得到代码检测插件，后续如果编写了其他的代码检测类文件，也可以在添加到代码检测项目中后重新对代码检测项目进行打包处理，进一步的，打包后的代码检测插件可以上传到仓库管理器中进行管理和保存。

以步骤201中的示例继续进行举例说明，假设构建好的代码检测项目为AAA-extra-enforcer-rules，则打包好的代码检测插件即为AAA-extra-enforcer-rules-x.x.x.jar，其中，x.x.x为版本号，例如0.0.3，AAA-extra-enforcer-rules-x.x.x.jar可以直接上传到Maven仓库管理器nexus中进行管理和保存。

203、在待检测项目中引入代码检测插件，并将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中。

具体的，在进行代码规范检测之前，可以首先在待检测项目中引入代码检测插件，其中，代码检测插件可以通过依赖jar包的方式引入到待检测项目中，然后可以将代码检测插件中的代码检测类文件以及代码检测类文件的检测路径配置到待检测项目的资源文件中，其中，代码检测类文件的数量可以为一个或多个，且每一个代码检测类文件都可以配置一个与其对应的检测路径，当然，代码检测类文件也可以不配置对应的检测路径，在这种情况下，该代码检测类文件的检测路径就是待检测项目的全路径。

在一个可选的实施方式中，步骤203具体可以通过以下步骤来实现：将代码检测插件中的至少一个代码检测类文件和至少一个代码检测类文件对应的代码检测路径配置到待检测项目中，其中，至少一个代码检测类文件包括代码文件检测类文件和/或资源文件检测类文件。在本实施方式中，代码检测类文件可以根据实际情况进行针对性的配置，即可以将代码检测插件中的部分代码检测类文件配置到待检测项目中，也可以将代码检测插件中的全部代码检测类文件配置到待检测项目中，并且，代码检测类文件可以是代码文件检测类文件，也可以是资源文件检测类文件，即代码检测类文件即可以针对代码文件进行检测，也可以针对资源文件进行检测。此外，对于每一个代码检测类文件均可以对应的配置一个代码检测路径，即指定该代码检测类文件具体的检测路径和/或文件。通过这种方式，可以针对性的对待检测项目中需要检测的文件进行针对性的检测，而对不需要检测的文件则可以略过不检测，以此提高代码检测效率。

在一个可选的实施方式中，将代码检测路径配置到待检测项目中的具体方法包括：将待检测项目中待排除的的代码检测路径配置到待检测项目中，和/或将待检测项目中待排除的代码文件和/或资源文件配置到待检测项目中。例如，用户xxx构建的本地项目yyy的默认代码目录是/Users/xxx/IdeaProjects/yyy/src/main/java，但是用户想检测yyy项目下的所有文件，包括代码文件和资源文件(resources)，那就可以配置待排除的的代码检测路径为“/src/main/java”，则检测目录就变为/Users/xxx/IdeaProjects/yyy/。又例如，用户在代码检测时想要排除ProductMutexRuleRelMapper.xml文件，则可以配置待排除的资源文件为ProductMutexRuleRelMapper.xml，接下来就可以对除该文件之外的所有文件进行代码检测。通过在待检测项目中配置待排除的检测路径和/或待排除的文件可以提高路径配置的效率，开发人员不必一一穷举代码检测路径，降低了文件的漏检率。

以步骤201和202中的示例继续进行举例说明，假设用户想要在待检测项目中引入代码检测插件AAA-extra-enforcer-rules，并通过代码检测类文件MapperCheckRule对待检测项目进行代码检测，则可以配置待检测项目的pom文件，并引入MapperCheckRule代码检测类文件，并配置待排除的代码检测路径和待排除的代码文件或资源文件，排除的文件和目录如果为多个，则用逗号分隔开，其中，配置代码如下：

204、在待检测项目的编译阶段，通过代码检测类文件对代码检测路径下的代码文件和资源文件进行代码检测。

具体的，在代码检测插件和代码检测类文件配置完成后，计算机设备可以对待检测项目进行编译，在编译阶段，计算机设备会根据配置的代码检测类文件对与代码检测类文件相对应的检测路径下的所有资源文件和代码文件进行代码的规范性检测，而对于代码检测类文件未指定的路径，则可以直接跳过检测，以缩短检测时间，提高检测效率。在此阶段，计算机设备会对代码检测类文件中记录的文件名称对应的文件进行检测，并逐一判断该文件中的每一条语句是否违反了代码检测类文件中记录的语句编写规范，通过这种方式，计算机设备可以逐一根据多个代码检测类文件对待检测项目中的多个文件进行针对性的代码检测。

在一个可选的实施方式中，步骤204具体可以通过以下步骤来实现：首先通过XML分析和JSON对象分析，扫描出代码检测路径下所有的代码文件和资源文件，然后通过代码检测类文件中的字节码校验规则和正则匹配规则，对代码文件和资源文件中的内容进行逐一检测。在编译阶段，本实施例提出的方法除了继承开发环境检测插件原有的字节码校验外，还可以通过扫描本地项目中的代码文件和资源文件内容，通过正则匹配、xml分析、JSON对象分析等方法对代码进行规范性检测，检测内容更加全面而准确。

在本实施例中，通过在待检测项目中配置代码检测类文件的代码检测路径，可以实现同步的对待检测项目中的代码文件和资源文件进行代码检测，而不是单一的只对代码文件进行检测，此外，在现有技术中将源代码文件中的各文件与多个代码检测规则进行逐一比对的方式也是非常耗时的，并且往往需要较多的额外操作，会浪费开发人员的宝贵时间，而本实施例提供的方案则可以有效的避免额外操作，减少比对时间。

205、输出代码文件和资源文件的代码检测结果。

具体的，在逐一的通过所有代码检测类文件对代码检测路径下的代码文件和资源文件进行检测之后，计算机设备会在编译结果中输出代码文件和资源文件的代码检测结果，其中，如果代码文件或资源文件中出现了违反代码检测类文件中记录的规则，编译结果中就输出相应的检测结果，并在检测结果中输出对应的文件名称或方法名称等信息，以便于开发人员进行及时修改，通过在编译过程中进行代码规范化检测，可以减少不必要的检测流程，缩短代码检测所需的时间，从而提高代码检测的效率。

在一个可选的实施方式中，步骤205具体可以通过以下步骤来实现：如果代码文件和资源文件中的内容与代码检测类文件中的预设规则相符，则输出编译通过的检测结果，如果代码文件和资源文件中的内容与代码检测类文件中的预设规则不相符，则输出不相符的提示信息以及编译不通过的检测结果。

以步骤201-203中的示例继续进行举例说明，在编译阶段通过MapperCheckRule代码检测类文件进行代码检测，如果存在与预设条件不相符的内容就进行报错，例如，如果对存在delete语句就进行报错，并明确告知错误信息，错误信息包括错误产生的文件名称和方法名称等。

[ERROR]ProductMuteRuleRelMapper.xml-queryByPrimaryKey查询语句没有is_delete条件

[ERROR]ProductMuteRuleRelMapper.xml不允许有删除语句

[INFO]Mapper检测完成，耗时384毫秒

将不需要检测的目录和文件排除后进行编译，重新输出检测结果如下：

[INFO]全路径/Users/IdeaProjects/sdb-core-mutex/src/main/java

[INFO]Mapper检测，排除的路径＝/src/main/java

[INFO]Mapper检测，检测的目录＝/Users/IdeaProjects/sdb-core-mutex

[INFO]Mapper检测，排除文件＝ProductMuteRuleRelMapper.xml

[INFO]Mapper检测完成，耗时233毫秒

通过上述编译结果可以看出，如果将一些不需要检测的目录和文件排除在检测范围之外，检测效率可以得到进一步提升。

进一步的，作为图1、图2所示方法的具体实现，本实施例提供了一种代码检测装置，如图3所示，该装置包括：检测配置模块31、代码检测模块32、结果输出模块33。

检测配置模块31，可用于在待检测项目中引入代码检测插件，并将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中；

代码检测模块32，可用于在待检测项目的编译阶段，通过代码检测类文件对代码检测路径下的代码文件和资源文件进行代码检测；

结果输出模块33，可用于输出代码文件和资源文件的代码检测结果。

在具体的应用场景中，所述检测配置模块31，具体可用于将代码检测插件中的至少一个代码检测类文件和至少一个代码检测类文件对应的代码检测路径配置到待检测项目中，其中，至少一个代码检测类文件包括代码文件检测类文件和/或资源文件检测类文件。

在具体的应用场景中，所述检测配置模块31，具体可用于将待检测项目中待排除的的代码检测路径配置到待检测项目中；和/或将待检测项目中待排除的代码文件和/或资源文件配置到待检测项目中。

在具体的应用场景中，所述代码检测模块32，具体可用于通过XML分析和JSON对象分析，扫描出代码检测路径下所有的代码文件和资源文件；通过代码检测类文件中的字节码校验规则和正则匹配规则，对代码文件和资源文件中的内容进行逐一检测。

在具体的应用场景中，所述结果输出模块33，具体可用于若代码文件和资源文件中的内容与代码检测类文件中的预设规则相符，则输出编译通过的检测结果；若代码文件和资源文件中的内容与代码检测类文件中的预设规则不相符，则输出不相符的提示信息以及编译不通过的检测结果。

在具体的应用场景中，如图4所示，本装置还包括项目构建模块34和项目打包模块35，所述项目构建模块34，可用于基于开发环境检测插件构建代码检测项目，并在代码检测项目中添加代码检测类文件；所述项目打包模块35，可用于将构建好的代码检测项目进行打包处理，得到代码检测插件。

在具体的应用场景中，所述项目构建模块34，具体可用于基于开发环境检测插件的基础套件和基础架构套件，构建代码检测项目；在代码检测项目中添加基础检测类文件，其中，基础检测类文件中封装有代码检测路径排除属性和文件检索方法；在代码检测项目中添加代码检测类文件，其中，代码检测类文件继承基础检测类文件并实现代码检测方法。

需要说明的是，本实施例提供的一种代码检测装置所涉及各功能单元的其它相应描述，可以参考图1、图2中的对应描述，在此不再赘述。

基于上述如图1、图2所示方法，相应的，本实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1、图2所示的代码检测方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该待识别软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

基于上述如图1、图2所示的方法，以及图3和图4所示的代码检测装置实施例，为了实现上述目的，本实施例还提供了一种代码检测的实体设备，具体可以为个人计算机、服务器、智能手机、平板电脑、智能手表、或者其它网络设备等，该实体设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1、图2所示的方法。

可选的，该实体设备还可以包括用户接口、网络接口、摄像头、射频(RadioFrequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如WI-FI接口)等。

本领域技术人员可以理解，本实施例提供的一种代码检测的实体设备结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述实体设备硬件和待识别软件资源的程序，支持信息处理程序以及其它待识别软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本申请的技术方案，首先在待检测项目中引入代码检测插件，并将代码检测插件中的代码检测类文件和代码检测路径配置到待检测项目中，然后在待检测项目的编译阶段，通过配置好的代码检测类文件自动对代码检测路径下的代码文件和资源文件进行代码检测，最后输出代码文件和资源文件的代码检测结果，呈现给开发人员或测试人员。与现有技术相比，上述方法通过在待检测项目中引入代码检测插件和配置自定义的代码检测类文件，可以在编译阶段自动实现定制化的源代码检测功能，代码检测效率较高，此外，上述方法还通过在待检测项目中配置代码检测路径，实现了对指定路径下的代码文件和资源文件进行同步检测，进一步提高了源代码文件的检测效率，并且提高了源代码文件检测的针对性。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种代码检测方法，其特征在于，所述方法包括：

在待检测项目中引入代码检测插件，并将所述代码检测插件中的代码检测类文件和代码检测路径配置到所述待检测项目中；

在所述待检测项目的编译阶段，通过所述代码检测类文件对所述代码检测路径下的代码文件和资源文件进行代码检测；

输出所述代码文件和所述资源文件的代码检测结果。

2.根据权利要求1所述的方法，其特征在于，所述将所述代码检测插件中的代码检测类文件和代码检测路径配置到所述待检测项目中，包括：

将所述代码检测插件中的至少一个代码检测类文件和所述至少一个代码检测类文件对应的代码检测路径配置到所述待检测项目中，其中，所述至少一个代码检测类文件包括代码文件检测类文件和/或资源文件检测类文件。

3.根据权利要求1或2所述的方法，其特征在于，所述将代码检测路径配置到所述待检测项目中，包括：

将所述待检测项目中待排除的的代码检测路径配置到所述待检测项目中；和/或

将所述待检测项目中待排除的代码文件和/或资源文件配置到所述待检测项目中。

4.根据权利要求1所述的方法，其特征在于，所述通过所述代码检测类文件对所述代码检测路径下的代码文件和资源文件进行代码检测，包括：

通过XML分析和JSON对象分析，扫描出所述代码检测路径下所有的代码文件和资源文件；

通过所述代码检测类文件中的字节码校验规则和正则匹配规则，对所述代码文件和资源文件中的内容进行逐一检测。

5.根据权利要求1所述的方法，其特征在于，所述输出所述代码文件和所述资源文件的代码检测结果，包括：

若所述代码文件和所述资源文件中的内容与所述代码检测类文件中的预设规则相符，则输出编译通过的检测结果；

若所述代码文件和所述资源文件中的内容与所述代码检测类文件中的预设规则不相符，则输出不相符的提示信息以及编译不通过的检测结果。

6.根据权利要求1所述的方法，其特征在于，所述在待检测项目中引入代码检测插件之前，所述方法还包括：

基于开发环境检测插件构建代码检测项目，并在所述代码检测项目中添加代码检测类文件；

将构建好的代码检测项目进行打包处理，得到代码检测插件。

7.根据权利要求6所述的方法，其特征在于，所述基于开发环境检测插件构建代码检测项目，并在所述代码检测项目中添加代码检测类文件，包括：

基于开发环境检测插件的基础套件和基础架构套件，构建代码检测项目；

在所述代码检测项目中添加基础检测类文件，其中，所述基础检测类文件中封装有代码检测路径排除属性和文件检索方法；

在所述代码检测项目中添加所述代码检测类文件，其中，所述代码检测类文件继承所述基础检测类文件并实现代码检测方法。

8.一种代码检测装置，其特征在于，所述装置包括：

检测配置模块，用于在待检测项目中引入代码检测插件，并将所述代码检测插件中的代码检测类文件和代码检测路径配置到所述待检测项目中；

代码检测模块，用于在所述待检测项目的编译阶段，通过所述代码检测类文件对所述代码检测路径下的代码文件和资源文件进行代码检测；

结果输出模块，用于输出所述代码文件和所述资源文件的代码检测结果。

9.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

10.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

Images