当您编写代码时,您是主动地还是被动地处理错误?

应该始终保持平衡。

错误检查太多太慢,导致垃圾代码。没有足够的错误检查会导致程序在边缘情况下崩溃,而这些情况在交付之后不太好发现。

因此,您可以决定某段代码的可靠性,并相应地实现错误检查。一些测试实用程序可能不太可靠-无错误检查。用于第三方搜索服务的深层次背景的COM服务器应该是超级可靠的——更多的是错误检查。

我认为单独问这个问题有点奇怪,而且非常主观,但是显然有很多技术可以让你做到每一个。我倾向于使用这两种方法:

• 测试驱动开发(这似乎是主动的)
• 强静态类型(反应式,但是紧凑迭代开发周期的一部分,如中所述,它由我的ML编译器强制执行,我编译了很多)

我偶尔会转向程序正式验证的世界。这绝对是“反应性的”,但是如果你提前考虑一点,它会使验证更容易。

我还必须说,我重视编程中的很多前期思想。避免bug的最简单方法是不要首先编写它们。有时这是不可避免的,但通常花更多的时间思考问题可以得到更好的质量解决方案,然后剩下的可以使用我上面提到的自动化方法。

我通常会问自己,在编码时会有一些假设,比如

• 用户点击按钮,如果他们没有选择日期呢?
• 用户正在搜索框中键入,如果他们尝试在其中键入HTML怎么办?
• 我的标签文本取决于共享驱动器的值,如果它没有映射呢?

等等。通过这样做,我发现当应用程序真正上线时,错误会减少很多,我可以专注于修复更模糊的错误,而不是纠正本应该存在的条件。

在考虑错误处理时,我遵循一个简单的原则:垃圾输入,垃圾输出。如果您不希望任何垃圾(例如无效输入)弄乱您的软件,您必须找到软件中所有可以进入并处理它的点。当然,你的软件越复杂,就越难找到每一个入口点,但是我觉得你在前面做的越多,你以后就需要的反应就越少。

我提倡主动的方法。

• 我试着用这种方式编写代码,这会产生可维护和可靠的代码。
• 我使用防御性编程技术来防止由于我失去注意力和类似情况而导致的代码中的愚蠢错误。
• 我根据Fortress原理设计了数据库模型,对每次奇异操作后的结果进行SQL代码检查。
• 我想到了代码的这一部分可能会发生的潜在问题,我对此负责。不是所有的可能性,而是我现在能想到的主要的可能性。

这通常会导致软件运行相当顺利。有时它甚至让我吃惊,但这是我们的目标,所以我们在这里。

imho,单词“错误”(或其松散的同义词“bug”)本身意味着它是一种无法预见的程序行为。

我通常会考虑所有可能的场景。当然,通常不可能想到 全部的 可能的情况。但是,考虑并考虑尽可能多的场景通常比让一些东西尽快工作要好。这节省了大量时间和精力调试和重新设计代码。我经常拿着纸和笔坐下来做一些即使是最小的编程任务,然后在我的编辑器中输入任何代码。

正如我所说,这并不能消除所有的错误。对我来说,它在调试上花费了很多时间。另一个好处是,它导致了一个更坚实和可维护的设计,减少了bugfixing黑客和以后添加的特殊情况。但是在任何情况下,代码完成后都需要进行大量的调试。

当你只想要一个模型或快速原型时,这并不适用。此外,诸如最后期限之类的实际限制常常使彻底的评估变得困难或不可能。

什么 友善的 程序设计?不可能用任何一般的方式来回答这个问题。(就像问“你玩的时候戴头盔吗?”--好吧,玩 什么 ?)

在工作中,我在一个数据库支持的网站上工作。这些要求是严格的,如果我没有预料到用户会怎么搞砸它,我会在一天中的某个小时接到一个电话来解决它。

在家里,我正在做一个程序…我还不知道它会做什么。我不能处理“错误”,因为我不知道在这种情况下“错误”是什么,因为我不知道什么是正确的行为。这个程序的整个目的可以而且经常在从几分钟到几小时的时间尺度上改变,所以即使在这之前花几分钟思考错误也是完全浪费时间的。(这比浏览更糟糕,因为错误处理增加了代码行。)

我想唯一一般的答案是“我做了有意义的事情,从长远来看节省时间”,这毕竟是使用机器为我们工作的全部原因。