在本文中,我将分享一些示例,说明消除特殊情况如何减少代码复杂性并提高可维护性。
特殊最大值
常见的特殊情况是使用0表示“无最大值”。这种特殊情况通常很容易消除。
Special Expirations
看下面的代码👇
在这段代码中,0是一种特殊情况,表示“没有过期”。这种特殊情况是不直观的,它增加了require语句的复杂性。
然而,真正的危险是团队中的一个新开发人员忽略了这个微妙之处,无法处理expiration==0的特殊情况。这很容易导致资金损失或其他严重问题。
这样代码就更简单更明显了:
这里,我使用的是uint256允许的最大值的expiration,而不是0,当涉及到时间戳时,expiration实际上是无限的。
特殊最大以太币数量
这是一个非常相似的示例,但这次涉及以太币:
同样,我们有一个非直观的特例,我们可以通过使用一个有效的无限值来解决这个问题:
2256-1是最大值
注意,同样的技巧可以概括为令牌数量或任何值。由于Solidity不能表示大于2256-1的值,因此它始终可以与uint256进行比较,成为“有效无限”值
解决gas成本问题
通常,在gas成本方面需要进行权衡。人们最终将默认值设为0的一个典型原因是存储非零值会耗费大量gas。
如果存储成本对于您的用例而言是很高的,请考虑以下技巧:
在此代码中,写入存储的_expiration值默认情况下为0,与以前的特殊含义相同。但是,我介绍了一个辅助函数expiration(),它将0转换为不太特殊的值2256-1。这意味着我的其余代码无需处理这种特殊情况。
考虑将此技术与自定义的linter规则配对使用,以确保您不会在expiration()函数之外的任何地方直接读取_expiration。
特殊地址
关于地址,我经常看到两种特殊情况:
-
地址0通常是不允许的。
-
不允许使用特定地址(通常是特权角色)。
特别地址0
这是一些熟悉的代码,其中使用0作为特殊情况:
禁止使用地址0通常是为了保护用户不受错误的影响。将令牌发送到地址0通常不会比将它们发送到地址1更糟糕,但0是默认值,因此更可能由于有错误的工具或库而意外传入。
我个人不喜欢这种地址0的支票,但这很少有问题。与前面的示例不同,如果开发人员在维护代码时忘记了这种特殊情况,那么一切都不会中断。
特殊角色地址
这段代码比上一段要麻烦得多:
当我看到这样的代码时,我的直接问题是为什么所有者地址无法接收令牌。这样的检查通常是为了将安全控制措施放在适当的位置,但通常无法解决Sybil攻击,因为系统中的多个地址由同一个人控制。
在这个特定的例子中,所有者可以简单地接收具有不同地址的令牌。如果这违反了合同的安全性假设,那就有问题了。
像这样的特殊情况是一种代码气息,但这并不意味着它们总是应该被消除。要做的重要事情是记录为什么需要这种特殊情况,并考虑替代方案。
总结
-
特殊情况会导致代码复杂性,从而导致错误。
-
在可能的情况下,完全消除特殊情况。
-
2256-1是最大值的良好替代品。
-
地址0的特殊情况通常可以。
-
其他特定地址的特殊情况是代码气味。
-
如果决定在代码中使用具有特殊意义的值,请尝试隔离用于处理这些值的代码。