最喜欢的（聪明的）防御性编程最佳实践

如果您必须选择最喜欢的（聪明的）技术进行防御性编码，它们将是什么？尽管我当前使用的语言是Java和Objective-C（具有C ++背景），但是可以使用任何语言进行回答。除了我们这里70％以上的人已经知道的防御技术外，这里还将重点介绍巧妙的防御技术。因此，现在该深入了解您的绝招了。

换句话说，除了这个无趣的示例，请尝试思考其他问题：

• if(5 == x) 代替 if(x == 5)：避免意外分配

以下是一些有趣的最佳防御性编程实践的示例（特定于语言的示例在Java中）：

-锁定变量，直到您知道需要更改它们为止

也就是说，您可以声明所有变量，final直到知道需要进行更改为止，此时可以删除final。一个普遍未知的事实是，这对于方法参数也有效：

public void foo(final int arg) { /* Stuff Here */ }

-发生不良情况时，请留下大量证据

发生异常时，您可以执行许多操作：显然，将其记录下来并执行一些清理工作只是其中的一部分。但是您也可以留下一些证据（例如，在调试器中将变量设置为“ UNABLE TO LOAD FILE”或99999等哨兵值将很有用，以防您碰巧遇到异常catch-block）。

-关于一致性：细节决定成败

与您正在使用的其他库保持一致。例如，在Java中，如果要创建一种提取一系列值的方法，则将下限包括在内，将上限值排除在外。这将使其与String.substring(start, end)以相同方式运行的方法保持一致。在Sun JDK中，您会发现所有这些类型的方法都具有这种行为，因为它会进行各种操作，包括与数组一致的元素迭代，其中索引的范围是从零（包括）到数组的长度（不包括）。

那么，您最喜欢的防御方法是什么？

更新：如果您还没有的话，请随时鸣叫。在选择正式答案之前，我有机会获得更多回应。

在c ++中，我曾经喜欢重新定义new，因此它提供了一些额外的内存来捕获篱笆张贴错误。

目前，我更喜欢避免防御性编程，而倾向于测试驱动开发。如果您在外部快速地捕获错误，则无需通过防御性操作使代码混乱，您的代码会变干，并且最终可以减少需要防御的错误。

正如WikiKnowledge所写：

避免防御性编程，而要快速失败。

通过防御性编程，我的意思是习惯于编写尝试补偿数据中某些故障的代码，编写假定调用者可能提供的数据不符合调用者与子例程之间的约定并且子例程必须以某种方式应对的代码用它。

的SQL

当我必须删除数据时，我写

select *    
--delete    
From mytable    
Where ...

当我运行它时，我会知道我是否忘记或破坏了where子句。我很安全。如果一切正常，我将突出显示“-”注释标记后的所有内容并运行它。

编辑：如果我要删除大量数据，我将使用count（*）而不是*

在应用程序启动时分配合理的内存块-我认为Steve McConnell 在Code Complete 中将其称为内存降落伞。

如果发生严重问题并且需要您终止，则可以使用此方法。

预先分配此内存为您提供了一个安全网，因为您可以释放它，然后使用可用的内存来执行以下操作：

• 保存所有持久数据
• 关闭所有适当的文件
• 将错误消息写入日志文件
• 向用户提出有意义的错误

在每个没有默认大小写的switch语句中，我添加了一个大小写，该错误使程序中止并显示一条错误消息。

#define INVALID_SWITCH_VALUE 0

switch (x) {
case 1:
  // ...
  break;
case 2:
  // ...
  break;
case 3:
  // ...
  break;
default:
  assert(INVALID_SWITCH_VALUE);
}

处理枚举（C＃）的各种状态时：

enum AccountType
{
    Savings,
    Checking,
    MoneyMarket
}

然后，在一些常规程序中...

switch (accountType)
{
    case AccountType.Checking:
        // do something

    case AccountType.Savings:
        // do something else

    case AccountType.MoneyMarket:
        // do some other thing

    default:
-->     Debug.Fail("Invalid account type.");
}

