代码检测工具箱——checkstyle、findbugs、pmd-cpd

Jenkins基础教程(132)Jenkins代码质量之PMD/CPD:Jenkins代码质检:PMD/CPD“捉妖记” 还在为代码中的隐藏bug和重复代码烦恼吗?本文将手把手带你使用Jenkins集成PMD和CPD,搭建自动化代码质量检查流水线。通过实际示例,你将学会如何配置规则、分析报告并优化代码,让代码质量隐患无处遁形,提升开发效率。一起来给代码做个全面体检吧! 阅读详情
 

 写在前面

好吧,我承认,我懒了,写了一天文档,到这里直接粘贴了,希望大家能看懂,如果需要一份格式完整的文档,请去我的百度文库下载,地址是:

http://wenku.baidu.com/view/d2849ff04693daef5ef73d34.html

 

下面,开始

一.目的:

最近要跟踪一个项目的代码质量,保障项目质量。个人总是认为,质量保障这个东西要用数据说话的。代码走查是一个方面,但要能使用工具完成部分标准化的代码走查,发现部分错误,也不失为一种不错的补充手段。结合之前自己用过、听过的几种开源工具,整合到一起,实现一个适合目前项目的简单工具。

 

二.取舍:

首先是工具的选择,经过多个工具的使用结合目前项目组成员的水平和状态,决定从几个方面进行检查:

常规bug

编码规范

重复代码

 

不想检查太多,以前没有开展过这方面的工作,领导是否支持,项目成员反响是否良好都很难说,如果大家都喜欢再完善更多的检查也不晚。

    

其实还差一个依赖的检测,但现在项目使用的是ssh的架构,现有依赖检查的工具中,对spring的支持都不是很好,遂放弃。

    

对于工具的选择,紧着自己熟悉的就选择了checkstyle、findbugs和pmd的cpd工具。

 

三.期望结果:

使用ant脚本,一步完成所有工作,针对项目直接产生检查报告。

 

四.步骤:

1.准备工具

ant、checkstyle、findbugs、pmd下载。还要下载cvs和eclipse,因为脚本中需要使用cvs更新代码,eclipse会让ant脚本的编辑和环境配置更加简单。

 

2.脚本规划

规划脚本,整个脚本分为几个部分,如下:

 

<?xml version="1.0" encoding="utf-8"?>

<project name="myProject" default="start" >

    <!-- 变量定义 -->

    <!-- 环境初始化 -->

    <!-- checkout -->

    <!-- javac -->

    <!-- jar -->

    <!-- checkstyle -->

    <!-- findbugs -->

    <!-- pmd cpd -->

    <!-- run -->

    <target name="start">

    </target>

</project>

 

整个脚本规划描述了脚本执行的过程,每个注释都将添加具体的内容。系统执行start任务,这个任务通过依赖调用其他任务,任务间通过依赖定义过程。

 

l         首先“变量定义”中定义变量,便于将来多个项目复用。

l         “环境初始化”中初始化环境,所有环境清理和环境建立都在这里完成。

l         “checkout”完成cvs的更新工作。

l         由于findbugs需要检查二进制代码,“javac”完成代码编译工作。

l         同样为findbugs需要,“jar”将代码打包。

l         “checkstyle”完成代码拼写检查。

l         “findbugs”完成bug检查

l         “pmd cpd”使用pmd的cpd功能检查重复代码。

 

3.checkout

变量定义和环境初始化部分,在需要时随时添加,首先是checkout过程,将代码检出cvs库。

3.1脚本编写

checkout部分脚本如下:

    <target name="checkoutlib" depends="mkDir">

       <cvs cvsroot="${cvsroot}" package="WorkingArea/Code/lib" />

    </target>

    <target name="checkoutsrc" depends="checkoutlib">

       <cvs cvsroot="${cvsroot}" package="WorkingArea/Code/project" />

    </target>

 

checkoutlib检出公共库,checkoutsrc检出代码,同时在变量定义部分定义cvsroot变量,如下:

 

    <property name="cvsroot" value=":pserver:wangjianxuan:password@scm1.domain.com:/repository/project" />

 

其中文字部分与我们常用的cvs写法相同,可以参考eclipse中的cvs视图的部分。

 

注意:上面脚本中依赖的mkDir任务是初始化部分的,为了建立相关的目录,后面有详细描述。

 

