blocks|key|1354033|text|我发现下面的代码相当方便。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1354034|1)断言。|1354035|2)一个调试记录器，可以输出到调试输出、控制台或文件。|1354036|3)内存跟踪工具。|1354037|4)单元测试。|1354038|5)智能指针。|1354039|我敢肯定还有很多其他的，但我想都想不出来:)|1354040|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

I find the following rather handy.

1) ASSERTs. 
2) A debug logger that can output to the debug spew, console or file. 
3) Memory tracking tools. 
4) Unit testing. 
5) Smart pointers. 

Im sure there are tonnes of others but I can't think of them off the top of my head :)

blocks|key|240565|text|自动化单元测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240566|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

blocks|key|240459|text|有一种经常被忽视的技术，我喜欢称之为QA团队，它可以在bug投入生产之前创造奇迹，剔除它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240460|根据我的经验(课本中经常引用)，程序员并不是最好的测试人员，不管他们怎么想，因为他们倾向于测试他们已经从他们的编码中知道是真的行为。最重要的是，他们通常不太善于设身处地地为最终用户着想(如果是这样的应用程序)，因此很可能会忽略UI格式/对齐/可用性问题。|240461|是的，单元测试是非常重要的，我相信其他人在这方面可以给你比我更好的提示，但不要忽视你的系统/集成测试。:)|240462|..and嘿，这是一种独立于语言的技术！|240463|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

There's an oft-unappreciated technique that I like to call The QA Team that can do wonders for weeding out bugs before they reach production.

It's been my experience (and is often quoted in textbooks) that programmers don't make the best testers, despite what they may think, because they tend to test to behaviour they already know to be true from their coding. On top of that, they're often not very good at putting themelves in the shoes of the end user (if it's that kind of app), and so are likely to neglect UI formatting/alignment/usability issues.

Yes, unit testing is immensely important and I'm sure others can give you better tips than I on that, but don't neglect your system/integration testing. :)

..and hey, it's a language independent technique!

blocks|key|4570739|text|Code+Review、Unit+Testing和Continuous+Integration都可能会有所帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4570740|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Code_review|1|http://en.wikipedia.org/wiki/Unit_testing|2|http://martinfowler.com/articles/continuousIntegration.html^0|0|B|0|C|C|1|P|M|2|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]|$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]|N|$5|G|H|I|C|$J|O]]]]

<a href="http://en.wikipedia.org/wiki/Code_review" rel="nofollow noreferrer">Code Review</a>, <a href="http://en.wikipedia.org/wiki/Unit_testing" rel="nofollow noreferrer">Unit Testing</a>, and <a href="http://martinfowler.com/articles/continuousIntegration.html" rel="nofollow noreferrer">Continuous Integration</a> may all help.

blocks|key|4570867|text|RAII，避免资源泄漏错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4570868|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/RAII^0|0|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

<a href="http://en.wikipedia.org/wiki/RAII" rel="nofollow noreferrer">RAII</a> to avoid resource leakage errors.

blocks|key|240831|text|为了让你的代码有机会利用类型系统并让编译器在编译时进行尽可能多的检查，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240832|争取让你的代码在编译时进行检查。模板和代码生成是您的好朋友，只要您保持您的通用代码和全局variables.|ordered-list-item|240833|Use+RAII的数量！|offset|length|240834|使用assertions！|240835|自动测试某些名义上和所有角落的情况。|240836|避免最后一刻的更改。|240837|<+sense.|240838|Minimize+>G221|240839|240840|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization|1|http://en.wikipedia.org/wiki/Assertion_%2528computing%2529#Assertions_during_the_development_cycle^0|0|0|4|4|0|0|2|A|1|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|14|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|15|8|@]|9|@$G|16|H|17|1|18]]|A|$]]|$1|I|3|J|5|D|7|19|8|@]|9|@$G|1A|H|1B|1|1C]]|A|$]]|$1|K|3|L|5|D|7|1D|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1E|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1F|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|1G|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10]]|11|$5|W|X|Y|A|$Z|12]]]]

