09责怪他人之前先检查一下你的代码
Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken.
开发者--- 我们所有人！---经常难以相信我们自己写的代码有问题。不可能，一定是编译器哪里出问题了。
Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software. Yes, these bugs exist, but they are far less common than we might like to believe.
但实际上，代码被编译器、解释器、操作系统、应用服务器、数据库、内存管理器或任何其他系统软件中的错误破坏是非常(非常)不寻常的。是的，这些bug确实存在，但是它们远没有我们想象的那么普遍。
I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many more times. I have wasted a lot of my time, support time, and management time in the process only to feel a little foolish each time it turned out to be my mistake after all.
我曾经在优化循环变量的编译器bug上遇到过真正的问题，但我曾多次想象我的编译器或操作系统有bug。在这个过程中，我浪费了很多自己的时间、支持时间和管理时间，但每次都觉得有点愚蠢，毕竟这是我的错误。
Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.)
假设这些工具被广泛使用，成熟，并在各种技术栈中使用，那么没有太多理由去怀疑其质量。当然，如果这个工具是早期发布的，或者是世界上很少有人使用的，或者是一个很少下载的0.1版开源软件，那么可能有充分的理由怀疑这个软件。(同样，商业软件的alpha版本也值得怀疑的。)
Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; explain it to someone else; look out for stack corruption and variable type mismatches; try the code on different machines and different build configurations, such as debug and release.
考虑到编译器错误的罕见性，将时间和精力放在查找代码中的错误上，比放到证明编译器有错误上，要理性的多。所有通用的调试建议都适用，所以应当隔离问题，截掉调用，用测试包围它；检查调用约定、共享库和版本号；将问题讲给别人听；注意堆栈损坏和变量类型不匹配；在不同的机器和不同的构建配置(如调试和发布)上尝试代码。
Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor.
质疑自己的假设和别人的假设。来自不同供应商的工具可能有不同的假设，来自同一供应商的不同工具也可能有不同的假设。
When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They maybe doing something you never thought of or are doing something in a different order.
当别人上报了一个你不能复现的问题时，去看看他们是如何操作的。他们可能在做一些你从未想过的事情，或者正在以不同的顺序做一些事情。
As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler, then it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around.
作为个人规则，如果有一个我无法确定的错误，并且我开始认为它是编译器，那么是时候寻找堆栈损坏了。如果添加跟踪代码会使问题四处移动，这一点尤其正确。
Multi-threaded problems are another source of bugs to turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi-threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.
多线程问题是另一个导致头发变白并引发机器尖叫的错误来源。当系统是多线程的时候，所有支持简单代码的建议都会成倍增加。不能依赖调试和单元测试来找到任何一致性的错误，所以设计的简单性是至关重要的。
So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."
所以在你急于指责编译器之前，记住Sherlock Holmes的建议，“一旦你消除了不可能，无论多么不应该出现，都必须是真相”，而不是Dirk Gently的建议，“一旦你消除了不应该出现，无论多么不可能，都必须是真相。"
Last updated