3.2执行

eclipse中执行ant就是有这点好,缺少什么不用去修改环境变量,eclipse内部就解决了。执行前有几个地方需要确认:

脚本上点右键-》Run As-》Ant Build…

注意,一定是带有省略号的菜单,这个菜单才能配置环境,打开界面如下图:

这里Targets可以选择要执行的任务,执行时会连依赖的任务一起执行。ClassPath定义依赖的类库,JRE用来定义JRE的版本,Environment标签很重要,可以定义一些环境变量中未定义的变量,这里我因为一直没有找到cvs路径,但命令行中能够找到cvs,所以把Path环境变量复制定义到这里了,如下图:

脚本执行后,会将代码检出到工程目录下的“WorkingArea/Code/project”位置。

 

注意:环境变量和类路径等内容的设置在更改ant脚本名称后会丢失,需要重新设置。

 

3.3问题处理

ant调用cvs网上文章较少,问题的处理就更少了,也许是太简单了吧,但我还是碰到了一些问题。

首先,如果path路径中没有增加cvs路径,或者你没有安装cvs(windows系统需要安装cvsnt),找不到cvs路径,将报错。所以保证命令行中任意路径下调用“cvs”命令可以成功,如果还报错,可以将“path”环境变量增加到eclipse中。

 

另外,按照ant的cvs任务说明,cvs密码应该使用cvspass任务生成cvspass文件,在cvs任务中使用cvspass标签调用这个文件。但是,我在eclipse中这么做不会产生文件,同时cvs checkout会报告访问被拒绝(很明白,没密码)。处理办法就是将密码加在cvsroot属性中,在用户名后,“@”符号前增加“:密码”即可。

 

 

4. javac

javac任务将刚刚检出的代码进行编译,编译后的代码放到bin目录下。

4.1脚本

javac部分的脚本如下:

    <target name="javac" depends="checkoutsrc">

       <javac srcdir="${srcdir}" destdir="${builddir}" source="1.6">

           <compilerarg value="-Xlint:unchecked" />

       </javac>

    </target>

其中,depends指定刚刚检出脚本,使脚本执行时先执行检出才会执行编译。source指定编译时使用的jdk版本,这里指定了1.6版本。由于代码编译需要,指定了一个编译参数“-Xlint:unchecked”,根据实际情况,可指定任何参数,可多次使用,与命令行编译对应。

在变量定义部分定义了两个变量:“srcdir”指定源代码路径;“builddir”指定编译后代码路径。脚本如下:

    <property name="projdir" value="D:/work/quality_workspace/AntScript" />

    <property name="srcdir" value="${projdir}/WorkingArea/Code/cginfo/src/main" />

    <property name="builddir" value="${projdir}/WorkingArea/Code/cginfo/bin" />

srcdir和builddir变量共同以当前项目目录为基础,所以,又定义了一个变量“projdir”声明项目目录。

 

4.2执行

简单执行javac脚本可能会出现问题,需要使classpath包含类路径。同样,脚本上右键-》Run As-》Ant Build…打开窗口中选择Classpath页签,如下:

这里要注意,

1.       只有选择“User Entries”节点时,添加jar包的按钮才有效。

2.       不知道是不是我使用的问题,Add Folders添加目录后,并不能把目录下所有jar包都添加到类路径来,只能将所有jar包摊在这里。

 

编译后就是打包了,见下节。

5.jar

与javac同样,由于findbugs的需要,将javac编译后的代码打包

5.1脚本

    <target name="jar" depends="javac">

       <jar destfile="${packagedir}/app.jar" basedir="${builddir}" />

    </target>

脚本destfile指定了编译后的jar包路径和文件名,basedir指定原代码的路径。

这里在变量定义部分定义了变量packagedir用于指定jar包的路径,脚本如下:

<property name="package" value="WorkingArea/Code/commonMakeManage"/>

执行后会在destfile位置找到打好的jar包。

6.checkstyle

终于进入正题了,准备工作完成,可以开始检查了,首先是checkstyle检查并且生成报告。

6.1脚本