<ol>
<li>Strive for <a href="http://www.c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork" rel="nofollow noreferrer">simplicity and conciseness</a>.</li>
<li>Never leave cases where your code <a href="http://en.wikipedia.org/wiki/Undefined_behavior" rel="nofollow noreferrer">behavior is undefined</a>.</li>
<li>Look for opportunities to leverage the type system and have the compiler check as much as possible at compile time. Templates and code generation are your friends as long as you keep your common sense.</li>
<li>Minimize the number of singletons and global variables.</li>
<li>Use <a href="http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization" rel="nofollow noreferrer">RAII</a> !</li>
<li>Use <a href="http://en.wikipedia.org/wiki/Assertion_%28computing%29#Assertions_during_the_development_cycle" rel="nofollow noreferrer">assertions</a> !</li>
<li>Automatic testing of some nominal and all corner cases.</li>
<li>Avoid last minute changes like the plague.</li>
</ol>

blocks|key|4570883|text|我用的是思考。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4570884|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

blocks|key|4570922|text|将变量的范围缩小到尽可能小的范围。外部作用域中的变量更少-更少的机会植入和隐藏错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4570923|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Reducing variables scope to as narrow as possible. Less variables in outer scope - less chances to plant and hide an error.

blocks|key|240619|text|我发现，在编译时做的和检查的越多，在运行时出错的可能性就越小。因此，我尝试利用允许在编译时进行更严格检查的技术。这也是我研究模板元编程的原因之一。如果你做错了什么，它不会编译，因此永远不会离开你的办公桌(因此永远不会到达客户的办公桌)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240620|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I found that, the more is done and checked at compile time, the less can possibly go wrong at run-time. So I try to leverage techniques that allow stricter checking at compile-time. That's one of the reason I went into template-meta programming. If you do something wrong, it doesn't compile and thus never leaves your desk (and thus never arrives at the customer's).

blocks|key|1354126|text|在我开始测试之前，我发现了很多问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1354127|断言|offset|length|style|BOLD|1354128|entityMap^0|0|0|2|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I find many problems before i start testing at all using

asserts

blocks|key|1354249|text|从一开始就用实际的、真实的数据进行测试。而且测试不仅在编写代码时是必要的，而且应该在设计阶段的早期开始。找出你最糟糕的用例是什么样子，并确保你的设计可以处理它。如果您的设计即使与这些用例相比也感觉良好和优雅，那么它实际上可能是好的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1354250|自动化测试对于确保您编写的代码是正确的非常有用。但是，在开始编写代码之前，您必须确保构建的是正确的东西。|1354251|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Testing it with actual, realistic data from the start. And testing is necessary not only while writing the code, but it should start early in the design phase. Find out what your worst use cases will be like, and make sure your design can handle it. If your design feels good and elegant even against these use cases, it might actually be good.

Automated tests are great for making sure the code you write is correct. However, before you get to writing code, you have to make sure you're building the right things.

blocks|key|1354344|text|学习函数式编程在某种程度上有所帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1354345|1354346|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|F|8|@]|9|@]|A|$]]|$1|C|3|-4|5|6|7|G|8|@]|9|@]|A|$]]]|D|$]]

Learning functional programming helps somehow. 
<a href="http://book.realworldhaskell.org/read/" rel="nofollow noreferrer">HERE</a> 
<a href="http://learnyouahaskell.com/chapters" rel="nofollow noreferrer">Learn you a haskell for great good.</a>

blocks|key|4570689|text|模型-视图-控制器，以及任何可以自动进行单元测试的契约和接口。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4570690|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Model-View-Controller, and in general anything with contracts and interfaces that can be unit-tested automatically.

blocks|key|1542492|text|我同意这里的许多其他答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1542493|具体到C%2B%2B，使用'const‘并尽可能避免原始指针(支持引用和智能指针)帮助我在编译时发现错误。|1542494|此外，使用“无警告”策略有助于查找错误。|1542495|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I agree with many of the other answers here.

Specific to C++, the use of 'const' and avoiding raw pointers (in favor of references and smart pointers) when possible has helped me find errors at compile time.

Also, having a "no warnings" policy helps find errors.