在某个时候，我将向该枚举添加另一个帐户类型。当我这样做时，我会忘记修复此switch语句。因此，Debug.Fail崩溃令人震惊（在“调试”模式下），以引起我对这一事实的注意。当我添加时case AccountType.MyNewAccountType:，可怕的崩溃停止了……直到我添加另一种帐户类型，然后忘记在此处更新案例。

（是的，这里的多态性可能更好，但这只是我脑海中的一个例子。）

用字符串输出错误消息时（尤其是取决于用户输入的错误消息），我总是使用单引号''。例如：

FILE *fp = fopen(filename, "r");
if(fp == NULL) {
    fprintf(stderr, "ERROR: Could not open file %s\n", filename);
    return false;
}

缺少引号%s真的很不好，因为说filename是一个空字符串或只是空格或其他东西。打印出来的消息当然是：

ERROR: Could not open file

因此，总是最好这样做：

fprintf(stderr, "ERROR: Could not open file '%s'\n", filename);

然后，至少用户会看到以下内容：

ERROR: Could not open file ''

我发现这在最终用户提交的错误报告的质量方面有很大的不同。如果有这样一个有趣的错误消息而不是通用的发音，则他们更有可能复制/粘贴该消息，而不仅仅是写“它不会打开我的文件”。

SQL安全

在编写将修改数据的任何SQL之前，我将整个内容包装在回滚的事务中：

BEGIN TRANSACTION
-- LOTS OF SCARY SQL HERE LIKE
-- DELETE FROM ORDER INNER JOIN SUBSCRIBER ON ORDER.SUBSCRIBER_ID = SUBSCRIBER.ID
ROLLBACK TRANSACTION

这样可以防止您永久执行错误的删除/更新。而且，您可以执行整个操作并验证合理的记录计数，或者SELECT在SQL和之间添加语句ROLLBACK TRANSACTION以确保一切正常。

当您完全确定它可以达到预期的效果时，请更改ROLLBACK为COMMIT并真正运行。

对于所有语言：

缩小变量范围到最小可能的要求。只是提供了将它们带入下一个语句的Eschew变量。不存在的变量是您不需要了解的变量，因此您不承担任何责任。出于相同的原因，请尽可能使用Lambda。

如有疑问，请轰炸该应用程序！

在每种方法的开头检查每个参数（无论是自己明确编码还是在这里使用基于合同的编程都无关紧要），并在有任何先决条件的情况下使用正确的异常和/或有意义的错误消息进行轰炸没见过。

我们在编写代码时都知道这些隐式先决条件，但是，如果未明确检查它们，则当以后出现问题时，我们将为自己创建迷宫，并且数十个方法调用堆栈将症状的发生和实际位置分开不满足前提条件的地方（=问题/错误实际上在哪里）。

在Java中（尤其是对于集合），请使用API​​，因此，如果您的方法返回List类型（例如），请尝试以下操作：

public List<T> getList() {
    return Collections.unmodifiableList(list);
}

不允许任何不必要的事情逃避您的课堂！

在Perl中，每个人都

use warnings;

我喜欢

use warnings FATAL => 'all';

这将导致代码因任何编译器/运行时警告而死亡。这在捕获未初始化的字符串时最有用。

use warnings FATAL => 'all';
...
my $string = getStringVal(); # something bad happens;  returns 'undef'
print $string . "\n";        # code dies here

C＃：

string myString = null;

if (myString.Equals("someValue")) // NullReferenceException...
{

}

if ("someValue".Equals(myString)) // Just false...
{

}

在对string.IsNullOrEmpty进行c＃检查之前，对字符串进行任何操作，例如length，indexOf，mid等

public void SomeMethod(string myString)
{
   if(!string.IsNullOrEmpty(myString)) // same as myString != null && myString != string.Empty
   {                                   // Also implies that myString.Length == 0
     //Do something with string
   }
}

[编辑]
现在，我也可以在.NET 4.0中执行以下操作，该操作还检查该值是否只是空白

string.IsNullOrWhiteSpace(myString)

