c语言静态代码分析工具_C ++的静态分析工具

本文介绍了C++的静态代码分析工具,旨在帮助开发者遵循最佳实践,解决C++语言复杂性带来的问题。作者在开发Robust Services Core (RSC)时面临代码维护挑战,决定创建一个工具来自动化代码检查。该工具不仅清理#include指令,还作为Scott Meyers代码检查器,通过编辑源代码来实现其建议。虽然目前只支持C++11的子集,但用户可以根据需要扩展其功能。
摘要由CSDN通过智能技术生成

c语言静态代码分析工具

介绍 (Introduction)

C++ is a large language—too large, some would argue. Because it's a superset of C, it's easy for developers with a C background to build a hybrid OO/non-OO system. C++ also kept the preprocessor, which is sometimes used in what can only be described as despicable ways. And rather than risk offending legacy systems, the C++ standards committee seems very reluctant to deprecate anything—but not at all reluctant to keep adding what seems like one pedantic feature after another, at least to those of us struggling to keep up.

C ++是一种大型语言,有些人会认为它太大了。 因为它是C的超集,所以具有C背景的开发人员很容易构建混合OO /非OO系统。 C ++还保留了预处理器,该预处理器有时只能以卑鄙的方式使用。 C ++标准委员会似乎并不愿意弃用任何东西,而不是冒犯旧系统的风险,但一点也不舍不得继续添加似乎又一个脚的功能,至少对于我们努力跟上的那些人。

As a result of all this, there are often many ways to do something in C++, and figuring out which way is best can be difficult. Without guidance, it can only be learned through torturous experience. It is therefore unsurprising that there are many books about C++ best practices, such as Scott Meyers' Effective C++. But it's easy to forget their recommendations when you're immersed in coding, especially when new to the language. Of course, some developers don't even bother to read such books, being of the "If it works, it's correct—so don't touch it!" school. Having a tool that could serve as an automated Scott Meyers code inspector would go a long way to addressing these issues.

所有这些的结果是,通常有很多方法可以在C ++中执行某项操作,而找出哪种方法最好则很困难。 没有指导,就只能通过痛苦的经历来学习。 因此,毫不奇怪的是,有许多关于C ++最佳实践的书籍,例如Scott Meyers的Effective C ++ 。 但是,当您沉迷于编码时,尤其是对语言不熟悉时,很容易忘记他们的建议。 当然,有些开发人员甚至不费心去读这些书,因为“如果它能奏效,那是正确的 -所以不要碰它!” 学校。 拥有可以充当自动Scott Meyers代码检查器的工具,对于解决这些问题将大有帮助。

背景 (Background)

When I started to develop the Robust Services Core (RSC), I had a reasonable knowledge of C++ but was far from proficient. The code grew very organically and was continually refactored. As I became more familiar with C++ and needed to revisit areas of the code that had lain dormant for a while, I kept finding things that I would now do differently. But there was always more code to develop and never enough time to do a tedious code inspection to find and "fix" all the things that could be improved.

当我开始开发健壮的服务核心 (RSC)时,我对C ++有一定的了解,但还远远不够熟练。 该代码非常有机地增长,并不断进行重构。 随着我对C ++的更加熟悉并需要重新研究一段时间以来处于Hibernate状态的代码区域,我一直在寻找可以做不同的事情。 但是总是有更多的代码要开发,而没有足够的时间进行繁琐的代码检查来查找和“修复”所有可以改进的地方。

Eventually I decided that, at the very least, it would be nice to clean up all the #include directives. Surely there was a publicly available tool for this. This was circa 2013, and the only thing I found was a Google initiative called "Include What You Use", which appeared to have been mothballed.1 I therefore decided to write such a tool as a diversion from the main focus of RSC.

最终,我决定,至少清理所有#include指令会很好。 当然,有一个公开可用的工具。 大约在 2013年,我发现的唯一发现是一项名为“包括您所使用的内容”的Google计划,该计划似乎已被封存。 1我因此决定写这样的工具从RSC的主要焦点的转移。

Some diversion! It soon became apparent that fixing #include lists, to add the directives that should be there and remove those that shouldn't, meant writing a parser. And not just a parser, but something closer to a compiler, because it would also have to do name resolution and other things. Another option was to take an open-source C++ compiler and either modify it or extract the necessary information from files that it might produce.

一些转移! 很快就发现,修复#include列表,以添加应该存在的指令并删除不应该存在的指令,意味着编写了解析器。 不仅是解析器,还有更接近编译器的东西,因为它还必须进行名称解析和其他操作。 另一种选择是采用开源C ++编译器并对其进行修改或从其可能产生的文件中提取必要的信息。

