30

每当我处理原型脚本时，我倾向于使用它，并且：

  1. 使用一些常见的变量（例如fileCount），并且
  2. 有一个大方法（20+ 行），并且
  3. 暂时不要使用类或命名空间。

在这种情况下，为了避免潜在的变量冲突，我一完成就删除了这个虫子。我知道，在生产代码中我应该避免使用 1.、2. 和 3.，但是从可以工作的原型到完全完善的类是耗时的。有时我可能想满足于一个次优的、快速的重构工作。在那种情况下，我发现把这些del陈述放在手边。我是否正在养成一种不必要的坏习惯？del完全可以避免吗？什么时候会是好事？

4

2 回答 2

26

我不认为这del本身就是一种代码气味。

在同一个命名空间中重用变量名绝对是一种代码异味，因为在适当的情况下不使用类和其他命名空间。因此，使用del来促进这类事情是一种代码味道。

del我能想到的唯一真正合适的用途是打破循环引用，这通常也是一种代码味道（而且通常，这甚至没有必要）。请记住，del所做的只是删除对对象的引用，而不是对象本身。这将通过引用计数或垃圾收集来处理。

>>> a = [1, 2]
>>> b = a
>>> del a
>>> a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
>>> b
[1, 2]

您可以看到该列表在del声明之后保持活动状态，因为b仍然保留对它的引用。

所以，虽然del不是真正的代码气味，但它可以与那些东西相关联。

于 2010-12-24T21:35:34.787 回答
9

del除非在特殊情况下，否则不需要任何在函数、类和方法中组织良好的代码。旨在通过使用更多功能和方法，避免重用变量名等，从一开始就构建您的应用程序。

使用del语句是可以的——它不会导致任何麻烦，当我使用 Python 作为系统上的 shell 脚本的替代品时，以及在进行脚本实验时，我经常使用它。但是，如果它经常出现在实际的应用程序或库中，则表明某些事情不太好，可能是代码结构不佳。我从来不需要在应用程序中使用它，而且你很少会看到它在已发布代码的任何地方使用。

于 2010-12-24T21:37:25.703 回答