您在编程时多久运行和测试一次代码?[关闭]


16

尤其是在用C从头开始编写新代码时,我发现自己编写了数小时甚至数天的代码,除了偶尔进行语法检查之外,甚至没有运行编译器。

我倾向于仔细地编写更大的代码块,并仅在确信通过分析我的头脑中的代码可以实现代码的预期工作时才进行彻底的测试。不要误会我的意思-我不会编写1000行而不进行任何测试(这将是赌博),但是在我认为完成后我会编写一个完整的子例程并对其进行测试(并在必要时进行修复)。

另一方面,我看到大多数新手都会在他们进入编辑器的每一行之后运行并测试他们的代码,并认为调试器可以代替谨慎和理智的做法。学习了语言语法后,我认为这会分散很多注意力。

您认为这两种方法之间的正确平衡是什么?当然,第一个需要更多经验,但这对生产率有正面还是负面的影响?第二个可以帮助您更好地发现错误吗?


3
编写整个子例程需要花费数小时或数天的时间?

1
@Thorbjorn子例程长约999行,并且被混淆了:#define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r+z))); goto xkcd)而这仅仅是一行。
Mateen Ulhaq 2010年

1
编译器有时可能会花费很长时间来编译程序,这就是为什么始终没有编译的好习惯的原因。在执行每项功能后,都是好的做法。添加新功能或一些困难的代码后,我将重新编译。我仅将其用作语法检查器。没有其他方法可以仔细检查代码并避免隐藏的错误和偶然的行为。
罗斯,2010年

Answers:


6

这实际上取决于您正在处理的项目的方面。

  • 当我使用OpenGL(类似于状态机)执行任何操作时,我会不断编译并运行以确保不会意外搞砸任何东西。设置一个值而不记得在函数结束时将其重置会很容易使应用程序仅呈现黑屏。

  • 对于大规模“幕后”开发,我尝试事先获得尽可能多的测试。由于测试可以更轻松地告诉我发生了什么,所以我可以花一段时间,而不必等待通常漫长的编译。

  • 对于UX设计,我使用某种视觉设计器,它总是看起来像它的运行方式(或接近它)。本质上,它总是在编译设计代码。


63

就我个人而言,我必须分小块地工作,因为我不够聪明,无法在我的生物学L1缓存中保留数小时的编码。由于我的能力有限,因此我编写了一些紧凑的,有凝聚力的方法,并设计出具有非常松散耦合的对象。功能更强大的工具和语言使无需构建就可以更轻松地编码更长的时间,但是对我来说仍然有一个限制。

我的喜好是写一小段,验证它是否按我的预期工作。然后,从理论上讲,我可以自由地忽略该部件的细节,并尽可能将其视为黑匣子。


12
赞成“ ...不够聪明。”我已经有相当一段时间了。
leed25d 2010年

4
那你的二级缓存呢?
Mateen Ulhaq 2010年

我本来打算对此表示赞成,但总分是42 ...
Wayne Werner

较新的型号具有更大的L1缓存。您什么时候买的?您可能要去进行硬件更新。
彼得·阿杰泰

