圣诞大减价开始了!

介绍断言

问题

为了使一部分代码正确工作,某些条件或值必须为真。

解决方案

用特定的断言检查替换这些假设。

之前
double getExpenseLimit(){//应该有费用限制或//一个主要项目。return (expenseLimit != NULL_EXPENSE) ?expenseLimit: primaryProject.getMemberExpenseLimit();}
double getExpenseLimit(){断言。isTrue(expenseLimit != NULL_EXPENSE || primaryProject != null);return (expenseLimit != NULL_EXPENSE) ?expenseLimit: primaryProject.getMemberExpenseLimit ();}
之前
double GetExpenseLimit(){//应该有费用限制或//一个主要项目。return (expenseLimit != NULL_EXPENSE) ?expenseLimit: primaryProject.GetMemberExpenseLimit();}
double GetExpenseLimit(){断言。IsTrue(expenseLimit != NULL_EXPENSE || primaryProject != null);return (expenseLimit != NULL_EXPENSE) ?expenseLimit: primaryProject.GetMemberExpenseLimit ();}
之前
function getExpenseLimit(){//应该有费用限制或//一个主要项目。return ($this->expenseLimit !== NULL_EXPENSE) ?$ this - > expenseLimit: $ this - > primaryProject - > getMemberExpenseLimit ();}
函数getExpenseLimit() {assert($this->expenseLimit !== NULL_EXPENSE || isset($this->primaryProject));return ($this->expenseLimit !== NULL_EXPENSE) ?$ this - > expenseLimit: $ this - > primaryProject - > getMemberExpenseLimit ();}
之前
def getExpenseLimit(self): #应该有费用限制或#一个主要项目。回归自我。expenseLimit if self。= NULL_EXPENSE else \ self.primaryProject.getMemberExpenseLimit()
def getExpenseLimit(self): assert (self.)expenseLimit != NULL_EXPENSE)或(self。primaryProject != None)返回self。expenseLimit if (self。= NULL_EXPENSE) else \ self.primaryProject.getMemberExpenseLimit()
之前
getExpenseLimit(): number{//应该有费用限制或//一个主要项目。return (expenseLimit != NULL_EXPENSE) ?expenseLimit: primaryProject.getMemberExpenseLimit ();}
getExpenseLimit(): number {// TypeScript和JS没有内置断言,所以我们将使用//旧的console.error()。您总是可以将其提取到//指定的断言函数中。如果(!(expenseLimit != NULL_EXPENSE || (typeof primaryProject !== 'undefined' && primaryProject))){控制台。错误("断言失败:getExpenseLimit()");} return (expenseLimit != NULL_EXPENSE) ?expenseLimit: primaryProject.getMemberExpenseLimit ();}

为什么重构

假设代码的一部分假设了一些东西,例如,一个对象的当前状态或一个参数或局部变量的值。通常这个假设总是成立的,除非发生错误。

通过添加相应的断言,使这些假设显而易见。与方法参数中的类型提示一样,这些断言可以作为代码的实时文档。

作为查看代码何处需要断言的指导原则,请检查描述特定方法工作条件的注释。

好处

  • 如果假设不正确,代码因此给出了错误的结果,最好在导致致命后果和数据损坏之前停止执行。这也意味着您在设计执行程序测试的方法时忽略了编写必要的测试。

缺点

  • 有时异常比简单的断言更合适。您可以选择异常的必要类,并让其余代码正确地处理它。

  • 什么时候异常比简单的断言更好?如果异常可能是由用户或系统的操作引起的,您可以处理该异常。另一方面,普通的未命名和未处理的异常基本上等同于简单的断言——您不处理它们,它们是由不应该发生的程序错误导致的。

如何重构

当您看到假设了一个条件时,为这个条件添加一个断言以确保。

添加断言不应该改变程序的行为。

不要过度使用for断言一切在你的代码中。只检查代码正确运行所必需的条件。如果即使某个断言为假,代码也能正常工作,则可以安全地删除该断言。

Baidu
map