当您编写代码时，您是主动还是被动地处理错误？
换句话说，您是花时间预测错误并编写代码来解决这些潜在问题，还是按照您认为合适的方式编写代码，然后逐个解决任何错误？
我最近一直在思考这个问题，而且我是一个非常反应性的人。我编写代码，试一试，返回纠正错误并重复，直到应用程序按预期工作。然而，我的一个朋友表示，他会花时间思考如何解释每一行，并在错误发生之前修复它们。
我必须指出，re-active 是纯粹的 PRE-live。我绝对会确保我的应用程序在上线之前能够正常运行。
In other words, do you spend time anticipating errors and writing code to get around these potential issues, or do you write the code as you see fit and then work through any errors on an issue by issue basis?
I've been thinking a lot about this lately and I'm very much a reactive person. I write my code, give it a whirl, go back correct error and repeat until application works as expected. However a friend of mine offered that he spends time thinking how each line is interpreted and fixes errors before they occur.
I must point out that re-active is pure PRE-live. I definitely make sure my application is working before it goes live.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
应该始终保持平衡。
太多的错误检查速度很慢并且会导致垃圾代码。没有足够的错误检查会使您的程序在边缘情况下崩溃，这在交付后不太好发现。
因此，您决定某段代码应该有多可靠，并相应地实施错误检查。一些测试实用程序可能不太可靠 - 错误检查较少。供第三方搜索服务在深层后台使用的 COM 服务器应该超级可靠 - 更多的错误检查。
There should always be a balance.
Too many error checking is slow and leads to garbage code. Not enough error checking makes your program crash on edge cases which is not very good to discover after having it shipped.
So you decide how reliable some piece of code should be and implement error checking accordingly. Some test utility can be not very reliable - less error checking. A COM server meant to be used by a third party search service in deep background should be super reliable - much more error checking.
我认为单独问这个问题有点奇怪，而且非常主观，但显然有很多技术可以让你做到每一个。我倾向于使用这两种：
我偶尔会转向程序的形式验证的世界。这绝对是“反应性”的，但如果你提前考虑一下，它往往会使验证变得更容易。
我还必须说，我重视编程中的许多预先思考。避免错误的最简单方法就是从一开始就不要编写它们。有时这是不可避免的，但通常多花一点时间思考问题可以带来质量更好的解决方案，然后可以使用我上面提到的自动化方法来处理其余的事情。
I think asking this in isolation is kinda weird, and very subjective, however there are obviously a bunch of techniques that permit you to do each. I tend to use these two:
Very occasionally I swerve into the world of formal verification of programs. That's definitely "reactive", but if you think a little more up-front, it tends to make the verification easier.
I must also say that I value a lot of up-front thought in programming. The easiest way to avoid bugs is to not write them in the first place. Sometimes it's inevitable, but often a little more time spent thinking about the problem can lead to better-quality solutions, and then the rest can be taken care of using the kinds of automated methods I talked about above.
我在编码时通常会问自己一堆假设，例如
等等。通过这样做，我发现当应用程序上线时，错误会少得多，我可以专注于修复更隐蔽的错误，而不是纠正一开始就应该存在的条件。
I usually ask myself a bunch of what-ifs when coding, like
and so on. By doing this I've found that when the application does go live, there are a ton fewer errors and I can focus on fixing more obscure bugs instead of correcting conditions that should have been in place to begin with.
在考虑错误处理时，我遵循一个简单的原则：垃圾输入，垃圾输出。如果您不希望任何垃圾（例如无效输入）弄乱您的软件，则必须找到软件中垃圾可以进入并处理的所有点。当然，你的软件越复杂，找到每个入口点就越困难，但我觉得你前期做的越多，以后需要的反应就越少。
I live by a simple principle when considering error-handling: garbage in, garbage out. If you don't want any garbage (e.g. invalid input) messing up your software, you have to find all the points in your software where it can get in and handle it. Of course, the more complicated your software is, the harder it is to find every point of entry, but I feel that the more you do up front the less reactive you will need to be later on.
我主张采取积极主动的做法。
这通常会导致软件运行相当顺利。有时它甚至让我感到惊讶，但这就是预期的目标，所以我们就在这里。
I advocate the proactive approach.
This usually results in software operating rather smoothly. At times it even surprises me but that was the intended goal, so here we are.
恕我直言，“错误”这个词（或其松散的同义词“bug”）本身意味着它是一种未预见到的程序行为。
我通常尝试在设计时考虑到所有可能的场景。当然，通常不可能想到所有可能的情况。但仔细思考并考虑尽可能多的场景通常比只是尽快让某些事情发挥作用要好。这节省了大量调试和重新设计代码的时间和精力。在实际在编辑器中输入任何代码之前，我经常坐下来用笔和纸完成即使是最小的编程任务。
正如我所说，这并不能消除所有错误。对我来说，它在调试时间方面得到了数倍的回报。另一个好处是，它可以带来更可靠和可维护的设计，并且减少错误修复和稍后添加的特殊情况。但无论如何，代码完成后你将不得不进行大量的调试。
当您想要的只是模型或快速原型时，这并不适用。此外，截止日期等实际限制常常使彻底的评估变得困难或不可能。
IMHO, the word "Error" (or its loose synonym "bug") itself means that it is a program behavior that was not foreseen.
I usually try to design with all possible scenarios in mind. Of course, it is usually not possible to think of all possible cases. But thinking through and allowing for as many scenarios as possible is usually better than just getting something working as soon as possible. This saves a lot of time and effort debugging and redesigning the code. I often sit down with pen and paper for even the smallest of programing tasks before actually typing any code into my editor.
As I said, this will not eliminate all errors. For me it pays off many times over in terms of time spent debugging. Another benefit is that it results in a more solid and maintainable design with fewer bugfixing hacks and special cases added on later. But in any case, you will have to do a lot of debugging after the code is done.
This does not apply when all you want is a mockup or rapid prototype. Also practical constraints such as deadlines often makes a thorough evaluation difficult or impossible.
什么类型的编程？不可能以任何一般的方式回答这个问题。 （这就像问“你玩的时候戴头盔吗？”——好吧，玩什么？）
在工作中，我正在开发一个数据库支持的网站。要求很严格，如果我没有预料到用户会如何搞砸它，我会在一天中的某个奇怪的时间接到电话来修复它。
在家里，我正在编写一个程序......我什至还不知道它会做什么。我无法处理“错误”，因为我不知道在这种情况下“错误”是什么，因为我不知道正确的行为是什么。程序的整个目的可能并且经常会在几分钟到几小时的时间范围内发生变化，因此即使这么早花几分钟考虑错误也完全是浪费时间。 （这比浏览 SO 更糟糕，因为错误处理会增加代码行。）
我想唯一的一般答案是“从长远来看，我做了在节省时间方面有意义的事情”，这毕竟是整个使用机器为我们工作的理由。
What kind of programming? It's impossible to answer this in any general way. (It's like asking "do you wear a helmet when playing?" -- well, playing what?)
At work, I'm working on a database-backed website. The requirements are strict, and if I don't anticipate how users will screw it up, I'm going to get a call at some odd hour of the day to fix it.
At home, I'm working on a program ... I don't even know what it'll do yet. I can't deal with 'errors' because I don't know what 'an error' is in this context, because I don't know what correct behavior is going to be. The entire purpose of the program can and frequently does change on a timescale of minutes to hours, so even a couple minutes spent thinking about errors this early is a complete waste of time. (It's even worse than browsing SO, since error-handling adds lines of code.)
I guess the only general answer is "I do what makes sense in terms of saving time in the long term", which is, after all, the whole reason to use machines to do work for us.