区块链研究实验室|减少智能合约代码复杂性并提高可维护性

在本文中，我将分享一些示例，说明消除特殊情况如何减少代码复杂性并提高可维护性。

特殊最大值

常见的特殊情况是使用0表示“无最大值”。这种特殊情况通常很容易消除。

Special Expirations看下面的代码

在这段代码中，0是一种特殊情况，表示“没有过期”。这种特殊情况是不直观的，它增加了require语句的复杂性。然而，真正的危险是团队中的一个新开发人员忽略了这个微妙之处，无法处理expiration==0的特殊情况。这很容易导致资金损失或其他严重问题。

这样代码就更简单更明显了：

这里，我使用的是uint256允许的最大值的expiration，而不是0，当涉及到时间戳时，expiration实际上是无限的。特殊最大以太币数量这是一个非常相似的示例，但这次涉及以太币：

同样，我们有一个非直观的特例，我们可以通过使用一个有效的无限值来解决这个问题：

注意，同样的技巧可以概括为令牌数量或任何值。由于Solidity不能表示大于2256-1的值，因此它始终可以与uint256进行比较，成为“有效无限”值

解决gas成本问题通常，在gas成本方面需要进行权衡。人们最终将默认值设为0的一个典型原因是存储非零值会耗费大量gas。

如果存储成本对于您的用例而言是很高的，请考虑以下技巧：

在此代码中，写入存储的_expiration值默认情况下为0，与以前的特殊含义相同。但是，我介绍了一个辅助函数expiration（），它将0转换为不太特殊的值2256-1。这意味着我的其余代码无需处理这种特殊情况。考虑将此技术与自定义的linter规则配对使用，以确保您不会在expiration（）函数之外的任何地方直接读取_expiration。

特殊地址

关于地址，我经常看到两种特殊情况：

1. 地址0通常是不允许的。

2. 不允许使用特定地址（通常是特权角色）。

特别地址0

这是一些熟悉的代码，其中使用0作为特殊情况：

禁止使用地址0通常是为了保护用户不受错误的影响。将令牌发送到地址0通常不会比将它们发送到地址1更糟糕，但0是默认值，因此更可能由于有错误的工具或库而意外传入。

我个人不喜欢这种地址0的支票，但这很少有问题。与前面的示例不同，如果开发人员在维护代码时忘记了这种特殊情况，那么一切都不会中断。

特殊角色地址

这段代码比上一段要麻烦得多：

当我看到这样的代码时，我的直接问题是为什么所有者地址无法接收令牌。这样的检查通常是为了将安全控制措施放在适当的位置，但通常无法解决Sybil攻击，因为系统中的多个地址由同一个人控制。

在这个特定的例子中，所有者可以简单地接收具有不同地址的令牌。如果这违反了合同的安全性假设，那就有问题了。

像这样的特殊情况是一种代码气息，但这并不意味着它们总是应该被消除。要做的重要事情是记录为什么需要这种特殊情况，并考虑替代方案。

总结

1. 特殊情况会导致代码复杂性，从而导致错误。

2. 在可能的情况下，完全消除特殊情况。

3. 2256-1是最大值的良好替代品。

4. 地址0的特殊情况通常可以。

5. 其他特定地址的特殊情况是代码气味。

6. 如果决定在代码中使用具有特殊意义的值，请尝试隔离用于处理这些值的代码。

—-

编译者/作者：链三丰

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。