blocks|key|4570908|text|我发现同龄人编程倾向于帮助避免许多愚蠢的错误，并且所有的时间都会产生揭示缺陷的讨论。另外，如果有人可以自由思考你为什么要做某件事，这会让一切变得更干净。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4570909|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I find peer progamming tends to help avoid a lot of the silly mistakes, and al ot of the time generates discussions which uncover flaws. Plus with someone free to think about the why you are doing something, it tends to make everything cleaner.

blocks|key|1542595|text|需求。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1542596|根据我的经验，拥有完整的需求是创建无bug软件的第一步。如果你不知道它应该做什么，你就不能写出完整和正确的软件。如果你不知道软件应该做什么，你就不能为它写正确的测试；你会错过相当多你应该测试的东西。此外，编写需求的简单过程可以帮助您充实需求。在编写第一行代码之前，您会发现很多问题和问题。|1542597|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Requirements.

From my experience, having full and complete requirements is the number one step in creating bug-free software. You can't write complete and correct software if you don't know what it's supposed to do. You can't write proper tests for software if you don't know what it's supposed to do; you'll miss a fair amount of stuff you should test. Also, the simple process of writing the requirements helps you to flesh them out. You find so many issues and problems before you ever write the first line of code.

blocks|key|1540579|text|代码审查；我个人在同事的代码中发现了很多错误，他们也在我的代码中发现了错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1540580|代码审查，早期和经常，将帮助您理解彼此的代码(这有助于维护)，并发现错误。|1540581|你越早发现bug，它就越容易修复。所以你要尽快去做这些事情。|1540582|当然，结对编程将这一点发挥到了极致。|1540583|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Code reviews; I've personally found lots of bugs in my colleagues' code and they have found bugs in mine.

Code reviews, early and often, will help you to both understand each others' code (which helps for maintenance), and spot bugs.

The sooner you spot a bug the easier it is to fix. So do them as soon as you can.

Of course pair programming takes this to an extreme.

blocks|key|240327|text|使用像IntelliJ这样的集成开发环境，它会在我编写代码时检查代码，并在编写代码时标记不可靠的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240328|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Using an IDE like IntelliJ that inspects my code as I write it and flags dodgy code as I write it.

blocks|key|4570966|text|单元测试，然后是连续集成。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4570967|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Unit Testing followed by Continious Integration.

blocks|key|240809|text|读书建议："Code+Complete“和"Release+it”是关于这个主题的两本必读书籍。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240810|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Book suggestions: "Code Complete" and "Release it" are two must-read books on this topic.

blocks|key|4571141|text|除了已经提到的事情之外，我相信C%2B%2B0x引入的一些特性将有助于避免某些bug。强类型枚举、for-in循环和删除对象的标准函数等特性浮现在脑海中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4571142|一般而言，强类型是最好的选择。|4571143|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In addition to the already mentioned things I believe that some features introduced with C++0x will help avoiding certain bugs. Features like strongly-typed enums, for-in loops and deleteing standard functions of objects come to mind.

In general strong typing is the way to go imho

blocks|key|1354632|text|在项目中保持编码风格的一致性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1354633|不仅仅是空格和制表符的问题，还有代码的使用方式。做事情总是有不止一种方法。当同样的事情在不同的地方以不同的方式完成时，它会使捕获常见错误变得更加困难。|1354634|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Coding style consistency across a project.

Not just spaces vs. tab issues, but the way that code is used. There is always more than one way to do things. When the same thing gets done differently in different places, it makes catching common errors more difficult.

blocks|key|1354701|text|这里已经提到过了，但我要再说一遍，因为我认为这还不够：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1354702|不必要的复杂性是好的工程的宿敌。|1354703|保持简单。如果事情开始看起来很复杂，停下来问问自己为什么，你可以做些什么来把问题分解成更小、更简单的部分。|1354704|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It's already been mentioned here, but I'll say it again because I believe this cannot be said enough:

Unnecessary complexity is the arch nemesis of good engineering.

Keep it simple. If things start looking complicated, stop and ask yourself why and what you can do to break the problem down into smaller, simpler chunks.

