调试 ruby​​ 等脚本语言

发布于 08-07 20:11 字数 264 浏览 10 评论 0原文

我基本上来自 C 语言编程世界,现在深入研究 Ruby 和 Python 等脚本语言世界。

我想知道如何进行调试。 目前我遵循的步骤是,

  • 我完成一个大脚本,
  • 评论除我的部分之外的所有内容 想要检查
  • 执行脚本

虽然它有效,但我无法像在 VC++ 环境或类似环境中那样进行调试。

我的问题是,有没有更好的调试方法?

注:我猜这可能是一个重复的问题,如果是这样,请指出我的答案。

I am basically from the world of C language programming, now delving into the world of scripting languages like Ruby and Python.

I am wondering how to do debugging.
At present the steps I follow is,

  • I complete a large script,
  • Comment everything but the portion I
    want to check
  • Execute the script

Though it works, I am not able to debug like how I would do in, say, a VC++ environment or something like that.

My question is, is there any better way of debugging?

Note: I guess it may be a repeated question, if so, please point me to the answer.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(11

倒数 2024-08-14 20:11:38

你的顺序对我来说似乎完全倒退了。我是这样做的:

  1. 我为我想要的功能编写一个测试。
  2. 我开始编写脚本、执行位并验证测试结果。
  3. 我回顾了我所做的记录和发布工作。

具体来说,我在完成之前执行。到那时就太晚了。

当然,有调试器,但是通过良好的测试和良好的设计,我几乎从不需要调试器。

Your sequence seems entirely backwards to me. Here's how I do it:

  1. I write a test for the functionality I want.
  2. I start writing the script, executing bits and verifying test results.
  3. I review what I'd done to document and publish.

Specifically, I execute before I complete. It's way too late by then.

There are debuggers, of course, but with good tests and good design, I've almost never needed one.

烧了回忆取暖 2024-08-14 20:11:38

这是关于 ruby​​ 调试的 截屏红宝石调试。

Here's a screencast on ruby debugging with ruby-debug.

杯别 2024-08-14 20:11:38

似乎这里的问题是您的环境(Visual Studio)不支持这些语言,而不是这些语言通常不支持调试器。

Perl、Python 和 Ruby 都有功能齐全的调试器;您也可以找到其他可以帮助您的 IDE。对于 Ruby,有 RubyMine;对于 Perl,有 Komodo。这就是我的想法。

Seems like the problem here is that your environment (Visual Studio) doesn't support these languages, not that these languages don't support debuggers in general.

Perl, Python, and Ruby all have fully-featured debuggers; you can find other IDEs that help you, too. For Ruby, there's RubyMine; for Perl, there's Komodo. And that's just off the top of my head.

╰ゝ天使的微笑 2024-08-14 20:11:38

There is a nice gentle introduction to the Python debugger here

奢华的一滴泪 2024-08-14 20:11:38

如果您使用 Python,则可以在此处找到调试工具列表我只想添加 EclipsePydev 扩展,这使得使用断点等也非常简单。

If you're working with Python then you can find a list of debugging tools here to which I just want to add Eclipse with the Pydev extension, which makes working with breakpoints etc. also very simple.

鲜血染红嫁衣 2024-08-14 20:11:38

我的问题是,有没有更好的调试方法?”

是的。

你的方法,“1. 一个大型脚本,2. 注释除我要检查的部分之外的所有内容,3. 执行脚本”实际上并不是用任何语言编写任何软件的最佳方法(抱歉,但这是事实。)

我完成了 任何大的东西都可以

这样做。

  1. 将你的问题分解为对象的类。

  2. 2a。概述类,重点关注外部接口,而不是实现细节。

    2b。编写测试来证明接口有效。

    2c。运行测试。他们会失败,因为你只概述了课程。

    2d。修复该类直到通过测试。

    2e。在某些时候,您会意识到您的类设计并不是最佳的。重构您的设计,确保您的测试仍然通过。

  3. 现在,编写您的最终脚本。它应该很短。所有类都已经过测试。

    3a。概述脚本。事实上,您通常可以编写脚本。

    3b。编写一些测试用例来证明脚本有效。

    3c。运行测试。他们可能会通过。你已经完成了。

    3d。如果测试未通过,请修复问题直至通过。

写很多小事。从长远来看,这比写一篇大文章并评论其中的一部分效果要好得多。

My question is, is there any better way of debugging?"

Yes.

Your approach, "1. I complete a large script, 2. Comment everything but the portion I want to check, 3. Execute the script" is not really the best way to write any software in any language (sorry, but that's the truth.)

Do not write a large anything. Ever.

Do this.

  1. Decompose your problem into classes of objects.

  2. For each class, write the class by

    2a. Outline the class, focus on the external interface, not the implementation details.

    2b. Write tests to prove that interface works.

    2c. Run the tests. They'll fail, since you only outlined the class.

    2d. Fix the class until it passes the test.

    2e. At some points, you'll realize your class designs aren't optimal. Refactor your design, assuring your tests still pass.

  3. Now, write your final script. It should be short. All the classes have already been tested.

    3a. Outline the script. Indeed, you can usually write the script.

    3b. Write some test cases that prove the script works.

    3c. Runt the tests. They may pass. You're done.

    3d. If the tests don't pass, fix things until they do.

Write many small things. It works out much better in the long run that writing a large thing and commenting parts of it out.

陪我终i 2024-08-14 20:11:38

脚本语言与其他语言相比没有什么区别,因为您仍然需要将问题分解为可管理的部分(即函数)。因此,我更喜欢在集成这些小功能之前先测试这些小功能,而不是在完成整个脚本后测试整个脚本。 TDD 总是有帮助的。

Script languages have no differences compared with other languages in the sense that you still have to break your problems into manageable pieces -- that is, functions. So, instead of testing the whole script after finishing the whole script, I prefer to test those small functions before integrating them. TDD always helps.

各自安好 2024-08-14 20:11:38

这里有一个关于 Ruby IDE 的问题 - 并搜索“ruby IDE”提供更多。

我完成了一个大脚本

这就是引起我注意的地方:“完成”对我来说意味着“完成”、“完成”、“发布”。无论您是否在编写通过测试的函数之前编写测试,或者是否根本不编写测试(我建议您这样做),您都不应该编写无法运行的代码(这本身就是一个测试) )直到它变大。 Ruby 和 Python 提供了多种方法来编写小型的、可单独测试(或可执行)的代码片段,这样您就不必等待(?)几天才能运行该代码。

我目前正在构建一个(Ruby)数据库翻译/转换脚本 - 大约有 1000 行,但尚未完成。我很少会超过 5 分钟而不运行它,或者至少运行我正在处理的部分。当它崩溃时(我并不完美,它崩溃了很多;-p)我知道问题一定出在哪里 - 在我在最后 5 分钟编写的代码中。进展相当快。

我并不是断言 IDE/调试器没有立足之地:有些问题直到大量代码发布后才会显现出来:有时将整个代码放入调试环境中以了解发生了什么情况确实非常有用在。当涉及第三方库和框架时,调试其代码以查找问题(通常但并非总是与对库函数的错误理解有关)非常有用。

There's a SO question on Ruby IDEs here - and searching for "ruby IDE" offers more.

I complete a large script

That's what caught my eye: "complete", to me, means "done", "finished", "released". Whether or not you write tests before writing the functions that pass them, or whether or not you write tests at all (and I recommend that you do) you should not be writing code that can't be run (which is a test in itself) until it's become large. Ruby and Python offer a multitude of ways to write small, individually-testable (or executable) pieces of code, so that you don't have to wait for (?) days before you can run the thing.

I'm building a (Ruby) database translation/transformation script at the moment - it's up to about 1000 lines and still not done. I seldom go more than 5 minutes without running it, or at least running the part on which I'm working. When it breaks (I'm not perfect, it breaks a lot ;-p) I know where the problem must be - in the code I wrote in the last 5 minutes. Progress is pretty fast.

