代码检查记录（通用11篇）
篇1：代码检查记录
代码检查
摘要：代码检查是白盒测试的一种静态测试方法，是众多软件测试方法中发现软件缺陷最有效的方法之一。本文结合国内外学者在相关领域的研究情况，介绍代码检查相关的基本概念、过程和分析方法。
关键字：白盒测试，代码检查，静态分析，检查规则
一、引言
按照测试时源代码是否可见，软件测试可以分为白盒测试和黑盒测试两类。
白盒测试（结构测试），即逻辑驱动的测试，是在了解程序内部结构的基础上，对程序的逻辑结构进行检查，从中获取测试数据。白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构的程度。白盒测试一般只应用于软件开发阶段。
白盒测试，又可按照是否需要运行程序，进一步细分为了静态测试和动态测试两种。通常情况下是按照先静态后动态测试顺序来实施。其中，静态测试包括代码检查、静态结构分析、代码质量度量等测试内容。静态测试既可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
代码检查是一种对程序代码进行静态检查。传统的代码检查是通过人工阅读代码的方式，检查软件设计的正确性；用人脑模拟程序在计算机中的运行，仔细推敲、校验和核实程序每一步的执行结果，进而判断其执行逻辑、控制模型、算法和使用参数与数据的正确性。
在实践中，代码检查比动态测试更有效率，能找到更多的缺陷，通常能发现30%～70%的逻辑设计和编码缺陷。代码检查非常耗费时间，而且需要专业知识和经验的积累。代码检查定位在编译之后和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。
代码检查可以发现的软件问题包括：声明或引用错误、函数/方法参数错误、语句不可达错误、数组越界错误、控制流错误、界面错误和输入/输出错误等。
1、代码检查
代码检查包括桌面检查、代码走查和代码审查等方式，主要检查代码和设计的一致性，代码对标准地遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等方面；发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型检查、程序逻辑检查、程序语法检查和程序结构检查等内容。下面对代码检查的三种具体方式进行介绍。
桌面检查
是一种传统的检查方法，由程序员检查自己编写的程序。程序员在程序通过编译之后对源代码代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。
代码走查
代码走查就是针对代码，在假想的输入情况下，逐行的浏览代码，走查代码中潜在的缺陷并记录结果的过程。
代码走查以小组会议方式进行，每小组3-5人。与代码审查不同的是，走查要求与会者扮演计算机的角色让测试用例沿被测程序的逻辑运行，是在模拟动态测试；而代码审查更多的是静态测试。
代码审查
代码审查是由一组人通过阅读、讨论和争议对程序进行静态分析的过程，以小组会的方式进行。
审查小组一般由若干程序员（包括程序代码的设计者）和代码检查人员组成。会前把设计规格说明书、控制流程图、程序文本以及要求、规范、错误检查清单交给与会者，开会时程序作者朗读解释程序，其他人则集中精力，捕捉程序在结构、功能、编码风格等方面的问题。
2、代码检查项
代码检查项即检查代码时，指定需要进行检查的内容。具体如：检查变量的交叉引用表；检查标号的交叉引用表；检查子程序、宏、函数；等价性检查；标准检查；风格检查；选择、激活路径；对照程序的规格说明，详细阅读代码，逐字逐句分析；补充文档。
检查项可以作为依据，用来编制代码规则、规范和缺陷检查表等。
3、编码规范
编码规范是程序编写过程中必须遵循的一套事先约定或者已经制度化、标准化的规则集，一般会详细的规定代码的语法规则和语法格式。
一个良好的编码规范能够带来许多好处：改善代码质量；提高开发进度；增进团队精神。对于软件开发而言，采用好的编程规范，虽然不能彻底杜绝糟糕的代码产生。但对于代码检查和将来的代码维护，仍然是意义重大的。
4、缺陷检查表
在进行人工代码检查时，使用代码缺陷检查表作为代码检查的参考依据。在软件测试项目实践中代码缺陷检查表又常被称作代码检查清单。
代码缺陷检查表中一般包括开发人员容易出错的地方和在以往的工作中遇到的典型错误。对应于不同的编程语言，代码缺陷检查表的具体内容将会有所不同。例如：对于C/C++语言代码缺陷检查表内容有以下几部分：文件结构；文件的版式；命名规则；表达式与基本语句；常量；函数设计；内存管理；C++函数的高级特性；类的构造函数、析构函数和赋值函数；类的高级特性；其他的常见问题等。
5、代码检查规则
在代码检查中，需要依据被测软件的特点，选用适当的标准与规范。在使用测试软件进行自动化代码检查或辅助代码检查时，测试工具需要内置许多编码规范。不同编程语言，对应的检查规范有所不同。针对与C/C++语言的规则有以下几类规则：通用规则、C++编码规则、C编码规则、Meyers-Klaus规则以及自定义规则。使用时，需要根据编程语言和被测程序的特点，选择适当的规则进行检查。
6、静态分析
静态分析是不执行程序，而分析程序代码的过程。源代码被静态分析器分析之后，得到的静态分析结果，通常可以表示成一棵静态语法树。其中包含了被测项目源代码的静态结构信息：基本代码成分、程序结构、语句结构、类型和模板等信息。
程序代码静态分析的结果能够给代码检查提供帮助。
三、代码检查过程
传统的代码检查是一种静态检查程序的测试方法，通常以团队的形式来进行。检查团队由程序作者，一个负责人，一个记录员以及一些检查员组成。首先需要一系列的准备工作，包括参与者的挑选和材料的准备。然后是个人准备阶段，每个小组成员各自熟悉材料。个人准备阶段后，就是实际的检查会议。在会议上，检查小组在假想的输入下，由程序作者带领，逐行的浏览代码，评审代码中潜在的缺陷。检查小组根据发现缺陷的严重程度和类型对其进行分类，并将问题记录下来供作者修正。会议后是作者的返工，作者汇报每个缺陷，最后确认每个缺陷已经被陈述过了。图 11为传统的代码检查过程。
图 1 代码检查过程示意图
代码检查过程中的两个重要阶段“个人准备”和“召开会议”阶段有以下注意事项：
1、“个人准备”阶段：
会前准备阶段是检查过程的一个关键阶段，因为如果检查者没有为检查做好充分的准备，检查效果会大打折扣。如果有检查人员没有做好准备，主审员可取消其代码检查资格，甚至取消这次检查会议。
检查人员要熟悉检查内容的相关文档，了解程序背景、设计思想和编程方法，在读懂、“吃”透代码的基础上，查出尽可能多的错误。
2、“召开会议”阶段：
参与会议的检查者应具有一定的专业技能和经验，缺乏经验的检查人员必然缺乏合适的领域知识来深入理解材料；
参与会议的检查者应做充分的个人准备，没有做充分准备的检查人员不能在检查会中做出实质性的贡献；
检查会议的速度应进行控制，如果试图在短时间内处理太多的材料，检查效果也会大打折扣。现在较为常见的代码检查速度上的建议为：汇编代码150行/小时，C语言150行/小时，而对于C++、Java这种面向对象语言，代码检查速度可以提高到200-300行/小时。
由此可见，代码检查适合于采用工具辅助的特性有：文档处理，个人准备，会议支持，数据收集。
文档处理
这是工具可支持的最明显的领域。传统的检查要求分发每份文档的复印件等，而将纸质的文档替换成计算机式的文档，不只是简单的介质变更，更是提供了一种契机——提高文档的可用性和表示性的机遇。
个人准备
首先，自动的缺陷检测可以用来发现简单的缺陷。如果简单问题能被自动发现，检查员就能专注于更加复杂/困难的缺陷，以及那些不能被自动发现的、潜在的、可能带来更大影响的问题。另外，自动化工具应该对个人准备阶段提供更多的帮助。例如，检查员可以利用检查表以及其它支持文档，并能很容易地交叉引用它们；还有些代码辅助理解工具，可为检查员理解程序、了解程序结构提供帮助。 会议支持
一些成员由于某些原因，可能没有花费足够的时间来进行准备，但他们仍然参加会议并试图掩盖他们的过失。项目管理人员可以使用计算机监控的个人准备时间信息，来剔除那些没有做好个人准备的成员，或者督促他们投入更多的努力。
召开会议时，检查员通常面对的是一堆枯燥的程序代码，如果在代码之外再结合一些图、表等便于分析、理解代码的信息，相信检查会议可以进行得更加有序和高效。
数据收集
代码检查一个重要的部分就是度量信息的收集，用来提供反馈以改进检查过程。度量信息包括会议时间、发现的缺陷、检查花费的总时间等。根据这些数据，可以来评价每一次代码审查的质量，进而给出关于代码审查的改进建议。
通过对检查过程的部分阶段提供计算机支持，代码检查可以进行得更加有效。使用计算机来支持检查过程，可以提高效率，并增加检查过程的严格性。
四、代码检查历史数据
代码检查中的历史数据本质是软件问题（缺陷）。按照不同的代码检查角度，存在多种对缺陷分类的方法。对过往发现的软件问题进行分析，总结出今后对于类似的代码需要按照某种规则来加以检查，这种的规则就是检查清单上的一条清单项，代码检查清单就是大量规则的集合。此外，由于软件问题总是以软件问题报告为载体形式出现，因此软件问题报告也被通俗的理解为代码检查历史数据。
下面对缺陷分类、代码检查清单和软件问题报告加以研究。
1、缺陷分类
关于缺陷分类存在以下几种常见的划分方式：
1）按缺陷出现的区域分类
这种分类方式是最常见的缺陷分类方式。按照出现区域将代码缺陷划分为变量级、属性级、函数/方法级和类级缺陷。其中，变量级、属性级和部分函数/方法级的缺陷，与传统的面向过程编程中的缺陷分类基本一致；而多数方法级缺陷和类级缺陷，则是针对面向对象技术编程特点提出的。
2）按检测内容分类
分为冲突、一致性问题两种。
冲突对应于文献[1]中的基于确定性“信念”的判定，而一致性问题则对应于基于可能性“信念”的判定。
3）按对代码的危害分类
按照对代码的危害，一般分为浪费时间和空间；语义混淆；暴露封装性，扩大使用权限；程序一致性问题；程序约束条件问题和空指针问题等。
2、代码检查清单（Checklist）
代码检查过程中，代码检查人员都会有一份代码检查清单。代码检查清单是一份为代码检查人员准备的缺陷检查表，检查表中开列所有可能与代码有关的缺陷，并注明了检查的内容、缺陷类型以及严重性。检查清单是检查代码的依据，代码检查人员根据它来发现并判断问题。代码检查清单中会逐条列出所有应该检查的缺陷种类，以及每条缺陷的各种特征，并且根据缺陷的严重程度和类型对其进行分类。通常每一条缺陷的特征描述如下：
1）缺陷描述：该缺陷的问题描述、举例说明，以及相应的正确形式；
2）缺陷出现的区域：分别为表达式级、语句级、声明级、模板缺陷、预处理缺陷、类级缺陷以及性能缺陷。表达式级、语句级、声明级以及预处理的缺陷，主要面向过程程序中的缺陷；模板缺陷、类级缺陷，则是针对面向对象软件的特点提出的；代码冗余等归为性能缺陷；
3）缺陷对代码的危害：代码中出现某种缺陷将会造成什么样的影响。
例如，检查表中一条缺陷的特征描述如下：
问题描述：指针所指内存释放后没有将指针赋为NULL。
举例说明：
char *p=(char *)malloc(100);strcpy(p, “hello”);free(p);//p所指的内存被释放，但是p所指的地址还是不变 …
if(p!=NULL)//没有起到防错的作用 { strcpy(p, “world”);//出错 }
正确形式：在释放内存的同时将指针置空。
char *p=(char *)malloc(100);strcpy(p, “hello”);free(p);p=NULL;//增加指针置空语句
…
if(p!=NULL){ strcpy(p, “world”);}
出现区域：语句级。
危害：指针被free释放后其地址并不会自动发生改变（非NULL），p成为了“野”指针，这种情况下再对p进行操作，很容易造成程序崩溃，后果非常严重。而代码检查清单正是由若干条这样的缺陷特征描述构成的。
3、软件问题报告（Software Problem Report）
在软件测试过程中，对于发现的每个软件问题（缺陷），都要进行记录该错误的特征和再现步骤等信息，以便相关人员分析和处理软件问题。为了管理测试发现的软件问题，通常要采用软件问题报告数据库，将每一个发现的软件问题输入到软件问题报告数据库中，软件问题报告数据库的每一条记录称为一个软件问题报告。
软件问题报告包括头信息、简述、操作步骤和注释。
头信息包括：被测试软件名称、版本号、缺陷或错误类型、可重复性、测试平台、平台语言、缺陷或错误范围。并要求填写完整和准确。
简述是对缺陷或错误特征的简单描述，可以使用短语或短句，要求简练和准确。
操作步骤是描述该缺陷或错误出现的操作顺序，要求完整、简洁和准确。对命令、系统变量、选项要用大写字母，对控件名称等要加双引号。
注释一般是对缺陷或错误的附加描述，一般包括缺陷或错误现象的图像，包括其他建议或注释文字。
软件问题报告是软件测试过程中最重要的文档之一。它记录了软件问题发生的环境，软件问题的再现步骤以及性质的说明，而且还可以跟踪软件问题的处理过程和状态。软件问题的处理进程从一定角度反映了测试的进程和被测软件的质量状况及改善过程。
五、代码检查规则管理的研究
1、潜在的编码规则和缺陷代码模式
潜在的编码规则（Implicit Coding Rules）和缺陷代码模式（Bug Code Pattern）是Tomoko MATSUMURA在文献[3,4]中针对代码检查实践，提出的两个相关的概念。
潜在的编码规则
潜在的编码规则包含以下几个特征：
1）不同于在开发启动时明确决定的“编码规范”的规则，这些规则在长期的测试/维护过程中是潜伏的，对这些规则的发现是不可预见的。
2）这些规则很少在设计文档或者特定的文档中被清楚的描述。他们通常只存在于开发人员、测试/维护人员的记忆中。换言之，是一种尚未系统化的经验积累和总结的结果。
3）不同于使用规范库的公用规则。对于特定的软件有其特定的规则，这也意味着对于不同的软件有不同的潜在的编码规则。
4）由于违反潜在的编码规则导致的缺陷通常情况下不是那么容易发现的。其中相当多一部分只在特定的罕见的情况下发生，所以在早期要想发现这些问题是很困难的。
5）目前，还不存在好的工具或者检查清单来发现违反潜在的编码规则的代码片段，通常的检查工具（例如PC-Lint、Purify）和通用的检查清单只能发现常见的问题。
6）为了减少违反潜在的编码规则的现象的发生，而进行重构通常很困难。要重构一个软件，准确理解代码是非常必要的，然而，老的系统太复杂，并且没有精确的文档和了
解系统的专业维护人员。总之，重构过期系统的代价很大，需要冒很大的风险。
缺陷代码模式：违反潜在的编码规则的编码模式。
缺陷代码模式不是肯定会导致缺陷的发生，一段符合缺陷代码模式的代码片段，并不意味着代码片段一定就有缺陷，缺陷代码模式只是疑似存在缺陷。另一方面，因为缺陷代码模式是静态的，没有考虑到代码片段之间的动态关联。需要代码检查人员或者维护人员把符合缺陷代码模式的代码片段提出来，并判断究竟是否存在缺陷。
在软件开发过程中发现和建立缺陷代码模式有三条主要途径。其一：在进行代码检查过程中，代码检查人员发现一个软件问题的同时，根据对该问题是否具备代表性和通用性等因素的考虑，确定是否建立一个缺陷代码模式；其二：当软件失效或者发生问题，检查对应的代码部分，发现并确定是否有潜在的编码规范与之相关；其三：分析现存的代码规范和积累的大量问题报告，从中提炼出潜在的编码规则。
在文献[3,4]中还给我们介绍了一个代码缺陷检测系统的大致工作流程，如2所示。
图2 缺陷检测模型系统的代码检查流程参考图
2、C++代码检查规则类型
1）规则层次
在代码检查工作中常常可以发现这样的现象：有些规则能在所有的项目中都能发现问题，另一些规则所能发现的问题只存在于某类项目中。
根据规则的这个特点，如图 33中所示，参考文献[2]中将代码检查规则分为两个层次：
公共规则（General checks）：用于检查在大多数情况都有可能发生的缺陷。
项目相关规则（Project specific checks）：用于在项目中检查可能的缺陷。
图 3 一个典型的代码检查规则清单节选图
在项目中积累了大量软件问题报告历史数据的支持下，可以从中进一步细化出与项目或开发人员相关的检查规则。
在学习任何一种计算机编程语言时，总是按照基本数据类型－>表达式－>语句－>复杂语句－>函数－>整个程序体(类)的顺序逐步学习的。事实上软件正是按照这样的顺序自下而上逐层组建起来的，代码缺陷作为软件编程写时的一种异常情况，毫不例外也是按照这样层次的构建而成。在实际测试项目的代码检查过程中，我们发现在每个层次上都有可能存在潜在代码缺陷，要找到引起软件问题的根源，要求在尽可能低的层次上找到引发缺陷的代码。正因如此，非常有必要在C++语法的每个层次上都建立相应的检查元规则。
图4为一个代码检查规则体系模型图[2]，图中展示了在代码检查项目开始前，通过逐级组合各种元规则和规则形成新的检查规则，最后形成了初始的检查清单。在项目实践中，经过对缺陷代码模式的推导，进而得到扩展的检查清单。初始检查清单和扩展检查清单本质上并没有什么区别，只是因为形成的时间不同。
图4 代码检查规则体系模型图
在检查代码时我们有时会想要定义一个带有否定意义的规则，如“在AA情况下如果没有BB，则可能存在一个问题”。这类检查规则采用自然语言描述比较容易，但是要用代码实现起来往往并不简单，并且对这类规则的定义和维护也比较麻烦。定义组合规则，是解决这类问题一种变通的方法。
下面简单介绍一下定义组合规则的原理。如图5中所示定义三个规则，“满足情况AA”对应规则R1，“满足在AA情况下出现BB”对应规则R2，将满足R1但不满足R2（即以！符号表示）组合则对应规则R3－“在AA情况下如果没有BB，则可能存在一个问题”。
图5 组合规则示例图
根据前面讨论，本文将代码检查的规则分类设计如下：
公共规则
定义针对函数体（含）以上层次的检查规则，在这些层次上出现的缺陷问题一般不容易精确到具体的代码行。
关键字规则
针对每个关键字定义的检查规则。由于关键字是C++语法中一种最普通的元素，单独使用关键字规则的意义不大，一般情况需要和语句、表达式规则或者复杂语句规则配合使用。
语句/表达式规则
针对基本语句类型或基本表达式定义的规则，满足对应结构的表达式，则可认为符合了相应的表达式规则。语句/表达式规则中可以包含多个关键字，在同一语句/表达式规则中包含的关键字地位是平等的，与检查的先后次序无关。
复杂语句块规则
针对条件、开关选择等多分支语句定义的规则，通常由关键字、语句/表达式进行组合来定义复杂语句块，并在定义时可以进行嵌套，在定义复杂语句块规则加入语句或表达式和复杂语句时需要考虑检查的先后次序。
高级组合规则
关键字规则、语句/表达式规则和复杂语句块规则合称为普通规则。
对于难以使用普通规则定义方式定义的复杂语义，需要定义高级组合规则。定义高级组合规则可以使用上面几种规则作为基本单元，也可以嵌套使用其它组合规则。
图6为一个由下至上、由多个缺陷代码模式组合形成的组合规则结构图。其中{}表示某条缺陷代码模式对应的规则。
图6 组合规则结构图
六、代码分析方法
1、静态分析
静态分析主要对源代码进行词法分析、语法分析，提取被分析程序的静态信息，所提取的静态信息是代码缺陷检测的基础。静态分析结果主要包括三部分信息：
程序定义信息：程序定义信息包含了程序中所有的定义和声明信息，如类定义、方法和数据成员的定义、方法内局部变量的定义等。
程序结构信息：主要指方法内的控制流信息和方法间的调用关系。静态分析器分析程序的语句分支、分支间的嵌套关系和方法调用，记录方法的控制流信息和调用信息，构造语法树。
分支内的变量操作：以方法控制流程中的分支为基本单元，记录每一分支中各语句对各变量施加的操作和操作序列。
2、数据流分析
数据流分析也是一种静态代码检查方法。它是在不通过计算机运行被测程序的条件下，利用预先进行静态分析后获取的信息，检测对变量的赋值与使用操作中，是否存在不合理情况，即找出被测程序中是否存在变量在使用前未被赋值；变量在两次赋值之间未被使用；一个变量在被赋值后是否未被使用等异常情况。
数据流分析目前的主要用途大多局限在编译器的实现和优化技术方面，而在代码检查系统中实用的数据流分析技术并不多见，主要集中在某几种缺陷检测上，如赋值引用异常检测以及内存错误检测，使用方式主要是定义数据流操作的符号，使用该符号系统构造数据流表达式（由数据操作符号构成的符号串），再分析该符号串来确定是否存在代码缺陷。
数据流分析包括以下两个步骤：一是分析程序的所有逻辑路径；二是对所有逻辑路径上的所有变量，分析其所有操作序列，然后将得到的操作序列输入自动机进行分析。因此数据流分析方法不可避免的存在以下缺点：
1）信息量多，上面所述的数据流分析方法是一种穷举法。事实上一个变量在大部分路径上存在问题的几率并不高，因此穷举每个变量的所有操作序列不可避免的要分析很多正确的信息，而且信息量巨大；
2）组合爆炸，当程序复杂度增长时，该分析方法的复杂度呈几何级数增长，并且当这种组合是建立在对所有逻辑路径、所有变量的穷举基础上时，如果不能找到一个非常高效的算法，数据流分析方法将是一个非常低效的方法；
3）实用性低，上述两点导致的数据流分析的实用性降低。
为缓解这些的缺点，数据流分析过程有许多改进方法，但实现都具有一定难度。本系统中数据流分析不是重点，采取的策略是尽可能简化数据流分析的过程，或者在可能的情况下尽量避免数据流分析。
篇2：代码检查记录
Java项目最枯燥的一部分，也是程序员总是避而不谈的一部分，就是检查代码。为了区块括号、代码缩进、Javadoc注释以及命名约定而检查其他人的上千行代码的确是一件痛苦的事。更糟糕的是，通常代码的检查还受限于紧迫的项目进度。没有足够的时间对代码的细节进行评估，因此代码检查经常变成了对代码的美化练习。不管检查者有多么好的意图，优化和逻辑检查都退居次席。
Java代码分析器减轻了这样的痛苦
在面对这种情况的时候，Java代码分析器正是对症良药。这些工具尽可能地将代码检查过程自动化。留给人工来做的就只有检查类的缺陷以及核心逻辑并确定可能的优化方法。优化（去除不必要的实例化对象、检查数据库连接是否合理、确保数据在可能的情况下被缓存）对于任何代码通常会带来性能上的极大改进。
最近我接触了各种代码分析器。我觉得一个基本的最重要的功能是与常用IDE（如NetBeans、Eclipse、jEdit以及JDeveloper）的集成。有一些代码检查工具在查找错误方面很有效，但是它们需要你根据给出的错误行的行号手工来追踪错误。这样的工具使用起来太累人了。与IDE环境集成了的工具可以大大简化这个过程，因为代码检查的结果是由所使用的IDE显示的。你只需在错误上双击就可以在Java编辑器中到达错误代码所在的行
我的试用心得
在我试用过的工具中，我发现其中三个工具十分强大并合乎与IDE集成的标准，它们是： PMD、Checkstyle 和 Jalopy。
PMD和Checkstyle
根据PMD的文档，它会对代码中的如下部分进行检查：
未使用的本地变量
空的catch块
未使用参数
空if语句
重复的import语句
未使用的私有方法
可能是Singletons的类
短/长变量及方法名字
Checkstyle检查如下部分：
Javadoc注释
命名约定
标题
Import语句
体积大小
空白
修饰符
块
混合检查（包活一些有用的比如非必须的System.out和printstackTrace）
它们的作用
不像PMD，Checkstyle能够检查Javadoc注释；但是PMD提供了一项叫作CPD的很有用的功能，它检查代码的拷贝粘贴部分。我使用PMD找到的最频繁的错误是未使用的import语句，未使用的私有变量以及意外重复拼写。Checkstyle可以发现更多的错误。包括漏掉的Javadoc注释，超过80个字符的行、不合约定的变量名、用tab来代替空格等等。两个工具都允许创建自定义的规则。
如果想在你的组织中使用它们中的一个，Checkstyle似乎更好一些：它检查公司编码约定的大多数项目。如果增强代码质量是主要目标，那PMD是一个好的选择。但是如果你想要更多的功能并真正使用工具来修改代码，应该试试Jalopy。
Jalopy
Jalopy是一个易于配置的源代码格式程序，它能检测并修补Java代码中大量的习惯性缺陷。Jalopy更像一个代码整理器而不是检查器。Jalopy的插件现在已经支持大多数IDE，而且多数是无缝集成。我发现Jalopy特别强大，能够干许多很酷的事情。例如，它可以修改代码缩进、对齐括号、使行宽符合某个字符长度、插入相关的Javadoc注释以及对import语句排序。Jalopy最好的地方是超级自定义功能。一个简单的用户界面就可以让你选择Jalopy的所有功能的开关，不需要XML配置文件。
不要浪费资源
篇3：代码检查记录
随着互联网的发展,PHP+MySQL已逐渐成为Web应用程序开发的一项主流技术。在此阐述分栏显示记录集的两种方法,并基于PHP+MySQL技术给出相应的PHP程序代码。
1 分栏显示的两种方法
分栏显示记录集的基本方法有两种,一种是先行后列法,实现如图1所示的显示效果;另一种是先列后行法,实现如图2所示的显示效果。
无论采用哪一种分栏显示方法,都必须在输出记录之前访问数据库,获取查询记录集,并将其保存到数组中。相应PHP代码如下:
为了便于给出分栏显示的PHP程序代码,不妨假设MySQL数据表具有表1所示结构。
2 先行后列法PHP代码
采用先行后列法分栏显示记录集,必须预先指定栏目数。其实现步骤为:首先建立表格,显示列名行;其次,遍历存储记录集的二维数组,将其转化为一维数组后循环显示数据行;最后,根据需要补充显示空白栏目或空白行,以保证表格完整和美观。相应PHP代码如下:
3 先列后行法PHP代码
采用先列后行法分栏显示记录集,必须预先指定栏目数和每栏显示记录数。其实现方法是使用三层嵌套循环:外层为栏目级循环,用于显示栏目;中层为行级循环,用于显示记录;内层为单元格级循环,用于显示字段。相应PHP代码如下:
4 结语
文中给出的PHP程序代码已在PHP+MySQL开发环境中验证通过。实际应用中,数据表通常有成千上万条记录,为了显示查询记录集,必须将分栏技术与分页技术结合起来,进行综合应用,以获得较好的输出效果。
参考文献
[1]李刚.网络数据库技术PHP+MySQL[M].北京:北京大学出版社,2008.
篇4：组织机构代码证超期年检检查
**技术监督局组织机构代码办公室：
我单位****有限公司2009年03月02日经**工商行政管理局批准成立，地址位于**市**区**路*号*层*号，法定代表人：***，注册资金：****万元整，经营范围：*********************。我公司的营业期限为****年**月**日至****年**月**日。此前由于代码证及营业执照不慎丢失，补好后却已错过组织机构代码证年检期限，由此给贵办公室的工作造成的不便，表示深深的歉意。造成此后果都是因为我单位的工作疏忽，我单位保证以后不再出现此种情况。
最后，再次为我公司的代码证年检超期对贵办公室的工作所造成的不便，表示深深的歉意！
此致。
****有限公司
篇5：代码检查记录
1.系统winxp,登陆时,提示:“一个问题阻止Windows准确的检查此计算机的许可证”,无法进入系统‘确定’后系统注销，陷入死循环。,，安全模式则正常。
解决方法：进入安全模式，在安装光盘里找到oembios.bi_和expand.exe(i386目录下面),拷到硬盘上，如C:下面,运行cmd,(在C:盘下运行dos命令:expand oembios.bi_ oembios.bin,),如果解压有问题，可以可以用winrar解压,解压后会得到一个OEMBIOS.BIN文件,把这个文件复制到系统的安装目录:WINDOWSSYSTEM32下面,重启即可
如果问题依旧。
篇6：作业检查记录
二、存在的不足
1、有的班级学生的错题没有订正，有些订正后老师没进行第二次批改;还有一些老师批改马虎，一些做错的题目当对来勾，造成误批。
2、个别班级的作业书写普遍马虎，字体不够美观。
3、各班差生作业质量都较差，老师也没有跟进督促，作业本、练习册上的作业做错很多后，都没有订正。
4、有些同级的的单元分析表，除了分数情况，表格里的分析内容是一模一样的。
三、针对本次作业检查情况，建议如下：
1、鼓励所有教师评价应能结合学生特点及作业质量给出定性评价，并且写出相应的鼓励性或期待性的文字评价，或绘简笔画图形等评语。但是不要只表扬优秀学生作业，而更应该努力发现较差学生进步的闪光点，以此为契机，培养学生兴趣，激发学生上进。
2、对差生的作业要严格要求订正，要根据定好的措施认真做好扶差工作。
3、以后在写单元分析表时，应根据每班的实际情况制定可行的措施，措施应该有针对性和实效性。
希望各老师能从这次检查总结中找到自己的不足，反思
总体上看，数学教师们备课态度较认真，教案详尽，课时数量充足；大多数教师能根据所任学科教材及所教班级实际，认真制定好新学期教学计划，安排好教学进度。每篇课文按课时备课，每课时根据学生实际定好教学目标，确定教学重、难点，有一定的教学准备，教学过程较清晰。全体数学教师能按规定备课，备课有超前意识；个别的教师的备课书写字迹清晰端正，设计合理，过程详细，教学目标明确，重难点把握准确到位，体现教法、学法，教学过程清楚，作业设计格式统一，练习层次分明，图文并茂，练习量适当，有详细的板书设计，课后反思及时、详细、深入、能根据实际情况有感
1）多数教师布置的作业量适度，批改及时有复批；
（2）涉及书中练习册上的习题均有详尽的批改。
（3）个别数学老师根据学生差异采用分层次布置作业的做法，调动不同层次学生的学习积极性。一部分数学老师课中适当加一些思考题。
（4）希望数学老师更加注重学生作业本上即时评语的运用。将作业本开发为进行班级管理的又一阵地，成为家长、老师、学生情感沟通的桥梁。
2、存在问题：
（1）学生作业本保洁不好，纸页不整齐。
（2）个别班中学生本上的作业量不统一。
（3）个别老师批改作业不够认真、严谨。
（4）建议老师加强对学困生多采用面批形式。
三、尖子后进生辅导记录：
大部分教师的培优扶差记录本都是过于简单，都没书写计划，没有成绩跟踪，只体现扶差，没体现尖子辅导。个别教师的记录本只体现题纲，没具体内容，一题练习都没有；个别教师的书写过于马虎，有应付检查的嫌凝。扶差是提高数学质量的关键，可能同事们是有做这项工作，但希望也做好资料的书写吧。
改进意见：
1、认真钻研教材，努力提高自己的教学观念，备课时要备教材，也要备班级的学生的学习情况。年青教师应该写好详细的教案。按实际上课课时进行备课。
2、借鉴人家的东西要联系自己的实际情况，认真舍取，而不能照搬照抄。
3、课后反思要有一定的数量，也要有一定的质量，每次上完课要认真总结反思，以改进自己的教学，为今后自己更好的教学积累一笔财富。
4、在批阅学生作业时发现学生有错误，要少打“×”，圈出来或划出来，让学生订正后再批。
5、把漏写的东西要及时整改，补充完整。
6、对待资料的工作检查要保持良好的心态，不足的就整改。
7、数学教案要多一点备练习。练习量要足、练习题型要多层次。
篇7：代码检查记录
随着GB 50300—2013建筑工程施工质量验收统一标准 (新版) 的发布和实施 (旧版GB 50300—2001同时废止) , 相对于旧版标准有一些修订、补充和完善, 必然带来对质量验收的新要求和资料记录方面的一些新规定。本次标准修订的本意在于提高检验批抽样检验的理论水平, 使抽样符合统计学原理, 满足样本分布均匀, 抽样具有代表性, 检查记录具有可追溯性等要求, 解决建筑工程施工质量验收中的具体问题, 丰富和完善标准的内容。
新标准已实施一年多了, 但笔者发现项目部主管技术、质量的人员对于新标准的理解并不到位, 对检验批的划分无所适从, 质检人员的检查记录和技术资料上填写的完全是两张皮, 没有对应性, 和现场实体质量更是无法追溯, 资料也就谈不上真实可信了。造成这一问题的关键就是项目部事先未制定《各分项工程检验批验收抽样方案》, 未明确抽样方法、检验批容量、样本容量以及最小抽样数量, 并且未与施工现场的实体形成对应关系。
下面, 笔者结合龙瑞苑项目质量验收及检查记录填写的部分实例与各位分享、交流。
1 工程概况
工程概况如表1所示。
2 以A座主体结构施工阶段为例, 填写检验批质量检查记录
1) 由项目工程师或技术员将工程各分部、分项检验批的划分方案传至质检员, 如表2所示。
2) 由质检员根据各检验批的划分情况和项目工程师或技术员共同编制《检验批验收抽样方案》。
3) 《检验批验收抽样方案》中要明确抽样方法、检验批容量、样本容量以及最小抽样数量 (需满足检验批最小抽样数量要求, 见表3, 表4) , 并绘制与实体的对应关系图, 或用表格轴线编号等给样本予以定位。A座标准层梁柱墙定位见图1。
说明:现浇结构外观及尺寸偏差检验批的抽样方法应在方案中注明。根据“新标准”3.0.9条及“解读指南”中的条文解读, 验收抽样应事先制定方案、计划, 可以抽签确定验收点位, 也可以在图纸上根据平面位置随机选取, 最好是验收前由各方验收人员在办公室共同完成, 尽量不要在现场随走随选, 避免样本选取的主观性。我们项目编制的抽样方案明确规定了分单、双数抽样, 即选用方法1抽单数或方法2抽双数后全检并记录, 同时作为考核施工队伍质量水平的奖罚指标。
4) 质检员按抽样方法验收并填写《现场验收检查原始记录》, 见表5, 表6。
5) 根据《现场验收检查原始记录》填写《检验批质量验收记录》。
3 经验总结及建议
从以上实例可以看出, 该抽样方案完全实现了三性:抽样具有代表性;原始的样本记录和检验批汇总记录具有对应性;记录和现场实体部位具有可追溯性。实现了新标准的意图, 解决了建筑工程施工质量验收中的实际问题。
根据以上需实现“三性”的原则, 技术、质量管理的同行们可以参考制定出其他分部、分项检验批的抽样方案。如屋面工程中的卷材防水, 土方工程中的土方回填, 抹灰工程中的室内一般抹灰, 见表7。
4 结语
《建筑工程施工质量验收统一标准》属于我国《工程建设标准体系》中“建筑施工质量专业”里的通用标准, 大约每间隔10余年修订一次, 每修订后的变化或者增加的内容必然有新的解读和一段时间内的各自理解的做法。笔者总结的这点经验和建议难免存在不妥之处, 只希望能够给同行们参考借鉴, 起到抛砖引玉之效用。
摘要：以国瑞企业总部基地龙瑞苑商务写字楼实际工程为例, 结合质量检验抽样方案的要求, 阐述并列举了新标准实施后检验批质量检查及相关记录的填写方法, 以提高检验批抽样检验的水平。
关键词：质量检查,检验批,抽样方案
参考文献
[1]GB 50300—2013, 建筑工程施工质量验收统一标准[S].
篇8：期中教学检查记录
为了配合期中教学检查工作，加强对同学们的监督管理，更好地去了解他们最近的学习生活情况。我于4月17日晚上八点半，于BS402召开期中教学检查学生代表座谈会，会议由我主持。会议过程，我先让各班委就最近班级的表现各自发言，并指出不足之处，最后由我总结发言。主要内容现汇总如下：
一是学生反映高数老师比较认真负责，教学态度严谨，课堂氛围好。但仍存在个别同学存在逃课现象。但大多数学学生不迟到早退，课堂表现良好，学习积极性主动性比较好，学生能自信的学习。
二是大多数同学反映数据库和电路课程授课不易听懂，学习起来比较吃力。课程跨度大，与之前学的不能很好的衔接，从高中到大学很多内容还没有接触过，还没有对新知识的学习方法入门，对专业课的认识模糊，学习起来比较吃力。
篇9：检查听课记录评语
季艳芳老师的语文课给我的感受是备课充分、讲解精辟、重点突出、善于调动学生积极性。
房平老师的英语课思路清晰、语言流畅、安排合理、效果良好。
林燕、陈红梅老师的课有一定改进，但仍需努力，要加强教师基本功训练，虚心学习，不断提高，力争成为学校骨干教师。
篇10：作业检查记录
生字、生词、组词、综合、造句
一、值得肯定的方面：
1、作业进度与教学进度相符，生字、生词、组词完成至18课，综合、造句完成至第四单元。
2、作业要求规范统一，在抽查的作业中，可以清楚地看到教师们对学生的答题格式、书写工具、书写要求、甚至是答语的完整性等都能严格要求。
3、普遍能做到要求学生及时订正，教师及时批改，并能做到规范订正。
4、老师们对“作业批改”这一常规工作较为重视，批改时间、作业分数书写都比较规范。
二、存在问题主要有：
1、仍然有漏批漏改的现象。例如生字本中“囵”有部分学生把里面的“仑”写成“仓”；学生订正的作业；教师来不及当天批改而后又忘批改的作业等。
2、学生对批改要求不明晰。从抽查中发现了这样的现象：老师批改学生错误答案，有些学生用红笔改，有些学生用蓝笔改。
3、有些教师批改作业还不够细致，没有做到每一小题都去认真批改，而是一勾批多题的现象，这主要反映在综合本中。
三、六年级作业优秀学生名单：
六（1）班：姚雪婷、姚洁如、姚晓婵、曾玉滢、姚淑敏、陈依然、张雅茹、杨志诚、六（2）班：姚子敏、谢莲、姚依婷、罗琳、姚淑兰、姚晓铭、姚巧玲、刘佳盈、刘文威
六（3）班： 袁进、张敏、王敏、林炜楠、黄茂南、姚锐彪、杨嘉欣、翟依玲
篇11：代码检查记录
1现状及原因分析
1.1现状分析
每个项目软件需填写的软件质量保证检查记录表格数量尽管差距较大,但也有成千甚至上万个。例如,对于一个包含1~3个软件配置项的项目软件,其质量保证检查记录表格数量约为7000~15000个(注:表格数量=每类表单需填写表格数×该表单张数,且表单内一个格子不论填写多少内容,均算一格)。
实际上,软件质量保证检查记录表格中存在有较多重复填写的内容。估计这部分表格数约占全部表格总数的25%。此外,在“过程检查单”中还存在较多勾选“不适用”或“未达”等选项的检查项。估计此类检查项约占全部过程检查项的30%;再有,“过程检查单”中还存在较多重复检查项。估计此类检查项约占全部过程检查项的15%。而“过程检查单”约占全部表单的25%。据此推算,“过程检查单”中不适用/未达/重复的检查项的表格约占全部表格数量的(30%+15%)×25%=11.25%。
1.2设定目标
根据上述分析,若能解决重复填写的问题,可减少手工填写表格数约25%;若能解决不适用/未达/重复检查项较多的问题,又可减少手工填写表格数约11.25%。若两个目标都能实现的话,则可将项目软件质量保证检查记录的手工填写率平均减少约36%。为此,可将手工填写率减少36%设定为工作目标,并将要因确认标准设定为2%。
需要指出的是,工作目标和要因确认标准的设定是建立在对现状调查分析的基础上的。对于不同的项目软件,其质量保证检查记录手工填写率的减少目标和要因确认标准是有较大区别的。
1.3原因分析
为找出减少软件质量保证检查记录手工填写率的方法,特对可能产生不利影响的各方面因素进行了梳理分析,发现主要有如下几个原因:
(1)填写多余表格:可抽查每位软件质量保证人员负责的一个项目软件质量保证记录,查看填写的多余表格数量。对某个项目软件的抽查结果表明,填写的多余表格数量为8个,占总表格数量9000的0.09%,小于确认标准(2%)。
(2)存在非必要填写的表单:可组织软件同行专家依据相关标准规范的要求,从使用目的、标准符合性等方面对现有表单的必要性进行确认。对某个项目软件的确认结果表明,“不符合项报告表”表格数量占比约为15%,大于确认标准(2%)。
(3)表单中存在非必要填写内容:可组织软件同行专家依据相关标准规范要求,从使用目的、标准符合性等方面对现有表单填写内容的必要性进行确认。对某个项目软件的确认结果表明,表单中需填写的内容均为应关注的内容,表单中需填写项不宜删减,即表单中存在非必要内容的表格数为0,小于确认标准(2%)。
(4)表单中可抽查检查项提示不足:可统计软件质量保证体系文件中缺少提示的可抽查检查项数量。对某个项目软件的统计结果表明,体系文件中缺少提示的可抽查检查项共19个,占总表格数量9000的0.21%,小于确认标准(2%)。
(5)不适用/未达/重复的过程检查项过多:可通过统计分析的方法确认不适用/未达/重复的过程检查项数量。对某个项目软件的统计结果表明,项目软件过程检查单中不适用的检查项占比为4.5%,未达的检查项占比为5.1%,重复的过程检查项占比4.2%,均大于确认标准(2%)。
(6)缺少合适的项目软件质量保证工具:目前多以word文档形式存放,所有填写内容几乎均为手工录入。对某个项目软件的统计结果表明,如果使用工具可将具有逻辑关系的表格自动生成,则项目中有逻辑关系的表格总数占比为34%,大于确认标准(2%)。
综上所述,存在非必要填写的表单、不适用/未达/重复的过程检查项过多、缺少合适的项目软件质量保证工具为影响软件质量保证检查记录手工填写率的要因,约占全部影响因素项(件)的60%。
2对策措施及效果
2.1对策措施
针对上述现状及原因分析结果,可采取以下工作方法和对策措施:
(1)存在非必要填写的表单:改进工作流程,更改“不符合项报告表”的提交时机。例如,可将“不符合项报告表”的提交时机由原来的发现不符合项时提交更改为需要上报不符合项时再提交。此举可减少大量非必要表单的填写。
(2)不适用/未达/重复的过程检查项过多:优化过程审核内容,由原按过程域检查更改为按活动检查,并调整检查项。例如,可将活动过程细分,把具有前后置顺序的检查项划为一类,不具有关联关系的检查项分开,以减少检查过程中的不适用/未达/重复检查项。
(3)缺少合适的项目软件质量保证工具:改变手工填写方式。例如,可利用EXCEL等编写软件质量保证检查记录工具,将逻辑上有关联的数据利用工具进行自动关联,以大幅减少手工重复填写率。
2.2效果评估
通过采取以上针对性措施后,一方面,减少原有软件质量保证检查记录表格中存在的较多重复填写的内容;另一方面,较好地解决了软件质量保证检查记录表格中不适用/未达/重复检查项较多的问题。此举可减少软件质量保证人员重复繁琐的填写记录工作,使得软件质量保证人员能够将注意力更多地放在过程检查和产品检查中而不是填写记录中。使用工具则可以确保软件质量保证记录间协调一致。在内审过程中,审核人员也可以减少对记录一致性的检查,而将注意力集中在审核软件质量保证人员是否及时、有效地完成过程和产品检查,从而找出更深层次的问题,促使项目软件过程管理不断改进。对某个项目软件减少软件质量保证检查记录手工填写率的改进活动实践表明,上述措施最终可将项目软件质量保证检查记录的手工填写率平均减少36%以上,超过预期目标。
3结语