检查脚本如下:

    <target name="checkstyle" depends="jar">

       <taskdef resource="checkstyletask.properties" />

       <checkstyle config="lib/check_rules.xml">

           <formatter type="xml" tofile="${checkstyledir}/checkstyle_report.xml" />

           <fileset dir="${srcdir}" includes="**/*.java" />

       </checkstyle>

       <style in="${checkstyledir}/checkstyle_report.xml" out="${checkstyledir}/checkstyle_report.html" style="lib/checkstyle-frames.xsl" />

    </target>

 

脚本有点长,逐个解说:

首先,taskdef定义了checkstyle的ant task,以及声明了属性文件,这就需要ant的类路径中有checkstyle的jar包,这里我用的是checkstyle-5.4-all.jar。

 

下面,checkstyle定义了检查的各方面,“config”定义了检查规则,规则可以自定义编写,随后说明。

 

formatter子元素定义了输出格式以及输出文件的位置,这里定义了xml格式,同时定义了“checkstyledir”变量,代表checkstyle报告目录。后面说明具体变量定义。

 

fileset子元素定义了源代码位置,dir指定了源代码目录,includes指定文件类型,也可以使用excludes排除一些文件,详见checkstyle文档。

 

执行后生成xml报告文件,使用style标签结合checkstyle中自带的xsl文件将xml生成html,便于查看,checkstyle自带了很多xsl文件,多尝试一下,看看哪个适合。

 

注意:这里使用的是框架样式,生成的html,生成后有时会在“${checkstyledir}”的同级目录生成files目录,目录中包含部分检查结果。

 

6.2变量定义

脚本如下:

    <property name="checkstyledir" value="${projdir}/checkstyle" />

 

6.3环境初始化脚本

由于每次检查代码前要将之前的检查结果删除,保证结果是最新的。同时要保证文件目录存在,否则写报告时报错。所以有如下脚本:

    <target name="delDir">

       <delete dir="${builddir}" />

       <delete dir="${checkstyledir}" />

       <delete dir="${findbugsdir}" />

       <delete dir="${cpddir}" />

    </target>

    <target name="mkDir" depends="delDir">

       <mkdir dir="${builddir}" />

       <mkdir dir="${checkstyledir}" />

       <mkdir dir="${findbugsdir}" />

       <mkdir dir="${cpddir}" />

    </target>

这里将所有需要删除和建立的脚本都写出来了,包括编译的目录builddir;代码检查结果目录checkstyledir;bug检查结果目录findbugsdir以及代码重复检查目录cpddir。

 

6.3执行

脚本执行后会在checkstyledir目录下建立checkstyle_report.xml和checkstyle_report.html文件

6.4自定义规则

checkstyle规则可以自定义,详细规则可以参考checkstyle文档,这里我只需要检查很少的规则,从checkstyle规则中删除不必要的规则,保留一部分需要的即可。规则如下:

<?xml version="1.0"?>

<!DOCTYPE module PUBLIC

          "-//Puppy Crawl//DTD Check Configuration 1.3//EN"

          "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">

 

<!--

 

  Checkstyle configuration that checks the sun coding conventions from:

 

    - the Java Language Specification at

      http://java.sun.com/docs/books/jls/second_edition/html/index.html

 

    - the Sun Code Conventions at http://java.sun.com/docs/codeconv/

 

    - the Javadoc guidelines at

      http://java.sun.com/j2se/javadoc/writingdoccomments/index.html

 

    - the JDK Api documentation http://java.sun.com/j2se/docs/api/index.html

 

    - some best practices

 

  Checkstyle is very configurable. Be sure to read the documentation at

  http://checkstyle.sf.net (or in your downloaded distribution).

 

  Most Checks are configurable, be sure to consult the documentation.

 

  To completely disable a check, just comment it out or delete it from the file.

 

  Finally, it is worth reading the documentation.

 

-->

 