Rather than give up, I decided to try writing the tool from scratch. It would be a learning experience, even if the attempt ultimately had to be abandoned. This article describes the current state of the code that emerged.

我没有放弃,而是决定从头开始编写该工具。 即使最终不得不放弃尝试,这也是一次学习经历。 本文介绍了出现的代码的当前状态。

使用代码 (Using the Code)

Not only does the code clean up #include directives, it serves as an automated Scott Meyers code inspector that can implement some of its recommendations by suitably editing the source code. Its main drawback is that it only supports the subset of C++11 that RSC uses. Although this is a reasonable subset of the language, what's missing will hamper its usefulness to projects that use unsupported language features. Adding one of these missing language features can be anywhere from moderately easy to quite challenging. Nonetheless, feel free to request that a specific language feature be supported—or even volunteer to implement it! This will make the tool useful to a wider range of projects.

该代码不仅可以清除#include指令,还可以用作自动化的Scott Meyers代码检查器,可以通过适当地编辑源代码来实现其一些建议。 它的主要缺点是它仅支持RSC使用的C ++ 11的子集。 尽管这是该语言的合理子集,但是缺少的语言会妨碍其对使用不受支持的语言功能的项目的有用性。 添加这些缺少的语言功能之一,从轻而易举到极具挑战性的任何地方都可以。 但是,请随时请求支持特定的语言功能,甚至自愿实施! 这将使该工具对更广泛的项目有用。

Unlike previous articles that I've written, this one focuses more on how to use the code, and not much on how it works. However, it will provide a high-level overview of the design as a roadmap for those who want to dig into the code.

与我之前写过的文章不同,本篇文章更多地关注如何使用代码,而不是如何工作。 但是,它将为那些想要深入研究代码的人提供设计的高级概述,作为路线图。

演练 (Walkthroughs)

定义图书馆 (Defining the Library)

Before the tool can be used, the files that make up the code base must be defined. This can be done right after RSC starts by entering the command >read buildlib from the CLI. That ">" is RSC's CLI prompt and is not entered, but this article uses it to denote a CLI command. A dump of all CLI commands is available in help.cli2; scroll down to somewhere around line 1246, to "ct>help full", to see those in the ct directory, which is where the tool is implemented.

在使用该工具之前,必须先定义组成代码库的文件。 可以在RSC启动后立即执行此操作,方法是从CLI输入命令>read buildlib 。 “ > ”是RSC的CLI提示符,没有输入,但是本文使用它来表示CLI命令。 help.cli 2中提供了所有CLI命令的转储。 向下滚动到第1246行附近的某个位置,以“ ct>help full ”,以查看ct目录(该工具的实现位置)中的内容。

What >read buildlib does is execute the script buildlib, which contains a sequence of CLI commands. This results in the execution of the following commands, which are copied from the console transcript file that RSC generates, with commands not relevant to this article removed:

>read buildlib作用是执行脚本buildlib ,该脚本包含一系列CLI命令。 这将导致执行以下命令,这些命令从RSC生成的控制台脚本文件中复制,并删除了与本文无关的命令:

nb>read buildlib
nb>ct
ct>read lib.create
ct>import subs "subs"
ct>import nbase "nb"
ct>import ntool "nt"
ct>import ctool "ct"
ct>import nwork "nw"
ct>import sbase "sb"
ct>import stool "st"
ct>import mbase "mb"
ct>import cbase "cb"
ct>import pbase "pb"
ct>import onode "on"
ct>import cnode "cn"
ct>import rnode "rn"
ct>import snode "sn"
ct>import anode "an"
ct>import diplo "dip"
ct>import rsc   "rsc"

The tool is in the ct directory, so the command >ct is used to access the CLI commands in that directory. The script lib.create is then read. It contains a series of >import commands that add, to the code library, all of the directories that are needed to compile the project (RSC, in this case). For example, the command

该工具位于ct目录中,因此命令>ct用于访问该目录中的CLI命令。 然后读取脚本lib.create 。 它包含一系列>import命令,这些命令将所有编译项目所需的目录(在本例中为RSC)添加到代码库中。 例如,命令

ct>import ctool "ct"

imports the code in the ct directory, which can subsequently be referred to as ctool in other CLI commands. The path to this directory is relative to the SourcePath configuration parameter. When RSC starts up, it obtains its configuration parameters from the file element.config. So to use the tools on your own code, you need to

导入ct目录中的代码,该代码随后可在其他CLI命令中称为ctool 。 该目录的路径是相对于SourcePath配置参数的。 当RSC启动时,它从文件element.config获得其配置参数。 因此,要在自己的代码上使用这些工具,您需要

  • Modify element.config by setting its SourcePath entry to a directory that subtends all of your project's code files.

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值