如何不要忘记删除代码中的调试行
在我看来，这是一个新颖的想法（因为我还没有找到任何解决方案或任何人实现它）......
每当您进行 git commit 或其他任何操作时都会自动运行的 shell 脚本，如果您忘记删除项目中任何调试或开发环境特定的代码行，它会让您知道。
例如：
通常（在我的 Ruby 项目中）我会留下代码行来输出变量，例如
puts params.inspect
或
raise params.inspect
另外，有时我会使用不同的方法，这样我就可以轻松地看到效果，例如在使用delayed_job的情况下，我会而是在开发过程中立即调用该方法。
问题是有时我忘记将这些方法改回来，或者忘记删除对 raise params.inspect 的调用，我会无意中推送该代码。
所以我认为也许最简单的解决方案是向任何此类调试行添加注释，例如
raise params.inspect #debug
本质上将该行标记为仅开发/调试行。然后，在 git commit 等其他命令之前运行的 shell 脚本中，它可以使用 awk 或 grep 搜索所有最新修改的文件中的 #debug 注释，然后停止执行并向您发出警报。不过我对 shell 脚本了解不多，所以我想我应该寻求帮助:)
This seems to me to be a novel idea (since i haven't found any solutions or anyone having implemented it)...
A shell script that automatically runs whenever you git commit or whatever that will let you know if you forgot to delete any debugging or development env specific lines of code in your project.
For example:
Often times (in my Ruby projects) I'll leave lines of code to output variables like
puts params.inspect
or
raise params.inspect
Also, sometimes I'll use different methods so I can easily see the effects such as in cases like using delayed_job where I'd rather call the method without a delay during development.
The problem is sometimes I forget to change those methods back or forget to delete a call to raise params.inspect and I'll inadvertently push that code.
So I thought maybe the simplest solution was to add a comment to any such debugging line such as
raise params.inspect #debug
In essence flagging that line as a development only/debug line. Then in a shell script that runs before some other command like git commit it can use awk or grep to search through all the latest modified files for that #debug comment and stop execution and alert you. However i don't know much about shell scripting so I thought I'd ask for help :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
尽管我全心全意地建议遵循 cdeszaq'a 的建议并且不鼓励做这种事情，但编写一个 git hook 来阻止您提交带有特定字符串的任何行是相当容易的。为简单起见，我没有显示您应该使用的 git rev-parse --verify HEAD 来使该钩子在初始提交上工作，但是如果您只是将以下内容放入 .git/hooks/pre-commit 中（并使它可执行），您将无法提交包含字符串“#debug”的任何代码行：
Although I whole-heartedly recommend following cdeszaq'a advice and discourage doing this sort of thing, it is pretty easy to write a git hook that will prevent you from committing any lines with a particular string. For simplicity, I'm not showing the git rev-parse --verify HEAD that you should use to make this hook work on an initial commit, but if you simply put the following in .git/hooks/pre-commit (and make it executable), you will not be able to commit any lines of code that contain the string '#debug':
为什么不放入合理的调试语句< em>从一开始？
大多数语言都有相当有表现力且通常很便宜的日志库，允许您将各种级别的信息（错误、信息、调试、跟踪）写入许多不同的位置（文件、数据库）。其中许多库甚至允许您在运行时甚至在程序运行时调整特定代码块的日志记录级别。
因此，与其尝试通过编写脚本来消除问题来解决强力调试，为什么不自己以及世界其他必须使用您生成的内容的人帮忙并使用实际的日志记录框架来进行日志记录呢？
Rather than having to remember to do additional work (removing lines of code) only to have to do more work later when things break again (re-adding that code), why not put in sensible debugging statements from the beginning?
Most languages have fairly expressive and often cheap logging libraries that will allow you to write out various levels of information (error, info, debug, trace) to a number of different locations (a file, a database). Many of these libraries will even let you adjust the logging level for a specific chunk of the code at runtime or even while the program is running.
So, rather than try to bandage up brute-force debugging by scripting away the problem, why not do yourself, and the rest of the world that has to use what you produce, a favor and use an actual logging framework for logging?
正如我在评论中所说，您可以使用任何您觉得舒服的编程语言。
不管怎样，寻找其他提交挂钩，我认为 这个可能是一个不错的开始。它基本上会在文件中查找一些单词，并且只需更改文件顶部的
checks数组即可进行自定义。As I said in my comment, you can use any programming language you feel comfortable with.
Anyway, searching for other commit hooks, I think this one could be a good one to start with. It basically looks for some words in your files and can be customized just changing the
checksarray in the top of the file.@cdeszaq 关于日志记录部分是正确的。
对于因环境而异的行为，实现此目的的常见方法是使行为可配置。
delayed_job应该从配置文件中读取一个值来决定延迟多长时间。对于生产环境，配置将具有一个值，而对于开发环境，配置将具有不同的值。@cdeszaq is correct about the logging part.
For behaviour that differs depending on environment, the common way to achieve this is to make the behaviour configurable.
delayed_jobshould read a value from the config file to decide how long to delay. For production environments the config would have one value and for development environments the config would have a different value.