作为开发者的你平时工作时是怎么判断并清理死代码的？也许你猜到了这篇文章要讲什么，是的，我们是有一些清理死代码的好方法推荐给你……

编译 | 弯月  责编 | 张文

出品 | CSDN（ID：CSDNnews）

对于我们团队来说，有两项工作能让我们感受到满满的成就感：清理死代码和自动化！

因此，在认真考虑了各种自动化工具之余，我们还希望能够遍历所有的代码，分析每一个 .erl 和 .hrl 文件，并输出所有可以删除和/或重构代码的候选列表。

本文介绍的这款工具 Hank 可以帮助你确定哪些是死代码。

Hank 与其他现有工具的区别

你可能想问：“为什么我要选择 Hank？这类的工作可以通过 linter 解决！”

答案是：不，Hank 与 linter 不同。

关于代码的 linting，我们使用 Elvis，它会审核我们的 Erlang 代码风格，比如函数命名、嵌套层级、每一行的长度、变量命名约定等等。

这些不属于 Hank 的工作范围。

Xref 是一种交叉引用工具，可用于查找函数、模块、应用程序以及发行版本之间的依赖关系。它会分析函数的定义和函数的调用，并警告我们源代码中已定义、但从未使用过的函数。

这些也不属于 Hank 的工作范围。

那么 Dialyzer 呢？Dialyzer 是一种静态分析工具，可识别软件差异，例如成功类型的错误，以及由于编程错误而变得无效或无法访问的代码，以及不必要的测试等。它的分析基于的是成功类型的概念。

Hank 不依赖于规范，也不评估函数参数/返回中的“语义”。

Hank 的功能

那么，Hank 究竟有哪些功能？Hank 会检测并警告你代码库中可以被删除，或者可以根据规则重构的代码。

它适用于整个项目（与 Elvis 不同，后者只能处理单个文件），源代码（与 Xref 不同，后者只能处理已编译的代码），以及单个项目（与 Dialyzer 不同，后者将分析整个系统，包括 OTP 以及依赖项）。

如何使用 rebar3_hank

你只需要将下列代码添加到rebar.config（项目或全局的~/.config/rebar3/rebar.config）：

{plugins, [rebar3_hank]}.

然后运行：

rebar3 hank

接下来就是见证奇迹的时刻！

跳过规则

在某些情况下，你可能需要跳过某些规则，比如正在开发的库，你可以在其中定义供其他使用的 hrl 或模块。在这种情况下，你可能需要忽略一些规则（例如single_use_hrl_attributes）。使用 Xref 也会发生类似的情况。

为此，hank 可以忽略模块级别的规则：

% ignoring all the rules for this module
-hank ignore% or ignoring specific rules
-hank [single_use_hrl_attributes]

或者，在 rebar.config 中添加以下配置：

{hank, [{ignore, [{"test/*.erl", unused_ignored_function_params}
]}]}.

规则

以下是我们创建好的规则，你可以直接在 Hank 中使用。

unused_ignored_function_params

随着函数的不断发展，以前的某些参数可能已不再使用了。最简单的解决方案可能就是忽略它们，然后忘掉这个问题。

Hank 会检测出所有函数中被忽略的参数，并告知你可以删除这些参数，并重构函数的调用，这样就可以让代码更加简洁。

例如，在分析这个模块时……

-module(my_module).-export([external_fun/1]).external_fun(X) ->multi_fun(X,rand:uniform(), undefined).%% A multi-clause function with unused 3rd param
multi_fun(undefined, _, _) ->ok;
multi_fun(Arg1, Arg2, _Arg3) when is_binary(Arg1) ->Arg2;
multi_fun(Arg1, _, _) ->Arg1.

Hank 的输出结果为：

$ rebar3 hank
===> Looking for code to kill with fire...
===> The following pieces of code are dead and should beremoved:
src/my_module.erl:9: Param #3 is not used at 'multi_fun/3'

为了避免这种警告，你可以删除未使用的参数。

single_use_hrls

有时，你会将一些代码放入应该在多个模块之间共享的头文件中，但最终你只编写了一个使用该头文件的模块。在这种情况下，最好将头文件的内容直接放入模块内。Hank 有这样的一个规则！

假设有一个文件 header.hrl：

-define(APP_HEADER, "this is a header from an app that willbe used in just one module").
-define(SOME_MACRO(A), A).-module(app_include_lib).-include("header.hrl").-export([my_function/0]).my_function() ->% those are only usedhere!?SOME_MACRO(?APP_HEADER).

