为什么要界定源代码数量

代码审计是一种评估软件代码质量、安全性和合规性的过程。在进行代码审计之前，先界定源代码的数量有以下几个原因：

1. 审计范围的确定：了解源代码的规模可以帮助审计团队确定审计的范围和深度，从而制定合理的审计计划。

2. 资源分配：源代码的数量直接影响到审计所需的时间和人力资源。大量的代码可能需要更多的时间来完成审计，因此需要合理分配审计资源。

3. 风险评估：源代码的规模可以作为评估项目风险的一个因素。通常，代码量越大，潜在的漏洞和问题可能越多。

4. 审计成本估算：了解源代码的数量有助于估算审计的成本。审计服务提供者可以根据代码量来报价。

5. 审计方法选择：不同的代码量可能需要采用不同的审计方法。例如，对于较小的项目，可能可以进行手动审计；而对于较大的项目，则可能需要自动化工具来辅助审计。

6. 审计时间估计：代码量的大小可以帮助审计团队估计完成审计所需的时间，从而为项目制定合理的时间表。

7. 审计报告的详细程度：源代码的数量也会影响审计报告的详细程度。对于较小的代码库，可能可以提供更详细的审计报告；而对于较大的代码库，则可能需要更概括的报告。

8. 合规性要求：在某些情况下，审计的深度和范围可能受到合规性要求的限制，源代码的数量可以帮助确定是否满足这些要求。

通过界定源代码的数量，审计团队可以更有效地规划审计过程，确保审计的质量和效率。

在我们进行审计之前应当首先了解以下内容
Stats

Use something like solidity metrics or cloc to get these.

nSLOC: XX
Complexity Score: XX
Security Review Timeline: Date -> Date

其中nSLOC，源代码的数量，下面的 Complexity Score有多种评估方式，一般而言，我们可以根据源代码数量进行评估，从而根据自己和团队的能力确定审计的日期Security Review Timeline: Date -> Date

代码难度的界定

对于 Complexity Score也有许多的方式界定：
复杂度分数（Complexity Score）是衡量代码复杂性的一个指标，它通常反映了代码的可读性、可维护性和潜在的错误风险。不同的编程语言和工具可能会使用不同的方法来计算复杂度分数。以下是一些常见的计算复杂度的方法：

1. Cyclomatic Complexity（圈复杂度）:

   • 由Thomas J. McCabe在1976年提出。
   • 计算方法：E - N + 2P，其中E是程序中边的数量，N是节点的数量，P是连接组件的数量。
   • 圈复杂度较高的模块可能需要更多的测试来确保其正确性。

2. Halstead Complexity Measures（Halstead复杂度度量）:

   • 由Maurice Halstead在1977年提出。
   • 包括多个度量，如程序长度（程序中操作符和操作数的总数）、体积（程序中不同操作符和操作数的数量）、难度（程序中不同操作符和操作数的比率）、估算工作量等。

3. Maintainability Index（可维护性指数）:

   • 考虑代码的圈复杂度、代码行数和注释比例。
   • 可维护性指数越高，代码的可维护性越好。

4. Essential Complexity（本质复杂度）:

   • 指的是即使最高效的算法也无法减少的复杂度。

5. Logical Complexity（逻辑复杂度）:

   • 考虑程序中逻辑结构的复杂性，如条件语句、循环等。

6. Modularity（模块化）:

   • 衡量代码的模块化程度，模块化程度越高，复杂度可能越低。

7. Depth of Inheritance（继承深度）:

   • 对于面向对象的语言，继承层次的深度可以影响复杂度。

8. Coupling and Cohesion（耦合和内聚）:

   • 耦合度衡量模块之间的相互依赖程度，内聚度衡量模块内部元素的关联程度。

9. Lines of Code（代码行数）:

   • 简单的行数统计，虽然不是直接的复杂度度量，但通常与复杂度相关。

10. Static Analysis Tools（静态分析工具）:

    • 使用自动化工具来检测代码中的潜在复杂性问题。

不同的工具和方法可能会结合上述一种或多种度量来计算复杂度分数。例如，一些工具可能会使用一个加权公式，将圈复杂度、代码行数、注释比例等因素结合起来，以提供一个综合的复杂度评分。

要计算复杂度分数，你通常需要使用专门的代码分析工具，这些工具可以自动计算上述度量，并给出一个综合评分。例如，对于Java代码，可以使用Checkstyle、PMD或SonarQube等工具；对于C/C++代码，可以使用Cppcheck或Clang Static Analyzer等。对于Solidity智能合约，可以使用Solidity Metrics等工具。

colc 的安装与使用

访问github官网
https://github.com/AlDanial/cloc
cloc
如果链接失效就在github搜索cloc
推荐选择Install via package manager下载
这样你会看到多种安装方式，我选择

npm install -g cloc

进入项目目录中，输入

cloc file

这里的file是你想要界定源代码数量的审计文件夹的路径
举例，我的审计文件位于./src/

cloc ./src/1 text file.1 unique file.                              0 files ignored.github.com/AlDanial/cloc v 2.02  T=0.03 s (32.7 files/s, 1342.7 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Solidity                         1              6             15             20
-------------------------------------------------------------------------------

我们可以看到
根据 cloc 命令输出结果，我们可以分析如下：

1. 文件统计:

   • 总共有1个文本文件被统计。

2. 文件唯一性:

   • 有1个独特的文件，意味着没有重复的文件被计算。

3. 忽略文件:

   • 没有文件被忽略。

4. 版本和执行时间:

   • 使用的 cloc 版本是 2.02。
   • 执行时间是 0.03 秒，这表明分析速度很快。

5. 文件处理速度:

   • 在这次分析中，cloc 处理了32.7个文件每秒，1342.7行代码每秒。

6. 语言统计:

   • 统计结果显示，有一个文件是用 Solidity 语言编写的。

7. 代码行数细分:

   • 在这个 Solidity 文件中：
     • 空白行（不包含代码的行）数量为 6 行。
     • 注释行（以 // 或 /* */ 开始的行）数量为 15 行。
     • 实际的代码行数（不包括空白和注释）为 20 行。

这个输出结果提供了一个快速的概览，让你知道在 ./src/ 目录下有一个 Solidity 文件，以及这个文件的代码、注释和空白行的分布情况。这对于评估代码规模和进行初步的代码审查非常有用。

solidity Metrics

这个工具位于vscode 拓展当中，当我们下载之后，可以选择，文件点击鼠标右键，便可以看到solidity Metrics
若有人的电脑没有拓展或者是无法安装和加载，这里给出一种万能解决方法

我们直接使用node全局下载

npm install -g solidity-code-metrics

之后我们使用命令

solidity-code-metrics myfile.sol > metrics.md
solidity-code-metrics myfile.sol --html > metrics.html`

将myfile.sol 更换成你需要的文件，这里可以得到许多的提示

Type	File	Logic Contracts	Interfaces	Lines	nLines	nSLOC	Comment Lines	Complex. Score	Capabilities
📝	/home/zqy/foundry/3-passwordstore-audit/src/PasswordStore.sol	1	****	41	41	20	15	10	****
📝	Totals	1	****	41	41	20	15	10	****

可以清晰的看法到

nSLOC: 20
Complexity Score: 10

有不懂的欢迎联系我