在Java和C＃中，为每个线程取一个有意义的名称。这包括线程池线程。它使堆栈转储更加有意义。甚至给线程池线程起一个有意义的名字要花费更多的精力，但是如果一个线程池在长时间运行的应用程序中有问题，我会导致发生堆栈转储（您确实了解SendSignal.exe，对吗？ ），获取日志，而不必中断正在运行的系统，我可以知道哪些线程是...什么。不管发生什么问题，僵局，泄漏，增长。

使用VB.NET，默认情况下，整个Visual Studio的Option Explicit和Option Strict均处于打开状态。

C ++

#define SAFE_DELETE(pPtr)   { delete pPtr; pPtr = NULL; }
#define SAFE_DELETE_ARRAY(pPtr) { delete [] pPtr; pPtr = NULL }

然后将所有“ delete pPtr ”和“ delete [] pPtr ”调用替换为SAFE_DELETE（pPtr）和 SAFE_DELETE_ARRAY（pPtr）

现在，如果错误地删除了指针“ pPtr”，则会出现“访问冲突”错误。它比随机存储器损坏要容易得多。

使用Java，即使在断言关闭的情况下运行生产代码，使用assert关键字也很方便：

private Object someHelperFunction(Object param)
{
    assert param != null : "Param must be set by the client";

    return blahBlah(param);
}

即使没有断言，至少代码也记录了预期将参数设置在某个地方的事实。请注意，这是一个私有帮助器函数，而不是公共API的成员。该方法只能由您调用，因此可以确定如何使用它。对于公共方法，最好为无效输入抛出一个真正的异常。

在readonly找到ReSharper之前，我没有找到关键字，但是现在我本能地使用它，尤其是对于服务类。

readonly var prodSVC = new ProductService();

在Java中，当某些事情发生并且我不知道为什么时，有时会像这样使用Log4J：

if (some bad condition) {
    log.error("a bad thing happened", new Exception("Let's see how we got here"));
}

这样，我得到了一个堆栈跟踪，向我显示了我是如何陷入意外情况的，比如说一个从未解锁的锁，一个不能为null的null等等。显然，如果抛出了真正的异常，则不需要这样做。在这种情况下，我需要查看生产代码中发生的事情，而又不会真正干扰其他任何事情。我不希望抛出一个异常，我没赶上之一。我只想记录一条堆栈跟踪，并记录一条适当的消息以将我标记为正在发生的事情。

如果使用的是Visual C ++，则每当重写基类的方法时，都应使用override关键字。这样，如果有人碰巧更改了基类签名，它将抛出编译器错误，而不是错误地调用方法。如果早已存在，这将为我节省几次。

例：

class Foo
{
   virtual void DoSomething();
}

class Bar: public Foo
{
   void DoSomething() override { /* do something */ }
}

我从Java中学到几乎没有无限期地等待锁解锁，除非我真正期望它可能需要无限长的时间。如果实际上，锁应该在几秒钟内解锁，那么我将只等待一定时间。如果锁没有解锁，那么我会抱怨并将堆栈转储到日志中，并根据对系统稳定性最有利的方式，要么继续将其解锁，要么就好像从未解锁一样继续。

在我开始这样做之前，这有助于隔离一些神秘的竞态条件和伪死锁条件。

C＃

• 验证公共方法中引用类型参数的非空值。
• 我sealed在类上花了很多时间，以避免在不需要的地方引入依赖。允许继承应该显式完成，而不是偶然。

发出错误消息时，至少尝试提供程序在决定引发错误时所具有的相同信息。

“拒绝权限”告诉您存在权限问题，但您不知道问题发生的原因或原因。“不能写事务日志/ my / file：只读文件系统”至少会让您知道做出决定的依据，即使该决定是错误的-尤其是如果它是错误的：文件名错误？开错了吗？其他意外错误？-并让您知道遇到问题时所在的位置。

在C＃中，使用as关键字进行转换。

string a = (string)obj

如果obj不是字符串，将抛出异常

string a = obj as string

如果obj不是字符串，将保留为null

您仍然需要考虑null，但这通常比查找强制转换异常更直接。有时，您需要“强制或爆炸”类型的行为，在这种情况下(string)obj，首选语法。

在我自己的代码中，我发现我使用as语法的时间约为75％，而使用(cast)语法的时间约为25％。