<module name="Checker">

    <!--

        If you set the basedir property below, then all reported file

        names will be relative to the specified directory. See

        http://checkstyle.sourceforge.net/5.x/config.html#Checker

 

        <property name="basedir" value="${basedir}"/>

    -->

 

    <!-- Checks that property files contain the same keys.         -->

    <!-- See http://checkstyle.sf.net/config_misc.html#Translation -->

    <module name="Translation"/>

   

 

    <module name="TreeWalker">

 

        <!-- Checks for Javadoc comments.                     -->

        <!-- See http://checkstyle.sf.net/config_javadoc.html -->

        <module name="JavadocMethod"/>

        <module name="JavadocType"/>

        <module name="JavadocVariable"/>

 

 

 

        <!-- Checks for Naming Conventions.                  -->

        <!-- See http://checkstyle.sf.net/config_naming.html -->

        <module name="ConstantName"/>

        <module name="LocalFinalVariableName"/>

        <module name="LocalVariableName"/>

        <module name="MemberName"/>

        <module name="MethodName"/>

        <module name="PackageName"/>

        <module name="ParameterName"/>

        <module name="StaticVariableName"/>

        <module name="TypeName"/>

 

 

        <!-- Checks for Headers                                -->

        <!-- See http://checkstyle.sf.net/config_header.html   -->

        <!-- <module name="Header">                            -->

            <!-- The follow property value demonstrates the ability     -->

            <!-- to have access to ANT properties. In this case it uses -->

            <!-- the ${basedir} property to allow Checkstyle to be run  -->

            <!-- from any directory within a project. See property      -->

            <!-- expansion,                                             -->

            <!-- http://checkstyle.sf.net/config.html#properties        -->

            <!-- <property                                              -->

            <!--     name="headerFile"                                  -->

            <!--     value="${basedir}/java.header"/>                   -->

        <!-- </module> -->

 

        <!-- Following interprets the header file as regular expressions. -->

        <!-- <module name="RegexpHeader"/>                                -->

 

 

        <!-- Checks for imports                              -->

        <!-- See http://checkstyle.sf.net/config_import.html -->

        <module name="AvoidStarImport"/>

        <module name="IllegalImport"/> <!-- defaults to sun.* packages -->

        <module name="RedundantImport"/>

        <module name="UnusedImports"/>

 

 

 

        <!-- Checks for common coding problems               -->

        <!-- See http://checkstyle.sf.net/config_coding.html -->

        <module name="SimplifyBooleanExpression"/>

        <module name="SimplifyBooleanReturn"/>

 

 

    </module>

 

</module>

 

 

7.findbugs

使用findbugs检查常见bug

7.1脚本

脚本如下:

<target name="findbugs" depends="checkstyle">

       <taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask" />

       <findbugs home="${findbugs.home}" output="html" outputFile="${findbugsdir}/findbugs_report.html">

           <sourcePath path="${srcdir}" />

           <class location="${projdir}/WorkingArea/Code/cginfo/app.jar" />

       </findbugs>

    </target>

同样,taskdef定义了findbugs的ant task,需要classpath中增加findbugs的jar包。一个findbugs-ant.jar基本就够了。

findbugs标签,home指定findbug安装目录。

output定义输出样式,一般输出html形式,xml形式也可,但xml形式再用样式转html总是显示不了bug,没仔细查问题发生在哪里。

outputFile指定报告的路径和文件名。

sourcePath指定源代码目录

class指定jar包的目录和文件名。

7.2执行

执行后查看报告即可。但findbugs生成的报告与findbugs eclipse插件检查的结果有些出入,没有查看具体问题发生在哪里。

 

8.cpd

cpd是pmd的一个组件,用来检查重复代码。

8.1脚本

脚本如下:

    <target name="pmdcpd" depends="findbugs">

       <taskdef name="cpd" classname="net.sourceforge.pmd.cpd.CPDTask" />

       <cpd minimumTokenCount="100" encoding="UTF-8" format="xml" outputFile="${cpddir}/cpd.xml">

           <fileset dir="${srcdir}">

              <include name="**/*.java" />

           </fileset>

       </cpd>

    </target>

taskdef定义了cpd的ant任务,这与pmd任务是分开的。classpath中需要增加pmd解压目录的lib目录下的所有jar包。

cpd标签的minimumTokenCount指定了最小重复行数,当重复函数大于这个量时产生报告。

encoding指定文件编码。

format指定输出文件格式。

outputFile指定输出文件路径和文件名称。

include指定检查的文件。可以使用exclude指定剔除的文件。

 

8.2执行

执行后查看输出文件,虽然是xml格式,但使用IE打开很容易查看,由于只能使用xslt结合xml形式生成html,且初步试验,生成html文件有点问题,就放弃了。

 

9.完整脚本

完整脚本如下:

<?xml version="1.0" encoding="utf-8"?>