I'm not asserting that IDEs/debuggers have no place: some problems don't surface until a large body of code is released: it can be really useful on occasion to drop the whole thing into a debugging environment to find out what is going on. When third-party libraries and frameworks are involved it can be extremely useful to debug into their code to locate problems (which are usually - but not always - related to faulty understanding of the library function).

何其悲哀 2024-08-14 20:11:38

您可以使用附带的 pdb 模块调试 Python 脚本。如果您想要一个可视化调试器,您可以下载 winpdb - 不要被“win”前缀推迟, winpdb是跨平台的。

You can debug your Python scripts using the included pdb module. If you want a visual debugger, you can download winpdb - don't be put off by that "win" prefix, winpdb is cross-platform.

鲜肉鲜肉永远不皱 2024-08-14 20:11:38

您描述的调试方法对于像 C++ 这样的静态语言来说是完美的,但是考虑到语言如此不同,编码方法也同样不同。在 Python 或 Ruby 等动态语言中,最重要的事情之一就是交互式顶层(通过在命令行上键入 python 得到的内容)。这意味着运行程序的一部分非常容易。

即使您在测试之前编写了一个大型程序(这是一个坏主意),也希望将其分成许多函数。因此,打开交互式顶层,执行导入事物(无论发生什么事物),然后您可以轻松地开始逐个测试您的函数,只需调用它们在顶层。

