![]() |
1
4
不,这不是作弊。 我认为,如果您对编程“逻辑”的感觉有所减弱,那么刷新甚至学习这一点的绝对、最佳、100%的方法就是在调试器中观察代码。 这是一个很酷的想法,如果我再教一个初学者编程课,我应该让一台计算机在那里运行调试器中的代码,这样学生就可以看到发生了什么。 为了回答你的第二个问题,如果我真的需要担心代码在做什么,那么我就开始写东西了。但是,如果我是通过在Eclipse中导航来查看代码的,那么我很少需要写下东西,因为我刚才所在位置的历史记录是随时可用的。然而,如果这段历史没有被电脑记录下来,当我浏览代码时,我绝对会在一个便笺簿上疯狂地涂鸦。 |
![]() |
2
2
这是我需要时间来认识到的: 理解别人写的代码不是巫术,只是练习而已。 这不是智力和逻辑的问题,真正的,这是你在真正理解他人代码的同时所开发的一项技能。 当我开始工作的时候,我真的开始理解这一点,并且提高了这一技能,因为我需要修改别人的代码。 不要害怕,你读的代码越多,就越容易。 |
![]() |
3
2
使用调试器查找错误或观察程序行为不是“欺骗”,但必须小心,不要让它变成拐杖。过多地依赖调试器也会导致“ programming by accident “,这也不是很有效。而且,你真的希望能够概念化事物是怎样的 想象上的 在调试程序中观察它是否按您认为的方式工作之前就开始工作。 编程在很大程度上是一种抽象的心理活动。你必须在你的头脑中计算出一些东西是如何工作的(设计),然后你去编写代码(实现)。你越能在头脑中想象出某件事将如何运作,从长远来看,你的工作效率就越高。 正如其他人提到的,有很多时候您不能使用调试器。我认为从长远来看,最好是编写代码,这样更容易理解代码的行为。 |
![]() |
4
1
即使是最有经验的程序员也会在调试器中查找答案和说明;或者编写简单的旧printf来理解状态;或者在阅读/审阅他人代码时写下内容。 我认为你通过观察发生在幕后的事情来学习任何东西都不是欺骗,事实上,你将比仅仅阅读书籍并将其作为一个抽象的想法拥有更清晰、更具体的理解。 所以不,这根本不是作弊。 |
![]() |
5
1
使用调试器并逐步执行是理解代码、库、API等内部结构的最佳方法之一。学习。所以这绝对不是欺骗,而是学习,是获取知识。 |
![]() |
6
1
大多数时候,练习是让您思考代码中可能发生的事情,而不是在特定的运行中发生的事情。因此,使用调试程序运行几次可能会有所帮助,但是您仍然需要从这些特定的运行中进行概括。对于算法,这通常意味着考虑路径如何随着输入大小的增加而增长。对于并发程序,这意味着要考虑不同执行线程的路径如何在代码中相互作用。无论您多次运行调试程序,它都不会告诉您这些事情。 使用一个调试器只会告诉你在一次试验中发生了什么;它不会训练你抽象地思考你的程序——它只是一个苹果从树上掉下来,而不是重力理论。 |
![]() |
7
1
可以使用调试器来尝试找出为什么会发生某些事情,特别是在神秘的代码中,但最好先预测应该发生什么,然后看看调试器是否确认了您的推理和直觉。将来,这将帮助您编写能够捕获意外错误的测试用例,并且从一开始就开始编写代码。 |
![]() |
8
0
绝对不是!这与作弊正好相反!了解正在发生的事情的最好方法就是深入了解事情的本质并观察它的发生。从书中读代码会让人眼花缭乱,无聊透顶…但是,在调试器中观察它的执行是很神奇的,特别是当您在某个特定部分遇到问题时。 如果没有在调试程序中运行它并观察几乎所有的代码,我永远不会发布我编写的代码。 |
![]() |
9
0
我同意你没有在一般意义上作弊。我只能看到两种情况,在这种情况下,您可以考虑将调试器用作欺骗:
|
![]() |
10
0
好吧,如果你要参加一个课程的期中考试,那就是作弊,而且有一个“编程”问题需要你在纸上分析一些东西,而不运行它。但我一直讨厌这种测试,正是因为它看起来一点用处都没有——它与实际编程完全不同。而且,即使在那里,你仍然可能会通过在笔记中写下临时处理来“运行”它。 我发现最好不要过分依赖实际的调试器,因为有时你不得不依赖更简单的调试方法(比如说,如果你试图调试一个问题,而这个问题只能在一个不希望你在她的计算机上胡闹的测试人员拥有的计算机上重现)。但即使在那里,您仍然在运行代码并看到发生了什么(可能还会添加“调试”消息框或将文本写入磁盘函数)。在没有实际运行程序的情况下(甚至在纸上)尝试阅读比“你好世界”复杂得多的程序并不能避免作弊,这是受虐狂。 也就是说,的确,当你看到一种特定的语言或一类问题时,你就越不必这么做。但是,当然,如果有一个bug,即使是你见过无数次类似版本的代码中的一个bug,找到它的最快和最不痛苦的方法总是运行代码并查看它的功能。 |
![]() |
11
0
我认为在调试器中有极端的价值,作为一种学习工具,它们可能特别棒。有时您只需要它们来诊断缺陷。但是,我认为,如果在开发软件时不断地依赖于调试器,则可能会出现不良的编程习惯。 完美高效的软件开发人员能够很好地理解她所使用的抽象——语言、框架、操作系统——能够向系统声明她的问题,并知道它是正确的。当然,这是一个不切实际的理想,但我认为这是一件值得努力的事情。如果你经常在调试器中发现自己,这意味着你不理解你的抽象,这意味着你在编写代码时会慢很多。即使您在调试器的帮助下解决了这一问题,但是当您尝试在功能和特性上分层时,您的无知会减慢您的速度。 很明显,你处于“学习”模式,所以任何能让你达到那种理解水平的东西都取决于你的学习风格。如果调试程序帮助您到达那里,那就太好了。但是,如果您希望提高工作效率,那么最好的目标是了解如何在编写代码时获得正确的代码,而不是在运行代码时获得正确的代码。 与这个问题相关的是LinusTorvalds对调试器的咆哮,我特别喜欢: |
![]() |
feasega · 聚合物模拟-2个节点之间的最短路线,适用于所有节点 6 月前 |
![]() |
Alisa Petrova · 在有向图中更改一对顶点以创建循环 6 月前 |
![]() |
b39b332d · 使用C++标准库实现高效间隔存储 10 月前 |
![]() |
Paul C · 在维基百科上,将二叉搜索树转换为排序链表的算法是否存在错误? 10 月前 |
![]() |
ABGR · 二叉树的直径——当最长路径不通过根时的失败案例 10 月前 |
![]() |
EpicAshman · 数独棋盘程序中同一列和同一行出现两次的数字 11 月前 |