<project name="myProject" default="start">

    <!-- 变量定义 -->

    <property name="cvsroot" value=":pserver:wangjianxuan:password@scm1.domain.com:/repository/opermanage" />

    <property name="projdir" value="D:/work/quality_workspace/AntScript" />

    <property name="srcdir" value="${projdir}/WorkingArea/Code/cginfo/src/main" />

    <property name="builddir" value="${projdir}/WorkingArea/Code/cginfo/bin" />

    <property name="checkstyledir" value="${projdir}/checkstyle" />

    <property name="findbugsdir" value="${projdir}/findbugs" />

    <property name="findbugs.home" value="D:/work/quality_workspace/findbugs-1.3.9" />

    <property name="cpddir" value="${projdir}/cpd" />

 

    <!-- init -->

    <target name="delDir">

       <delete dir="${builddir}" />

       <delete dir="${checkstyledir}" />

       <delete dir="${findbugsdir}" />

       <delete dir="${cpddir}" />

    </target>

    <target name="mkDir" depends="delDir">

       <mkdir dir="${builddir}" />

       <mkdir dir="${checkstyledir}" />

       <mkdir dir="${findbugsdir}" />

       <mkdir dir="${cpddir}" />

    </target>

 

    <!-- checkout -->

    <target name="checkoutlib" depends="mkDir">

       <cvs cvsroot="${cvsroot}" package="WorkingArea/Code/lib" />

    </target>

    <target name="checkoutsrc" depends="checkoutlib">

       <cvs cvsroot="${cvsroot}" package="WorkingArea/Code/cginfo" />

    </target>

 

    <!-- javac -->

    <target name="javac" depends="checkoutsrc">

       <javac srcdir="${srcdir}" destdir="${builddir}" source="1.6">

           <compilerarg value="-Xlint:unchecked" />

       </javac>

    </target>

    <!-- jar -->

    <target name="jar" depends="javac">

       <jar destfile="${projdir}/WorkingArea/Code/cginfo/app.jar" basedir="${builddir}" />

    </target>

    <!-- checkstyle -->

    <target name="checkstyle" depends="jar">

       <taskdef resource="checkstyletask.properties" />

       <checkstyle config="lib/check_rules.xml" failureProperty="checkstyle.failure" failOnViolation="false">

           <formatter type="xml" tofile="checkstyle/checkstyle_report.xml" />

           <fileset dir="${srcdir}" includes="**/*.java" />

       </checkstyle>

       <style in="checkstyle/checkstyle_report.xml" out="checkstyle/checkstyle_report.html" style="lib/checkstyle-frames.xsl" />

    </target>

 

    <!-- findbugs -->

    <target name="findbugs" depends="checkstyle">

       <taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask" />

       <findbugs home="${findbugs.home}" output="html" outputFile="${findbugsdir}/findbugs_report.html">

           <sourcePath path="${srcdir}" />

           <class location="${projdir}/WorkingArea/Code/cginfo/app.jar" />

       </findbugs>

    </target>

 

    <!-- pmd cpd -->

    <target name="pmdcpd" depends="findbugs">

       <taskdef name="cpd" classname="net.sourceforge.pmd.cpd.CPDTask" />

       <cpd minimumTokenCount="100" encoding="UTF-8" format="xml" outputFile="${cpddir}/cpd.xml">

           <fileset dir="${srcdir}">

              <include name="**/*.java" />

           </fileset>

       </cpd>

    </target>

    <!-- run -->

    <target name="start" depends="pmdcpd">

    </target>

</project>

 

 

 

 

 

 

 

 

 

 

 

几款Java源码扫描工具(FindBugs、PMD、SonarQube、Fortify、WebInspect) 几款Java源码扫描工具FindBugs、PMD、SonarQube、Fortify、WebInspect 阅读详情

相关推荐

Jenkins基础教程(138)Jenkins代码质量之使用Checkstyle、PMD 和FindBugs 报告:Checkstyle、PMD、FindBugs三剑客合体

代码质量,就像程序员的个人卫生,虽然不影响功能但严重影响形象。想象一下,你写出的代码每次提交都会自动被一群“代码警察”检查:变量命名不规范?扣分!有可能出现空指针?扣分!重复代码太多?直接挂掉!这就是Jenkins与Checkstyle、PMD、FindBugs组合带来的威力。它们就像是代码的“全职体检医生”,能够在每次提交后自动检查代码问题。

jxf_jxfcsdn的博客 355