当然,对于一个更成熟的项目,您可能想要编写一个实际的测试套件,并且大多数语言都有一种方法可以做到这一点(在Python中,这是doctestnose,不知道其他语言)。不过,一开始,当您编写不太正式的内容时,只需记住一些调试动态语言的简单规则即可:

  • 从小处开始。不要编写大型程序并测试它们。在编写每个函数时测试它,至少是粗略地测试。
  • 使用顶层。使用 Python 等语言运行小段代码非常轻量:启动顶层并运行它。与用 C++ 编写完整的程序并编译运行它相比。利用这一事实,您可以快速更改任何函数的正确性。
  • 调试器很方便。但通常情况下,print 语句也是如此。如果您只运行单个函数,那么使用 print 语句进行调试并不是那么不方便,而且还可以让您免于在 IDE 中拖拖拉拉。

The debugging method you described is perfect for a static language like C++, but given that the language is so different, the coding methods are similarly different. One of the big very important things in a dynamic language such as Python or Ruby is the interactive toplevel (what you get by typing, say python on the command line). This means that running a part of your program is very easy.

Even if you've written a large program before testing (which is a bad idea), it is hopefully separated into many functions. So, open up your interactive toplevel, do an import thing (for whatever thing happens to be) and then you can easily start testing your functions one by one, just calling them on the toplevel.

Of course, for a more mature project, you probably want to write out an actual test suite, and most languages have a method to do that (in Python, this is doctest and nose, don't know about other languages). At first, though, when you're writing something not particularly formal, just remember a few simple rules of debugging dynamic languages:

  • Start small. Don't write large programs and test them. Test each function as you write it, at least cursorily.
  • Use the toplevel. Running small pieces of code in a language like Python is extremely lightweight: fire up the toplevel and run it. Compare with writing a complete program and the compile-running it in, say, C++. Use that fact that you can quickly change the correctness of any function.
  • Debuggers are handy. But often, so are print statements. If you're only running a single function, debugging with print statements isn't that inconvenient, and also frees you from dragging along an IDE.
如日中天 2024-08-14 20:11:38

这里有很多好的建议,我建议尝试一些最佳实践:

http://github.com/edgecase/ ruby_koans

http://blog.rubybestpractices.com/

http://on-ruby.blogspot.com/2009/01/ ruby-best-practices-mini-interview-2.html

(并阅读 Greg Brown 的书,非常棒)


您谈论大型脚本。我的很多工作流程是在 irb 或 python shell 中制定逻辑,然后将它们捕获到一系列小型的、以单任务为中心的方法中,并进行适当的测试(不是 100% 覆盖率,更多地关注边缘和角落情况)。

http://binstock.blogspot.com/ 2008/04/perfecting-oos-small-classes-and-short.html

There's a lot of good advice here, i recommend going through some best practices:

http://github.com/edgecase/ruby_koans

http://blog.rubybestpractices.com/

http://on-ruby.blogspot.com/2009/01/ruby-best-practices-mini-interview-2.html

(and read Greg Brown's book, it's superb)


You talk about large scripts. A lot of my workflow is working out logic in irb or the python shell, then capturing them into a cascade of small, single-task focused methods, with appropriate tests (not 100% coverage, more focus on edge and corner cases).

http://binstock.blogspot.com/2008/04/perfecting-oos-small-classes-and-short.html

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文