为任何事情做好准备输入如果遇到任何意外输入，请转储到日志中。（有原因。如果您正在从用户那里读取密码，请不要将其转储到日志中！也不要每秒将数千种此类消息记录到日志中。在记录日志之前，请先确定其内容，可能性和频率）

我不仅在谈论用户输入验证。例如，如果您正在读取希望包含XML的HTTP请求，请为其他数据格式做好准备。我很惊讶地看到HTML响应只希望XML，直到我看到并看到我的请求正在通过一个我不知道的透明代理并且客户声称对它不了解为止，并且该代理在尝试完成该请求时超时了请求。因此，代理向我的客户端返回了一个HTML错误页面，使客户端只希望XML数据的混乱变得混乱。

因此，即使您认为自己控制了导线的两端，也可以得到意想不到的数据格式，而不会涉及任何恶意。做好准备，进行防御性编码，并在输入意外的情况下提供诊断输出。

我尝试使用按合同设计方法。可以用任何语言模拟运行时。每种语言都支持“断言”，但是编写更好的实现可以使您以更有用的方式管理错误，这既容易又方便。

在排名前25位最危险的编程错误的“不正确的输入验证”是在一节“组件间不安全互动”最危险的错误。

在方法开始时添加前提条件断言是确保参数一致的好方法。在方法结束时，我写了后置条件，以检查输出是否符合预期。

为了实现不变式，我在任何检查“类一致性”的类中都编写了一个方法，该方法应通过前置条件和后置条件宏进行自定义调用。

我正在评估代码合同库。

爪哇

Java api没有不可变对象的概念，这很糟糕！在这种情况下，Final可以为您提供帮助。标签每类是不可变的与最终并准备类相应。

有时在局部变量上使用final很有用，以确保它们永远不会改变其值。我发现这在丑陋但必要的循环构造中很有用。它只是为了容易意外地重用变量，即使它被要求是一个常量也是如此。

在您的吸气剂中使用防御复制。除非返回原始类型或不可变的对象，否则请确保复制该对象以免违反封装。

切勿使用克隆，而使用副本构造函数。

了解equals和hashCode之间的约定。这经常被违反。问题是它在99％的情况下都不会影响您的代码。人们会覆盖等于，但并不在乎hashCode。在某些实例中，您的代码可能会中断或表现异常，例如，将可变对象用作映射中的键。

我忘记echo用PHP 编写太多次了：

<td><?php $foo->bar->baz(); ?></td>
<!-- should have been -->
<td><?php echo $foo->bar->baz(); ?></td>

我将永远需要尝试找出为什么-> baz（）没有返回任何内容，而实际上我只是没有回声它！：-S因此，我做了一个EchoMe可以包装在任何应回显的值周围的类：

<?php
class EchoMe {
  private $str;
  private $printed = false;
  function __construct($value) {
    $this->str = strval($value);
  }
  function __toString() {
    $this->printed = true;
    return $this->str;
  }
  function __destruct() {
    if($this->printed !== true)
      throw new Exception("String '$this->str' was never printed");
  }
}

然后在开发环境中，我使用了EchoMe包装应该打印的东西：

function baz() {
  $value = [...calculations...]
  if(DEBUG)
    return EchoMe($value);
  return $value;
}

使用该技术，第一个缺少的示例echo现在将引发异常...

C ++

键入new时，必须立即键入delete。特别是对于数组。

C＃

在访问属性之前，请检查是否为null，尤其是在使用Mediator模式时。对象被传递（如前所述，然后应使用as强制转换），然后检查是否为null。即使您认为它不会为null，也请进行检查。我很惊讶

使用允许动态，运行时日志级别调整的日志系统。通常，如果您必须停止某个程序以启用日志记录，那么您将丢失该错误发生的任何罕见状态。您需要能够在不停止该进程的情况下打开更多日志记录信息。

另外，Linux上的'strace -p [pid]'将显示您希望系统调用某个进程（或linux线程）。乍一看可能很奇怪，但是一旦您习惯了通常由libc调用进行的系统调用，您就会发现这对于现场诊断非常有用。