代码检查工具PMD/CPD

一.PMD/CPD介绍 PMD是一个源代码分析器。它寻找常见的编程缺陷,例如未使用的变量、空的catch块、多余的对象创建等等。支持Java、JavaScript、Salesforce.com Apex、PLSQL、Apache Velocity、XML、XSL。 另外,它包含CPD(copy-paste-detector),一个复制粘贴检测器。CPD寻找重复的代码,支持Java、C、C++、C#、Groovy、PHP、Ruby、Fortran、JavaScript、PLSQL、Apache Velocit

u010107252的博客 5011

Java代码规范检查插件实战:Checkstyle、PMD、SpotBugs与CI/CD集成指南

在软件工程实践中,代码规范检查是保障代码质量、提升团队协作效率的基础环节。其核心原理是通过静态代码分析技术,对源代码进行自动化扫描,识别出违反预设编码规范、潜在缺陷或不良实践的模式。这项技术的价值在于将主观的代码风格约定转化为客观、可执行的规则,从而在开发早期发现并预防问题,如空指针异常、资源泄漏和代码重复等,有效降低维护成本与线上故障风险。其应用场景广泛覆盖了从个人开发到大型团队协作的全流程,尤其在持续集成/持续交付(CI/CD)流水线中,可作为关键的质量门禁。本文聚焦于Java生态,深入探讨如何将主流的

weixin_30263277的博客 367

10个静态代码检查工具

静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行,充分发挥人的逻辑思维优势,也可以借助软件工具自动进行。

pantouyuchiyu的博客 1万+

21、流行的 Java 和 Groovy 代码质量分析工具及报告插件使用指南

本文介绍了几种流行的 Java 和 Groovy 代码质量分析工具,包括 Checkstyle、PMD/CPD、FindBugs 和 CodeNarc,并详细说明了它们在不同构建工具(如 Maven、Gradle 和 Ant)中的配置方法。此外,还介绍了如何使用 Jenkins 的 Violations 插件来生成代码质量报告,帮助开发团队提高代码质量、减少潜在错误。通过工具对比和实际应用建议,为不同项目和团队提供了实用的参考方案。

wdx01234567的博客 92

PMD与CPD使用说明

PMD与CPD使用说明,检查Java代码的重复度

idea,配置checkstyle 【提高代码质量,检查代码规范的工具 】Checkstyle,FindBugs,PMD,Jtest

提高代码质量,检查代码规范的工具 有几款代码质量: PMD 是一个源代码分析器。发现常见的编程缺陷像未使用的变量,空的catch块,不必要的对象的创建,等等。支持java,JavaScript,Salesforce.com的先端,PLSQL,Apache速度,XML。此外,它包括CPD,复制粘贴探测器。 官网地址:http://pmd.github.io/ FindBugs

随笔记录-分享&记忆 3万+

从MCU到MPU:瑞萨RZN2L上手初体验,给Cortex-M工程师的Cortex-R52入门避坑指南

本文详细介绍了从MCU到MPU的过渡经验,特别是瑞萨RZN2L开发板的实战避坑指南。针对Cortex-M工程师转向Cortex-R52内核的挑战,文章深入解析了启动流程、内存管理、中断响应等九大本质差异,并提供了硬件设计陷阱和软件迁移的实用技巧,帮助开发者快速适应MPU开发环境。

weixin_29158413的博客 252

Java项目代码规范与静态检查实战:Checkstyle、PMD、SpotBugs集成指南

代码规范与静态代码分析是软件工程中保障代码质量的核心实践。从概念上讲,代码规范定义了团队统一的编程准则,包括命名、格式和结构约定;而静态分析则是在不运行程序的情况下,通过分析源码或字节码来发现潜在缺陷、安全漏洞和规范违反。其技术原理在于自动化检查工具对抽象语法树或字节码的模式匹配与分析。这一实践的核心价值在于提升代码一致性、提前发现运行时错误、强制执行最佳实践,并显著降低代码审查成本。在应用场景上,它广泛应用于持续集成流水线、团队协作开发以及长期项目维护中。本文聚焦于Java技术栈,通过集成Checksty

weixin_30797199的博客 418

《基于Yolo算法的火灾检测系统设计与实现》开题报告

