本发明属于软件代码的开发及管理技术领域，尤其涉及一种代码的规范性检查方法及装置。
背景技术：
目前，很多公司尤其是it(informationtechnology，信息技术)公司对员工编写的软件代码都有代码规范的要求。
虽然公司不同，代码规范的要求可能会略有不同，但在代码规范的管理方面，多数公司的代码规范基本上都是一纸文书，并通过培训文档来加强员工的编码规范性，在实际的代码开发过程中，基本上需要依赖于员工自觉性地遵守代码编码规范，由于员工素质参差不齐，导致代码规范程度也是参差不齐，此种只能靠开发人员等员工自己把握的方式，由于缺少自动监控机制，从而导致实际应用中员工的代码规范效果不是很理想，执行效率也较低。
技术实现要素：
有鉴于此，本申请的目的在于提供一种代码的规范性检查方法及装置，旨在通过一种自动的代码规范性检查方式，提升代码规范效果及执行效率。
为此，本申请公开如下技术方案：
一种代码的规范性检查方法，包括：
在满足预定的代码检查条件时，生成代码检查指令；所述代码检查指令包括目标分支代码标识、参照版本标识及当前待检查的提交代码文件的标识，所述参照版本标识所指示的参照版本文件为所述目标分支代码对应的各个代码版本中提交成功的时间最晚的版本文件，所述当前待检查的提交代码文件与所述参照版本文件同属于所述目标分支代码所对应的分支；
基于所述目标分支代码对应的版本树，获得所述目标分支代码对应的各个代码版本中的所述参照版本文件；其中，每个分支代码对应一个版本树，版本树中的每个节点对应一个版本标识、该版本标识对应的代码文件及提交人员信息；
确定所述提交代码文件相比于所述参照版本文件的差异代码行，并对所述差异代码行进行预设的代码规范性检查处理，得到检查结果；
若所述检查结果表示所述提交代码文件不符合规范，则提交失败。
上述方法，优选的，所述在满足预定的代码检查条件时，生成代码检查指令，包括：
在检测到提交人员向其处理的当前分支代码对应的版本树提交代码文件时，基于构建的版本开发基线，生成针对所提交代码文件及该版本树中提交成功的时间最晚的版本文件的代码检查指令；
其中，所述版本开发基线包括多个活动，各个活动与各个分支代码一一对应，每个活动中包括所对应的分支代码的版本变更集，分支代码的版本变更集中包括基于时间戳串联起来的分支代码的各个版本的版本信息，分支代码的每个版本的版本信息对应一个时间戳；所述版本开发基线中每个分支代码与其对应的版本树相关联。
上述方法，优选的，所述对所述差异代码行进行预设的代码规范性检查处理，包括：
对所述差异代码行进行utf-8编码格式检查、方法名和属性名的格式检查、代码的逻辑嵌套层数检查，以及对所述差异代码行所在的所述提交代码文件的文件名进行格式检查。
上述方法，优选的，还包括：
若所述检查结果表示所述提交代码文件不符合规范，在提交失败的同时提示使用者并记录日志；
若所述检查结果表示所述提交代码文件符合规范，则在所述提交代码文件所对应的分支代码的版本树中为所述提交代码文件生成一节点，将所述提交代码文件及提交人员信息关联至所生成的节点，并在所述节点中为所述提交代码文件生成一版本标识。
上述方法，优选的，还包括：
在符合预定的统计报告生成条件时，生成统计报告，并在获得展示所述统计报告的指令时，展示所述统计报告；
其中，所述统计报告包括代码文件提交失败的个数、原因、时间和/或所对应的提交人员信息。
一种代码的规范性检查装置，包括：
指令生成单元，用于在满足预定的代码检查条件时，生成代码检查指令；所述代码检查指令包括目标分支代码标识、参照版本标识及当前待检查的提交代码文件的标识，所述参照版本标识所指示的参照版本文件为所述目标分支代码对应的各个代码版本中提交成功的时间最晚的版本文件，所述当前待检查的提交代码文件与所述参照版本文件同属于所述目标分支代码所对应的分支；
文件获取单元，用于基于所述目标分支代码对应的版本树，获得所述目标分支代码对应的各个代码版本中的所述参照版本文件；其中，每个分支代码对应一个版本树，版本树中的每个节点对应一个版本标识、该版本标识对应的代码文件及提交人员信息；
规范性检查单元，用于确定所述提交代码文件相比于所述参照版本文件的差异代码行，并对所述差异代码行进行预设的代码规范性检查处理，得到检查结果；
提交处理单元，用于若所述检查结果表示所述提交代码文件不符合规范，则提交失败。
上述装置，优选的，所述指令生成单元，具体用于：
在检测到提交人员向其处理的当前分支代码对应的版本树提交代码文件时，基于构建的版本开发基线，生成针对所提交代码文件及该版本树中提交成功的时间最晚的版本文件的代码检查指令；
其中，所述版本开发基线包括多个活动，各个活动与各个分支代码一一对应，每个活动中包括所对应的分支代码的版本变更集，分支代码的版本变更集中包括基于时间戳串联起来的分支代码的各个版本的版本信息，分支代码的每个版本的版本信息对应一个时间戳；所述版本开发基线中每个分支代码与其对应的版本树相关联。
上述装置，优选的，所述规范性检查单元，具体用于：
对所述差异代码行进行utf-8编码格式检查、方法名和属性名的格式检查、代码的逻辑嵌套层数检查，以及对所述差异代码行所在的所述提交代码文件的文件名进行格式检查。
上述装置，优选的，所述提交处理单元，还用于：
若所述检查结果表示所述提交代码文件不符合规范，在提交失败的同时提示使用者并记录日志；
若所述检查结果表示所述提交代码文件符合规范，则在所述提交代码文件所对应的分支代码的版本树中为所述提交代码文件生成一节点，将所述提交代码文件及提交人员信息关联至所生成的节点，并在所述节点中为所述提交代码文件生成一版本标识。
上述装置，优选的，还包括：
统计报告生成及展示单元，用于在符合预定的统计报告生成条件时，生成统计报告，并在获得展示所述统计报告的指令时，展示所述统计报告；
其中，所述统计报告包括代码文件提交失败的个数、原因、时间和/或所对应的提交人员信息。
由以上方案可知，本申请提供的代码的规范性检查方法及装置，在满足预定的代码检查条件时，生成代码检查指令，该指令中包括目标分支代码标识及参照版本标识，并基于以下处理过程响应该指令：基于所述目标分支代码对应的版本树，获得所述参照版本文件；确定所提交代码文件相比于参照版本文件的差异代码行，对所述差异代码行进行预设的代码规范性检查处理，并在检查结果表示提交代码文件不符合规范时，提交失败。由此可见，本申请方案提供了一种能够自动对所提交的代码进行规范性检查的自动监控机制，执行效率高，且通过在检查结果为不规范时强制性地使得代码文件提交失败，可有效提升员工的代码规范效果。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1是本申请实施例一提供的一种代码的规范性检查方法流程图；
图2是本申请实施例二提供的另一种代码的规范性检查方法流程图；
图3是本申请实施例二提供的基于版本开发基线进行代码检查的示意图；
图4是本申请实施例三提供的又一种代码的规范性检查方法流程图；
图5是本申请实施例四提供的再一种代码的规范性检查方法流程图；
图6是本申请实施例五提供的一种代码的规范性检查装置的结构示意图；
图7是本申请实施例五提供的另一种代码的规范性检查装置的结构示意图。
具体实施方式
为了引用和清楚起见，下文中使用的技术名词、简写或缩写总结解释如下：
ccrc：clearcaseremoteclient，cc远程客户端软件，是一种版本管理工具，是ibmrational推出的用于在广域网环境下进行资源配置管理的产品，是一个基于eclipserichclient技术开发的用户界面，为用户提供了一种通过clearcaseweb服务器访问与使用clearcase服务的便捷方式，类似功能的还有svn等。
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例一提供一种代码的规范性检查方法，参考图1示出的代码的规范性检查方法流程图，该方法可以包括以下步骤：
步骤101、在满足预定的代码检查条件时，生成代码检查指令；所述代码检查指令包括目标分支代码标识、参照版本标识及当前待检查的提交代码文件的标识，所述参照版本标识所指示的参照版本文件为所述目标分支代码对应的各个代码版本中提交成功的时间最晚的版本文件，当前待检查的提交代码文件与所述参照版本文件同属于所述目标分支代码所对应的分支。
一个完整的软件项目代码往往由多个分支代码构成，在软件代码的开发过程中，技术人员可通过对各个分支进行不断的代码开发来最终完成整个项目的开发。
本申请基于版本树的管理理念，来对每个分支代码在开发过程中由技术人员所提交的多个不同版本的代码文件进行管理，并在此基础上，基于版本树自动完成面向技术人员的代码规范性检查。
具体地，例如，可基于ccrc(clearcaseremoteclient，远程客户端软件)版本树的管理理念，为项目的每个代码分支创建一颗版本树，在该分支中，每成功提交一次代码(本申请中每次提交的代码是指该分支至提交时刻的最新全量代码)，会将本次成功提交的代码作为一个新的版本在版本树中为其生成一个节点，并为该节点产生一个版本标识如产生版本号(版本号也相当于是节点号)等，同时，还可以在节点属性中包含提交时间、提交人员id，提交的代码内容等信息。
需要说明的是，技术人员可对不同分支进行并行的代码开发，而在同一分支中，在同一时刻仅能由一个技术人员对该分支中的当前最新版本进行代码修改/编写(而不允许由多个技术人员针对同一版本文件同时进行代码修改或编写)，以逐步完成针对该分支的代码开发。实际应用中，可通过向版本文件添加排他锁使得版本文件在同一时刻仅能被一个技术人员进行代码修改/编写，而当技术人员对该版本文件的代码修改/编写完毕后，可释放所述排他锁，以使得将该版本文件的代码修改/编写权限开放给其他技术人员，还需要说明的是，虽然在同一时刻仅能由一个技术人员对版本文件进行代码修改/编写，但其他技术人员仍具有对该版本文件进行代码查看的权限。
还需要说明的是，本申请中，版本树各节点中的版本文件为提交成功的代码文件，且进一步地，所述提交成功的代码文件为通过代码的规范性检查后所得的符合规范的代码文件。
实际应用中，可在技术人员每次向版本树提交代码文件时，实时触发一次针对该技术人员本次所提交代码文件的代码检查过程。或者还可以在达到预定的代码检查时间时，针对整个项目所有分支中未检查的提交代码进行批量的代码检查等，具体地，比如，在每天的上午11：00开始针对各员工当天上午提交的批量代码文件进行批量检查，以及在每天的下午5：00开始针对各员工当天下午提交的批量代码文件进行批量检查等。鉴于此，所述预定的代码检查条件可以是“检测到提交人员向其处理的当前分支代码对应的版本树提交代码文件”，或者还可以是“达到预定的代码检查时间”。
需要说明的是，所述预定的代码检查条件并不局限于上述两种，具体实施本申请时，可由技术人员依据实际需求来设定该代码检查条件。本申请中将“检测到提交人员向其处理的当前分支代码对应的版本树提交代码文件”作为所述代码检查条件的一较优选的实施例，从而可使得每次向版本树提交代码文件时，能够实时触发一次针对该技术人员本次所提交代码文件的代码检查过程。
本步骤101中，当满足上述预定的代码检查条件时，自动生成代码检查指令。由于技术人员在进行代码开发时，会将所需分支的版本树中最新提交成功的版本文件拉出进行代码修改/编写，根据上文所述，可知，版本树各节点中的版本文件为提交成功的代码文件，且提交成功的代码文件为通过代码的规范性检查后所得的符合规范的代码文件。因此，在技术人员通过对拉出的最新提交成功的版本文件进行代码修改/编写得到进一步的代码文件并需要提交时，仅需对两者的差异代码行进行代码规范性检查即可，其他重复的代码部分由于已符合规范，从而不必再执行代码检查过程。
鉴于此，该代码检查指令可以包括目标分支代码标识、参照版本标识及当前待检查的提交代码文件的标识，所述参照版本标识所指示的参照版本文件为所述目标分支代码对应的各个代码版本中提交成功的时间最晚的版本文件，当前待检查的提交代码文件与所述参照版本文件同属于所述目标分支代码所对应的分支。本质上来说，所述提交代码文件为技术人员通过对所述参照版本文件进行代码修改/编写所得的新的代码文件。
其中，如果所述预定的代码检查条件为检测到提交人员向其处理的当前分支代码对应的版本树提交代码，则所述代码检查指令中包括的目标分支代码标识为所述当前分支代码的标识，所述代码检查指令中包括的参照版本标识所指示的参照版本文件为所述当前分支代码的版本树中提交成功的时间最晚的版本文件。
如果所述预定的代码检查条件为达到预定的代码检查时间，则待检查的代码文件为自最近一次代码检查之后由各技术人员提交的批量代码文件；相对应地，所述代码检查指令中包括的目标分支代码标识包括自最近一次代码检查之后产生了代码更改的所有分支的标识，且所述代码检查指令中包括多个参照版本标识，各个参照版本标识所指示的参照版本文件与待检查的批量代码文件各自所对应分支的版本树中最新节点的版本文件(即最晚提交成功的版本文件)一一对应。
本申请方法可通过一插件实现，且所述代码检查指令的自动生成可通过设定一triger触发器来实现，每当检测到符合所述预定的代码检查条件时，可利用设定的triger触发器触发插件自动生成所述代码检查指令。
步骤102、基于所述目标分支代码对应的版本树，获得所述目标分支代码对应的各个代码版本中的所述参照版本文件；其中，每个分支代码对应一个版本树，版本树中的每个节点对应一个版本标识、该版本标识对应的代码文件及提交人员信息。
在获得所述代码检查指令后，可根据该指令中包括的目标分支代码标识确定该分支对应的版本树，并进一步根据该指令中包括的参照版本标识，从该分支的版本树中确定出需作为代码检查时的参照基准的参照版本文件，该参照版本文件为该分支的版本树中最新节点中的代码文件。
步骤103、确定所述提交代码文件相比于所述参照版本文件的差异代码行，并对所述差异代码行进行预设的代码规范性检查处理，得到检查结果。
在基于所述目标分支代码对应的版本树，获得需作为代码检查时的参照基准的参照版本文件后，可对比扫描所述参照版本文件及待检查的提交代码文件的内容，以此确定出所述待检查的提交代码文件相比于所述参照版本文件的差异代码行，并进而对所述差异代码行进行预设的代码规范性检查处理。
其中，可以但不限于对所述差异代码行执行如下的代码规范性检查处理：utf-8编码格式检查、方法名和属性名的格式检查、代码的逻辑嵌套层数检查，以及对所述差异代码行所在文件的文件名进行格式检查等等。
示例性地，比如具体检查utf-8编码格式是否合规、文件名是否是所要求的全部小写、代码中的方法名和属性名是否是所要求的全部小写、代码的逻辑嵌套是否最多未超过三层等。
步骤104、若所述检查结果表示所述提交代码文件不符合规范，则提交失败。
如果检查结果表示所述提交的代码文件不符合规范，则为了对提交人员所提交的代码文件进行规范性约束，会强制性地使得提交人员所提交的代码文件提交失败，以此要求提交人员仅能在其代码进一步修改合规后才能够提交成功，从而保证了技术人员所提交代码的规范效果。
由以上方案可知，本实施例提供的代码的规范性检查方法，在满足预定的代码检查条件时，生成代码检查指令，该指令中包括目标分支代码标识及参照版本标识，并基于以下处理过程响应该指令：基于所述目标分支代码对应的版本树，获得所述参照版本文件；确定所提交代码文件相比于参照版本文件的差异代码行，对所述差异代码行进行预设的代码规范性检查处理，并在检查结果表示提交代码文件不符合规范时，提交失败。由此可见，本申请方案提供了一种能够自动对所提交的代码进行规范性检查的自动监控机制，执行效率高，且通过在检查结果为不规范时强制性地使得代码文件提交失败，可有效提升员工的代码规范效果。
参考图2，为本发明实施例二提供的一种代码的规范性检查方法流程图，在本实施例二中，所述步骤101可以通过以下的处理过程实现：
步骤1011、在检测到提交人员向其处理的当前分支代码对应的版本树提交代码文件时，基于构建的版本开发基线，生成针对所提交代码文件及该版本树中提交成功的时间最晚的版本文件的代码检查指令；
其中，所述版本开发基线包括多个活动，各个活动与各个分支代码一一对应，每个活动中包括所对应的分支代码的版本变更集，分支代码的版本变更集中包括基于时间戳串联起来的分支代码的各个版本的版本信息，分支代码的每个版本的版本信息对应一个时间戳；所述版本开发基线中每个分支代码与其对应的版本树相关联。
具体地，参考图3所示，图3中的版本开发开始基线及版本开发结束基线构成版本开发基线，每次开发前，可建立版本开发开始基线，基线包含活动activity，活动包含着版本变更集，变更集包含着一个个版本变化，其中，当相应版本树中生成新的版本节点时，可将该节点的版本信息打上时间戳，并按时间戳的先后次序将其添加至该版本树所对应的基线分支中，各个版本通过其标注的不同时间戳体现其版本变化，基线通过这样的方式把项目所有分支中一个个的版本变化包含进来。
实际应用中，可以插件形式来实施本申请方案，从而使得使用者只需要在ccrc工具上安装一个插件，即可自动基于所述版本开发基线调用版本树中的相应参照版本文件对提交人员所提交的代码文件进行代码的规范性检查。
当技术人员基于活动开发只有检入时，设定triger触发器，插件自动触发读取基线中相应分支的版本变化信息，并基于时间戳从中确定代码检查时所需的参照版本文件的标识(将该分支中时间戳最新的版本信息作为参照版本标识)，进而从基线关联的相应分支版本树中调取该参照版本标识所对应的参照版本文件，并自动进行代码扫描，以参照版本文件为参照检查该技术人员检入的代码是否符合代码规范，如果为不符合设定的代码规范，进行提示，并不允许提交代码。如为检出或撤销检入，则不进行代码扫描和检查。
本实施例通过构建版本开发基线，在版本开发基线中基于时间戳将项目所有分支中一个个的版本变化包含进来，并将各个分支与其对应的版本树相关联，实现了对项目所有分支的版本变化信息进行归纳统一，以及实现了将基线中各分支版本变化信息与相应分支版本树的有机关联，为代码的规范性检查提供了便利。
参考图4，为本发明实施例三提供的一种代码的规范性检查方法流程图，在本实施例三中，所述方法还可以包括以下步骤：
步骤105、若所述检查结果表示所述提交代码文件不符合规范，在提交失败的同时提示使用者并记录日志。
具体地，若所述检查结果表示所述提交代码文件不符合规范，为了便于及时提醒使用者(如技术人员)所提交的代码文件不符合规范，则在提交失败的同时还生成并展示相应的提示信息，以提醒使用者，同时对本次提交失败事件的相应信息进行日志记录，比如，记录此次提交失败的时间、文件标识、提交人员信息，失败原因等等。
步骤106、若所述检查结果表示所述提交代码文件符合规范，则在所述提交代码文件所对应的分支代码的版本树中为所述提交代码文件生成一节点，将所述提交代码文件及提交人员信息关联至所生成的节点，并在所述节点中为所述提交代码文件生成一版本标识。
反之，如果所述检查结果表示所述提交代码文件符合规范，则将所提交的代码文件提交至其所对应分支的版本树中，具体地，可在所提交代码文件所对应分支的版本树中为所提交的代码文件生成一节点，将所述提交代码文件及提交人员信息关联至所生成的节点，并在所述节点中为所述提交代码文件生成一版本标识(也可理解为节点标识)，至此，表示本次提交的代码文件提交成功。
同时，还可以针对此次提交文件时所生成的新节点，在基线的相应分支中添加该新节点所对应的版本变化信息，以完善基线信息，使得版本开发基线中的版本变化信息与版本树的更新同步。进而便于后续基于所述版本开发基线对版本树进行管理。
本实施例通过在提交失败时生成并展示提示信息，可及时提醒技术人员进行代码修改，在提交成功时更新版本树及基线信息，可为后续基本基线及版本树进行代码版本管理提供支持。
参考图5，为本发明实施例四提供的一种代码的规范性检查方法流程图，在本实施例四中，所述方法还可以包括以下步骤：
步骤107、在符合预定的统计报告生成条件时，生成统计报告，并在获得展示所述统计报告的指令时，展示所述统计报告。
其中，所述统计报告可以包括但不限于代码文件提交失败的个数、原因、时间和/或所对应的提交人员信息。
如图3所示，在基于所构建的版本开发基线以及版本树进行代码规范性检查的基础上，可在符合预定的统计报告生成条件时，生成相应的统计报告。比如，在根据设定的统计报告生成周期，达到统计报告生成的时间节点(如每天或每周的某时刻等)时，生成包含有该统计周期内代码文件提交失败的个数、原因、时间和/或所对应的提交人员信息的统计报告等。
在生成所述统计报告后，可自动展示所生成的统计报告，或者还可以在使用者需要查阅所述统计报告时，由使用者调出并进行使用，本实施例对此不作限定。
本实施例通过生成包括但不限于代码文件提交失败的个数、原因、时间和/或所对应的提交人员信息的统计报告，为管理者或决策者了解各员工的代码提交情况提供了便利。
需要说明的是，本申请中，“分支代码”、“分支”及“代码分支”为同一概念，均至软件项目中所包括的各个可并行开发的代码分支中的某一分支。
本申请实施例五提供一种代码的规范性检查装置，参考图6示出的代码的规范性检查装置的结构示意图，该装置包括：
指令生成单元601，用于在满足预定的代码检查条件时，生成代码检查指令；所述代码检查指令包括目标分支代码标识、参照版本标识及当前待检查的提交代码文件的标识，所述参照版本标识所指示的参照版本文件为所述目标分支代码对应的各个代码版本中提交成功的时间最晚的版本文件，当前待检查的提交代码文件与所述参照版本文件同属于所述目标分支代码所对应的分支；
文件获取单元602，用于基于所述目标分支代码对应的版本树，获得所述目标分支代码对应的各个代码版本中的所述参照版本文件；其中，每个分支代码对应一个版本树，版本树中的每个节点对应一个版本标识、该版本标识对应的代码文件及提交人员信息；
规范性检查单元603，用于确定所述提交代码文件相比于所述参照版本文件的差异代码行，并对所述差异代码行进行预设的代码规范性检查处理，得到检查结果；
提交处理单元604，用于若所述检查结果表示所述提交代码文件不符合规范，则提交失败。
在本申请实施例的一实施方式中，所述指令生成单元601，具体用于：
在检测到提交人员向其处理的当前分支代码对应的版本树提交代码文件时，基于构建的版本开发基线，生成针对所提交代码文件及该版本树中提交成功的时间最晚的版本文件的代码检查指令；
其中，所述版本开发基线包括多个活动，各个活动与各个分支代码一一对应，每个活动中包括所对应的分支代码的版本变更集，分支代码的版本变更集中包括基于时间戳串联起来的分支代码的各个版本的版本信息，分支代码的每个版本的版本信息对应一个时间戳；所述版本开发基线中每个分支代码与其对应的版本树相关联。
在本申请实施例的一实施方式中，所述规范性检查单元603，具体用于：
对所述差异代码行中的代码进行utf-8编码格式检查、方法名和属性名的格式检查、代码的逻辑嵌套层数检查，以及对所述差异代码行所在的所述提交代码文件的文件名进行格式检查。
在本申请实施例的一实施方式中，所述提交处理单元604，还用于：
若所述检查结果表示所述提交代码文件不符合规范，在提交失败的同时提示使用者并记录日志；
若所述检查结果表示所述提交代码文件符合规范，则在所述提交代码文件所对应的分支代码的版本树中为所述提交代码文件生成一节点，将所述提交代码文件及提交人员信息关联至所生成的节点，并在所述节点中为所述提交代码文件生成一版本标识。
在本申请实施例的一实施方式中，参考图7，所述装置还可以包括：
统计报告生成及展示单元605，用于在符合预定的统计报告生成条件时，生成统计报告，并在获得展示所述统计报告的指令时，展示所述统计报告；
其中，所述统计报告包括代码文件提交失败的个数、原因、时间和/或所对应的提交人员信息。
对于本申请实施例公开的代码的规范性检查装置而言，由于其与以上实施例公开的代码的规范性检查方法相对应，且具有相同的技术效果，所以描述的比较简单，相关相似之处请参见以上实施例中代码的规范性检查方法部分的说明即可，此处不再详述。
综上所述，本申请的代码规范性检查方法及装置，具有以下的有益效果：
1)提供了一种能够自动对所提交的代码进行规范性检查的自动监控机制，执行效率高，且通过在检查结果为不规范时强制性地使得代码文件提交失败，可有效提升员工的代码规范效果；
2)可以持续集成代码的检查规则，把公司的代码规范变成实际的插件工具，实时监控并管理员工提交的代码质量和规范性；
3)减少了人工对代码的规范检查，减少了人力资源消耗成本，能够灵活控制代码规范的规则和要求，大幅度提高了代码的规范和质量。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
为了描述的方便，描述以上系统或装置时以功能分为各种模块或单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
最后，还需要说明的是，在本文中，诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。