Hank 的输出结果为：

$ rebar3 hank
===> Looking for code to kill with fire...
===> The following pieces of code are dead and should beremoved:
header.hrl:0: This header file is only included at:src/app_include_lib.erl

将这个 hrl 文件的内容直接放入使用该文件的模块中，就不会再看到这则警告了。

single_use_hrl_attrs

有时，情况会更微妙。有时，整个文件并非仅在一个模块中使用，可能在许多模块之间共享。但是某些属性并非如此，例如宏或记录，它们在头文件中定义，但仅在单个模块中使用。Hank 有一条规则，建议你将这些属性放在模块内，以减少不必要的共享内容。

对于上述文件，假设 hrl 包含在另一个文件中：

-module(app_include_lib_2).-include("header.hrl").

Hank 的输出结果为：

$ rebar3 hank
===> Looking for code to kill with fire...
===> The following pieces of code are dead and should beremoved:
include/header.hrl:2: ?SOME_MACRO/1 is used only at src/app_include_lib.erl

unused_hrls

有时，情况会更加恶劣，有的 hrl 文件可能没有包含在任何模块中。Hank 会检测到它们，并告知你可以将其完全删除，因为实际上它们没有任何作用。

添加一个未包含在任何模块中的 header_2.hrl 文件，Hank 的输出结果为：

$ rebar3 hank
===> Looking for code to kill with fire...
===> The following pieces of code are dead and should beremoved:
include/header_2.hrl:0: This file is unused

unused_macros

Hank 还有一条规则，它将检测项目中未使用的宏。这些宏可能定义在了源代码中的任何文件中，但是从未使用。因此，这些宏都是没有必要的，可以删除。

unused_record_fields

这个规则很重要。根据这个规则，Hank 会发现某些记录声明带有字段定义（甚至为它们提供默认值），但从未使用过。Hank 认为访问或写入记录字段就是在使用它。

你可以通过这个警告，删除记录中未使用的字段，从而减小记录的大小。

可扩展性

我们非常注重该项目的可扩展性，任何人都可以通过实现 hank_rule 的行为来编写自己的项目规则。

但是，如果你觉得新规则具有广泛适用性的话，可以贡献到 rebar3_hank 的 GitHub 社区！你可以查看未解决的议题，并随时创建新的议题！

测试 Hank 的威力

为了让你了解 Hank 的功能，我们决定在一个很大的代码库中对其进行测试。

我们决定尝试使用 Erlang / OTP。由于这个项目主要由各种库组成，因此我们必须限制应用哪些规则，以免产生一些虚假的结果。我们使用了以下配置：

{hank, [{ignore,["**/test/**"]}, %% Just "production" code, no tests{rules, [unused_ignored_function_params,unused_hrls,unused_macros,unused_record_fields]}
]}.

我们知道会找到大量警告，但是最终的结果还是超出了预期。Hank 找到了 OTP 生产代码中的 4000 多条死代码。

虽说并不是所有收到警告的代码都应该被删除，但是通过这个例子，你也看出了 Hank 的威力。以下是 Hank 输出的警告……

记录中未使用的字段

Hank 找到了 130 多个包含未使用字段的记录，例如 erl_tidy 或 remote_logger。

未使用的宏

Hank 在 OTP 中发现了 1000 多个未使用的宏，其中大多数出现在 megaco 应用程序的大型模块中，还有一些出现在其他宏中，比如 xmerl_uri。

未使用的参数

Hank 还发现了 2000 多个函数带有未使用的参数。其实有些不是真正的错误，但有些值得仔细检查。比如这个例子（https://github.com/erlang/otp/blob/6378a0c825db64df91e01ee39e3a268f4ba050b7/lib/inets/src/http_lib/http_uri.erl#L257-L266），该参数从未使用过第一个参数。（转自CSDN）

参考链接：https://tech.nextroll.com/blog/dev/2021/01/06/erlang-rebar3-hank.html

1.国产替代摸不着门儿？快来回看兆易创新直播课！

2.开源的RISC-V能否成为中国“缺芯”的解药？

3.树莓派Pico：仅4美元的MCU

4.MCU支持AI功能的多种原因~

5.2020年，我学习到的20条软件工程准则~

6.状态机思路在嵌入式开发中的应用~

免责声明：本文系网络转载，版权归原作者所有。如涉及作品版权问题，请与我们联系，我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。