在消防安全领域,火灾对生命财产安全构成严重威胁。传统的火灾检测手段存在诸多不足,如误报率高、检测范围有限、响应速度慢等。基于 Yolo 算法的火灾检测系统能够利用深度学习技术,实现对火灾的高效、精准检测,具有重要的现实意义。         从社会安全角度看,该系统可以广泛应用于各类公共场所、工业厂房和居民住宅,实时监测火灾隐患,及时发出警报,为人员疏散和消防救援争取宝贵时间,有效降低火灾造成的人员伤亡和财产损失,保障社会公共安全。

m0_69704149的博客 1380

Vivado图形化界面烧写MCS文件到SPI FLASH全流程(附常见报错解决方案)

本文详细介绍了使用Vivado图形化界面将MCS文件烧录至SPI FLASH的完整操作流程。内容涵盖从环境准备、MCS文件生成到硬件连接与烧写的每一步,并针对SPI总线宽度报错、FLASH型号识别失败等常见问题提供了深度解决方案,帮助用户高效完成FPGA配置,摆脱对TCL命令行的依赖。

s8t9u0v1w的博客 527

jenkins+Warnings Next Generation Plugin构建代码自动化检测

背景 现在大多数企业,都会选择使用自动化的方式去构建代码.UT,打包,部署等等,一条龙服务,为了产出优质的代码,代码检测当然是必不可少的.这个代码检测当然不是由我们手动检查,当然是由工具帮我们自动完成,下面就是我们要介绍的重点咯,jenkins+Warnings Next Generation Plugin实现自动化代码检测. Warnings Next Generation Plugin W...

iKun 4835

【华为OD机试真题 新系统】1029、字符串处理 | 机试真题+思路参考+代码解析(C++、Java、Py、C语言、JS)

【华为OD机试真题 新系统】1029、字符串处理 | 机试真题+思路参考+代码解析(C++、Java、Py、C语言、JS) 华为od机试,华为od机试真题,华为od机试E卷,华为odE卷,华为od机试真题E卷,华为OD,华为OD机试,华为OD机试真题,华为od机考,华为od机试D卷,华为od机试真题D卷,华为od手撕代码,华为od,华为od机试C卷,华为od e卷,华为2026e卷,od机试,2026E卷,华为OD机试E卷,什么是华为od,华为od介绍,全面了解华为od,2026华为od,如何备战华为od,

KJ.JK 212

代码检测对象箱——checkstyle、findbugs、pmd-cpd

http://wenku.baidu.com/view/d2849ff04693daef5ef73d34.html 下面,开端 一.目标: 比来要跟踪一个项目标代码质量,保障项目质量。小我老是认为,质量保障这个器材要用数据措辞的。代码走查是一个方面,但要能应用对象完成项目组标准化的代码走查,发明项目组错误,也不失为一种不错的补充手段。连络之前本身用过、听过的几种开源对象,整合到一路,实现...

轻轻草原 197

14、固态变压器(SST)供电的直流微电网控制策略解析

本文详细解析了基于固态变压器(SST)供电的直流微电网的分层功率管理与控制策略。重点介绍了二次控制和三次控制算法的原理及实现方式,探讨了将SST作为固态同步电机(SSSM)的控制概念及其频率调节方法。通过小型直流微电网的实验案例验证了控制策略的有效性,并对不同三次控制方法的优缺点进行了比较。最后,文章提出了未来控制策略的优化方向,包括通信技术提升、多目标优化和智能算法的应用,为直流微电网的可靠、高效运行提供了理论支持和实践指导。

star的博客 549

【误码率仿真】基于matlab 小波变换OFDM误码率仿真

其中,与传统的 OFDM 相比,小波变换 OFDM 在进行调制和解调时,使用的是小波变换函数。需要注意的是,由于小波变换函数将频域信号转换为时域信号,因此与传统 OFDM 不同,小波变换 OFDM 中的信号需要在时域上添加循环前缀。与传统的 OFDM 不同,小波变换 OFDM 使用小波函数作为基函数,而非正弦函数作为基函数,因此可以在保持子载波正交性的同时,让子载波之间的带宽变得更加均匀。在频域进行信号加权,然后进行小波逆变换,得到时域信号。在接收端进行信号接收,去掉循环前缀并进行小波变换得到频域信号。

Fanjufei的博客 658

有效检查Java代码的工具:PMD、Checkstyle、findbugs、Jalopy

