关于清理「死代码」,我有一些好方法推荐给你

百家 作者:CSDN 2021-01-27 09:08:57

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


编译 | 弯月  责编 | 张文
出品 | 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 parammulti_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),该参数从未使用过第一个参数。
参考链接:https://tech.nextroll.com/blog/dev/2021/01/06/erlang-rebar3-hank.html

程序员如何避免陷入“内卷”、选择什么技术最有前景,中国开发者现状与技术趋势究竟是什么样?快来参与「2020 中国开发者大调查」,更有丰富奖品送不停!


我们差点就用不上 Java 了!

印度永久封禁了微信、百度、TikTok 等 59 款中国 App……

RISC-V 正在成为芯片世界中的 Linux

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接