嗯,它不是模型的时代,而在于它是“预算”行。:(
dss539 2012年

17

我喜欢在编写实现代码之前先编写测试。我喜欢此举有以下三个原因:

  1. 事先编写测试代码可以帮助我思考如何使用我的代码。它可以帮助我想到最初设计程序时没有想到的边缘情况。
  2. 我知道当我所有的测试用例通过时,我就完成了编写实现代码。
  3. 养成在代码之前编写测试的习惯,还具有额外的效果,即能够证明您的代码没有添加任何新的错误(假设您已经编写了良好的测试用例)。

2
“我知道当我所有的测试用例通过时,我就完成了实现代码的编写。” -如何确定是否编写了所有必要的测试用例?
dss539 2010年

1
这是一个很好的问题。我认为,除非有正式的证明,否则您永远无法完全确定代码是否正常运行。我认为单元测试可以证明您的代码倾向于按照您的意图进行。但是,随着您添加的功能的增长,将要编写的测试用例的数量也可能会增长。如有疑问,请其他人查看您的测试用例,并询问他们未想到的用例。
David Weiser 2010年

4
@David-您如何正式证明您的正式证明没有错误?您如何正式证明您所感知的需求与实际需求相匹配。您可以正式证明一个描述与另一个描述匹配,但是两个描述完全有可能以相同的方式不正确-特别是如果两个描述都是由同一个人编写的。用数学记数法写东西不会使人无误。大量的数学“证明”已经证明(经过长时间的详尽检查)是错误的。
2010年

1
@ Steve314:AFAIK,当正式证明算法的正确性时,您可以准确准确地指定期望的正确性。但是,您提出了一个很好的观点,即“正确性”的定义可能实际上并不正确。
David Weiser 2010年

1
@ dss539,来自程序打算实现的用例。

4

我发现自己写了几个小时甚至几天的代码,只是偶尔进行语法检查而没有运行编译器。

数小时至数天-这是一个明显的信号,表明您错过了将代码分解为较小的块的能力,这些块可以自行验证和测试。您绝对应该在此上工作。

我倾向于仔细地编写更大的代码块,并仅在确信通过分析我的头脑中的代码可以实现代码的预期工作时才进行彻底的测试。

您应该尝试创建更小而不是那么大的构建块,而不是编写需要花费数小时才能分析的更大的代码(因此变得复杂)。这就是所谓的构建抽象 - 这是良好编程的要旨,绝对不是新手的迹象。

出色的编程就像出色的Billard演奏一样-优秀的演奏者不会打硬击。取而代之的是,他的打法是在每次击球后球停在下一击容易的位置。程序员不好是因为他会写复杂的代码-他很好是因为他能避免写复杂的代码。


3

我编译并测试是否满足以下条件之一:

  • 上次编译是15分钟前
  • 上一次编译是25行之前
  • 新功能/子程序已实现
  • 重大变化
  • 新功能(或伪装成功能的错误)
  • 错误修复(删除了“功能”)
  • 我很无聊

1

我运行和测试代码的频率取决于我当时使用的语言。如果要对存储过程进行编码,则通常会等到一切就绪为止。

另一方面,如果我使用Lisp进行编码,则在键入每个函数后将对其进行尝试。

如果我在Haskell中进行编码,通常会在每个函数之后进行编译以捕获任何类型错误,并在完成所有操作后运行代码。


1

我只编写了足以使测试变为绿色的代码。这意味着我每隔几分钟进行一次测试。那就是我的C ++风格。但是在Ruby中,我使用了自动测试,因此每次我点击保存时,都会通过漂亮的弹出窗口获得测试反馈。我什至不停止编写代码,它只是在后台发生。


1

不管是否需要,一个小时要三个小时。

我们进行测试优先编程,并将仅工作代码提交给VCS。smolderbot每20分钟检查一次仓库,然后运行测试套件。任何失败都将立即邮寄给整个编程团队以进行立即修复。


1

对我而言,这与我写多少无关。我可以编写数千行简单的代码,而无需对其进行测试。但是,当我编写更加困难的代码时,我倾向于在编写完所有功能后分别测试每个功能。

但是有时候,看到您的代码正在运行会极大地激发您的动力,当您一段时间没有执行任何操作时,很高兴能看到它的运行。


0

对我而言;-
时间表短(没有太多时间思考)-编写代码,编译,测试。调试
足够的时间-while(done){编写小代码,编译},测试,调试


我发现前者要比后者花费更长的时间:如果您的测试/写入循环非常小,您还有更多的调试时间。
Frank Shearar 2010年

也许。但是时间很短,这意味着屁股着火了,经理需要报告,其中说某些任务已100%完成。
Manoj R 2010年

0

我测试每个编码概念。有时这是一个函数或类,有时仅是一个if语句。一旦概念生效,请继续进行下一个。


0

我尝试在代码之前编写测试。在提交之前,我至少运行了两次测试。然后,它与Continous Integration服务器一起再次运行。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.