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を使用する場合や、スクリプトの実験を行う場合によく使用します。ただし、実際のアプリケーションやライブラリに頻繁に表示される場合は、何かが正しくないことを示しています。おそらく、コードの構造が正しくありません。アプリケーションで使用する必要はなく、リリースされたコードのどこでも使用されることはめったにありません。

于 2010-12-24T21:37:25.703 に答える