vba 将“Debug.Print”指令留在“生产”中的代码中是一种好习惯吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/8412404/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is it good practice to leave "Debug.Print" instructions in code that goes in "production"?
提问by BuZz
In Excel VBA, is it good practice to leave Debug.Printinstructions in code that goes in "production" ? That is quite useful to debug the sheets realtime at the user's machine when something goes wrong. Does it affect performance when Visual Studio is closed ? If not, what would you advise ?
在 Excel VBA 中，Debug.Print在“生产”中的代码中留下说明是一种好习惯吗？当出现问题时，这对于在用户机器上实时调试工作表非常有用。Visual Studio 关闭时是否会影响性能？如果没有，你有什么建议？
回答by Patrick Honorez
Debug.Print instruction DO have a small performance cost. So I would avoid them in loops that are executed a zillion times. Except for those cases, I think it's ok to keep them.
You could also use conditional compilation directives (#if) in combination with a compiler constant (#const) to enable/disable them globally without performance impact.
Debug.Print 指令的性能开销很小。所以我会在执行无数次的循环中避免它们。除了这些情况，我认为保留它们是可以的。
您还可以将条件编译指令 ( #if) 与编译器常量 ( #const)结合使用，以在不影响性能的情况下全局启用/禁用它们。
#CONST developMode = True
sub Xyz
#If developMode Then
Debug.Print "something"
#End If
End Sub
回答by dash
I usually have two versions; prod without debugging, and prod with debugging. That, combined with the catchall error handler logging, means that if a user experiences issues, I can deploy the debug version to them and they can run that up.
我通常有两个版本；prod 不调试，prod 调试。这与 catchall 错误处理程序日志记录相结合，意味着如果用户遇到问题，我可以向他们部署调试版本，他们可以运行它。
I have a macro that I run that comments out the debug.print statements, so it's not a real maintenance overhead.
我有一个我运行的宏，它注释掉 debug.print 语句，所以这不是真正的维护开销。
The problem with running a debug version all the time (and, with Excel VBA it's not usually a performance thing) is that your app is constantly emitting information that it doesn't need too. In an environment with controlled spreadsheets, for example, this can be seen as a bad thing.
一直运行调试版本的问题（而且，对于 Excel VBA，它通常不是性能问题）是您的应用程序不断发出它不需要的信息。例如，在具有受控电子表格的环境中，这可能被视为一件坏事。
In terms of global error handling, you still need the On Error GoTo statement for every function you want error handling in. You can, however, pipe these to a common function:
在全局错误处理方面，您仍然需要为每个要处理错误的函数使用 On Error GoTo 语句。但是，您可以将它们通过管道传递给一个公共函数：
Public Function HandleTheNastyErrors(E As ErrObject, ByVal writeLog As Boolean = True)
Select Case E.Number
Case xxx
...specific error handling...
Case Else
... Display a message to the user about how you dont know what happened....
End Select
If writeLog Then
...Log Writing Code...
End If
End Function
And then, OnError:
然后，OnError：
ErrorHandler:
Call HandleTheNastyErrors(Err, True)
Show do the trick
表演技巧