PMD的文档,它会对代码中的如下部分进行检查:    未使用的本地变量    空的catch块    未使用参数    空if语句    重复的import语句    未使用的私有方法    可能是Singletons的类    短/长变量及方法名字 Checkstyle检查如下部分:    Javadoc注释    命名约定    标题    Import语句

JX 2782

AI测试入门:基于 RAG 的 LLM 应用程序的测试方法「详细介绍」

一个典型的 RAG 架构包括一个检索器(对知识库进行矢量搜索检索上下文的组件)和一个生成器(从检索器中获取检索上下文以构建提示并生成自定义 LLM 响应作为最终输出的组件)。在大多数情况下, 知识库”由存储在向量数据库(如 ChromaDB)中的向量嵌入组成。

blues_C的博客 1867

java代码检查 jenkins_Java代码质量检查checkstyle, pmd, cpd, p3c,findbugs, jacoco, sonarquebe以及和Jenkins集成...

概述又搞一边质量扫描插件,之前做过一遍,然后后面各种忽略,然后就放弃了,所以,应该寻找一种方法,循序渐进的实施。本次将实施一个基本的打包扫描方案,包含checkstyle 固定团队编码风格,固定命名风格以及换行风格等,原型配置出资googlestyle, 修改缩进为4个字符(原型是2个)surefile test report Junit Test结果报告JaCoCo test coverage ...

weixin_28267011的博客 406

华为的C语言编程规范.pdf

华为技术有限公司内部技术规范。本规范制定了编写C语言程序的基本原则、规则和建议。从代码的清晰、简洁、可测试、安全、程序效率、可移植各个方面对C语言编程作出了具体指导。

VB摄像头监控

该VB模块可对摄像头捕获的画面进行录像等,可在创建的窗口进行控制

Java代码规范检查插件选型与落地实践:Checkstyle、PMD、SonarLint深度对比

在软件工程实践中,代码质量是保障项目可维护性与团队协作效率的基石。其核心原理在于通过静态代码分析技术,对源代码进行自动化检查,识别出不符合预定规范的代码模式、潜在缺陷及安全漏洞。这项技术的核心价值在于将质量保障左移,在编码阶段而非测试或上线后发现问题,从而显著降低修复成本与线上风险。它广泛应用于团队协作开发、持续集成流水线及技术债务管理等多个场景。本文聚焦于Java生态中主流的代码规范检查工具,深入剖析Checkstyle、PMD与SonarLint等插件的核心机制与实战应用,为团队构建自动化质量防线提供关

weixin_33850890的博客 437

Data-Structures-and-Algorithm-Analysis-in-Java.pdf

作者: Weiss, Mark A. 出版社: Addison Wesley Data Structures and Algorithm Analysis in Java is an “advanced algorithms” book that fits between traditional CS2 and Algorithms Analysis courses. In the old ACM Curriculum Guidelines, this course was known as CS7. This text is for readers who want to learn good programming and algorithm analysis skills simultaneously so that they can develop such programs with the maximum amo...

常用java代码质量检查工具.md

常用扫描工具 PMD-CPD :Copy/Paste Detector (CPD) 代码重复率检测 PMD:分析 Java 源代码,找出潜在的 bug Findbugs :Java bug检查 checkstyle : 固定团队编码风格,固定命名风格以及换行风格等 P3C: 阿里巴巴Java规范,这个是PMD扫描,但移除了PMD自带的n条规则,只执行阿里的规则 Sonar Quabe: 一站式代...

借你一秒 2997

Probability and Statistics - 4th edition

Probability and Statistics - 4th edition

为Java设置静态代码分析

介绍 在本文中,我们将介绍Java项目的静态代码分析的基本设置。 为什么静态代码分析很重要?它有助于我们确保整体代码质量,修复开发早期阶段的错误,并确保每个开发人员在编写代码时使用相同的编码标准。 我们将使用三种基本工具进行静态代码分析:CheckStyle,Findbugs,PMD。 的CheckStyle CheckStyle是一个工具,可以帮助程序员编写符合已经商定的编码标准的代码。它会自动...

Tybyqi的博客 630
上一篇: CXF、Restlet、RESTEasy、Jersey对比
下一篇: DbUnit 的数据层测试
jianxuan
博客等级 码龄26年 15粉丝 54原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值