blocks|key|240759|text|雇佣测试/验证您软件的人员。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|240760|我们有一个人先使用我们的软件，然后再使用我们的客户。他发现了我们的自动化测试过程找不到的bug，因为他认为自己是客户，而不是软件开发人员。这个人也为我们的客户提供支持，因为他从客户的角度非常了解软件。无价的。|240761|entityMap^0|0|E|0|2S|3|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Hire someone that test/validate your software. 

We have a guy that use our software before any of our customer. He finds bugs that our automated tests processes do not find, because he thinks as a customer not as a software developper. This guy also gives support to our customers, because he knows very well the software from the customer point of view. INVALUABLE.

blocks|key|240969|text|各种各样的“痕迹”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240970|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

blocks|key|4571373|text|还没有提到的事情-当有半复杂的逻辑在进行时，尽可能准确地命名你的变量和函数(但不要太长)。这将使它们之间的交互以及与它们应该做的事情之间的不一致变得更加突出。你大脑中的“意义”或语言解析部分将会有更多的东西要抓住。我发现，在命名模糊的情况下，你的大脑会忽略真正存在的东西，看到的是/supposed+to/+be发生的事情，而不是实际发生的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4571374|此外，让代码干净，这有助于防止你的大脑变得模糊。|4571375|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Something not mentioned yet - when there's even semi-complex logic going on, name your variables and functions as accurately as you can (but not too long). This will make incongruencies in their interactions with each other, and with what they're supposed to be doing stand out better. The 'meaning', or language-parsing part of your brain will have more to grab on to. I find that with vaguely named things, your brain sort of glosses over what's really there and sees what is /supposed to/ be happening rather than what actually is. 

Also, make code clean, it helps to keep your brain from getting fuzzy.

blocks|key|4571424|text|测试驱动开发与结对编程相结合，在减少一些bug方面似乎工作得很好。及早创建测试有助于完成一些设计，并在其他人不得不使用代码时给出一些信心。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4571425|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Test-driven development combined with pair programming seems to work quite well on keeping some bugs down. Getting the tests created early helps work out some of the design as well as giving some confidence should someone else have to work with the code.

blocks|key|1540624|text|创建类状态的字符串表示，并将其打印到控制台。请注意，在某些情况下，单行字符串是不够的，您必须编写小的打印循环，这将创建类状态的多行表示。一旦你以这种方式“可视化”了你的程序，你就可以开始查找其中的错误了。当您知道哪个变量最后包含了错误的值时，很容易将断言放在这个变量被赋值或修改的任何地方。通过这种方式，您可以准确地指出错误的位置，并在不使用分步调试的情况下修复它(这是一种相当慢的查找错误的方式)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1540625|就在昨天，在没有调试一行的情况下，发现了一个非常讨厌的bug：|1540626|vector<string>+vec;
vec.push_back("test1");
vec.push_back(vec[0]);+//+second+element+is+not+"test1"+after+this,+it's+empty+string|code-block|syntax|javascript|1540627|我只是不断地放置断言语句并重新启动程序，直到程序状态的多行表示是正确的。|1540628|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Creating a string representation of class state, and printing those out to console.
Note that in some cases single line-string won't be enough, you will have to code small printing loop, that would create multi-line representation of class state.
Once you have "visualized" your program in such a way you can start to search errors in it. When you know which variable contained wrong value in the end, it's easy to place asserts everywhere where this variable is assigned or modified. This way you can pin point the exact place of error, and fix it without using the step-by-step debugging (which is rather slow way to find bugs imo). 

Just yesterday found a really nasty bug without debugging a single line:

<pre><code>vector&lt;string&gt; vec;
vec.push_back("test1");
vec.push_back(vec[0]); // second element is not "test1" after this, it's empty string
</code></pre>

I just kept placing assert-statements and restarting the program, until multi-line representation of program's state was correct.

I don't mean external tools. I think of architectural patterns, language constructs, habits. I am mostly interested in C++

Which programming technique helps you most to avoid or resolve bugs before they come into production

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我不是指外部工具。我想到的是架构模式，语言结构，习惯。我最感兴趣的是C++

问哪种编程技术最能帮助您在进入生产环境之前避免或解决bug
EN

回答 28

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪种编程技术最能帮助您在进入生产环境之前避免或解决bugEN

回答 28

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪种编程技术最能帮助您在进入生产环境之前避免或解决bug
EN