老顾的记录

这个覆盖大部分语言，避免使用在所有情况中使用0，这样就能让代码更容易理解，并且更容易发现错误。下面是一些技巧：- 0 - 只使用在需要整型值0的情况；- nullptr - 作为C++的null指针；- NULL - 作为C的null指针；- `\0`，L`\0`，_T`\0` - 作为字符串结尾符；- 0.0，0.0f - 作为浮点值的0；- false，FALSE - 作为false；

如果遇到有些编程问题需要详细的了解相关文档的每一个部分，才能避免问题怎么办？去看文档吗？sorry，你得花费很多时间去看，这样就不能保证你有足够的时间去完成编程了。只有一个建议，就是直接用工具，比如PSV-Studio的静态分析器。当着这里作者好像忘了DllMain其实可以检测到被应用程序加载的状态，可以通过不同状态，调用不同的函数。

这篇是讲指针的，特别是从32位平台移到64位平台指针容易引发的一些问题，讲的有些深，所以除了对于一些资深的原生开发者而言，现在大部分的程序员都看不懂，当然这些非原生的程序员而言，看不懂也没有关系，他们不需要懂——他们都看不到指针了。

EOF，文件结束符，通常值为0xFF，转换成char型，值就是-1，所以很多程序员就会理所当然把-1当成文件结束符。这样的问题在于，某些国家的字母表，其中0xFF也给赋予了特定的字母，然后我们再理所当然的使用-1作为EOF判断是，错误就产生了。

从一个语言抽象出来的经验不一定适用于另外一个语言，比如Pascal和C/C++

当在一个类实例化时，在其一构造函数中调用其另外的构造函数，好吧，一些不可控的事情就发生了——C++的构造函数还有这些奇怪的东西可以挖掘。C++11也有了新的解决方案。

C++ 11中有很多新特性，绝大多数特性带来了便利的同时，也或多或少的带来了新的问题，比如auto关键字，但enum class绝对是个好东西，使得原来编译器不做类型检查的枚举类型，有了强类型检查的属性。

类似memset之类的函数重要吗？从编译器来看，其实不重要，因为在执行优化选项后，很有可能编译器会把觉得没有必要的memset函数调用去除。还是使用专用的数据清理函数吧，比如memset_s等。

对于文件流的读，光使用eof方面的函数做检查还不够，因为流中可能会发生错误。在Java/C#等语言中可以使用try...catch机制，但对于C/C++能，除了bad()和fail()等方法外，还有bool()操作符。

?:三元运算符的使用，其实因为其优先级很低，所以容易导致很多错误，所以把相关表达式用括号保护起来，可以避免很多容易发生的错误。

凡事预则立，类似因为使用复制代码产生的问题，相当多都很难发现，一般只有通过code review或者debug才能发现，因为一般编译器都不会报错，然后其实只有一个字母或者数字错了。PSV-Studio能发现这类问题，的确挺牛的。另外学会一句英文谚语： forewarned is forearmed，即：凡事预则立。

当不相同时，memcmp()函数返回大于0或小于0，而非1或-1，就是这么简单的错误，导致了MySQL/MariaDB前几年的主要几个发布版本都出现了安全漏洞，即黑客无须知道密码，就可以获得root管理权限。而且就我观察而言，这个问题非常普遍，相当多的程序里都有这个问题。

用表格化的方式格式化一些条件判断或者用数组初始化的语句块，并且把操作符或者分隔符按照左侧对齐，可以让代码更漂亮、更直观，更重要的是，可以更快的找到代码。

的确，当连续的代码块大部分类似时，我们会使用复制黏贴来加快编码速度，然后再手动修改每一块不一样的地方，但是——我的经验也是——我们会在最后一行犯错误。作者还严谨的做了统计，不止你、不止我，而是大部分程序员都会容易在最后一行犯错。

写出很酷炫的代码的确很牛逼，但你知不知道，这样的代码容易犯错，而且不容易维护。所以写代码是，切忌装逼。

即使再专业的程序员，也难以避免犯一些愚蠢的输入错误，这些错误很多时候即使使用再好的编译器以及优秀的编码风格，也不能避免，这个时候，我们需要综合各种方法：代码审查；单元测试；手动测试；静态代码分析；等等……

alloca()函数在线程的堆栈中分配内存，所以如果在循环中调用alloca()很危险，容易导致栈内存的溢出。有很多方法可以避免，比如使用循环内的栈变量替代（进入和退出范围会自动释放），或者在堆上分配（使用malloc或者new，但需要自己释放）。

对于异常，我在C++和Java中用的都不多，现在ES6的Node.js中因为使用了generator、Promise和co的同步化异步操作，不得不使用异常，但这个异常和传统的异常不一致。传统异常，特别是Java，往往会被那些懒惰的程序员们滥用，就像滥用延迟垃圾回收（完全不管内存的事情）。今天翻译的这节文章中，就说明了异常使用的一个禁区：一般不要再析构函数中抛出异常。当然，因线程栈释放抛出异常产生的问题还不止于此。

嗨，我是Andrey Karpov，我的主要兴趣领域在C/C++编程以及对应的代码分析提升方法论我曾连续5年当选微软的Visual C++ MVP。总体而言，我所写的文章以及我的工作，主要就是为了提升程序代码的可靠性和安全性。如果这些规则能帮助你写出更好的代码，并且避免典型的错误，我将会感到非常开心。那些在公司制定编码规范的朋友也能在其中发现很多有价值的东西。

所以，我的建议是——写简单且易读的代码。这里有个规则：简单的代码通常就是正确的代码。不要尝试去做编译器的活——比如去展开循环。编译器无须你的帮助，就可以把绝大多数事情做好。这样的人工优化工作一般只有在少数特定极端的代码段才有效，特别是只有在确认这段代码执行真有的有问题（慢）的情况

一般程序员估计很少使用#pragma warning(default:X)之类的指令，但其实这些指令在复杂的编译系统中很有用，但要小心哦，使用好也不容易。

这应该算是C/C++的福气呢？还是缺点呢？计算字符串的长度都有这么多文章。我觉得看具体情况吧。至少C/C++给了程序员最大程度的可控空间以及各种各样的手段。

使用的空指针，如果只是赋值，后面判断后再决定是否使用，部分程序员可能会觉得应该没事，但其实还有一定几率引发不可预知的行为，包括程序崩溃，为什么呢？你想过没有，也许你的编译器会做优化，比如把判断去除了……

如果你的程序不能运行，99.99%的原因可能是你的代码引起的；除此之外，剩余的0.01%，还有可能是海森堡bug、编译器以及硬件内存。

十分推荐看这篇，因为无论新手还是老手，可能都会忽略continue在do {...} while (...)中潜藏的风险。十分同意作者说的：好的程序员，不是那种炫耀很多不同编程语言技巧的，而是那种能写出清晰、易理解、甚至可以让一个新手都能看懂其代码的。

使用NULL表示空指针？似乎成为C/C++的常识，但NULL常会带来一些愚蠢而且难以发现的问题，我自己这么多年编程经历中就遇到。用nullptr吧，不要再用NULL了，为什么，看文内。

程序员最大的困境，其实不是技术如何难实现，或者产品经理如何胡说八道，而是自己力求实现的理想中的通用性、扩展性和现实的需求以及项目实际发展的南辕北辙。对于项目中使用的库，尤其如此。那些沧桑的程序员可以秒懂，新生的呢？还需要经历别人走过的路……

我特别在意函数的名字，因为合适的函数名字不光能让人一下子知道这个函数的大概目的，还能简单知道如何使用这个函数。对于强迫症程序员而言，函数的命名更是一个头疼的问题：）

翻译《有关编程、重构及其他的终极问题？》——尾声标签（空格分隔）： 翻译 技术 C/C++作者：Andrey Karpov翻译者：顾笑群 - Rafael Gu校验者：高国栋最后更新：2018年10月01日##尾声我希望你喜欢这些技巧。当然，不可能写出所有错误编写程序的方法，而且这样做可能没有任何意义。我的目标是警告一个程序员，并培养一种危机感。也许，下一次当程序员遇到一些奇怪的事...

有时候，明明包含有错误的代码，但程序还是照常运行，老程序员秒懂：）这篇就举了个例子。另外，不要使用太复杂的表达式，避免不必要的麻烦。

常用的printf等函数，如果用不好，不光是程序会出问题，还会留下安全隐患，可能被某些人攻击

读了这篇文章，除了你可以知道为何使用size_t轮询数组更好，而不是使用其他外，还能知道你自己的汇编有多弱。另外，这篇和前面一篇的部分，作者好像是生气的写的，应该是被很多人怼了之后写的吧：）

一天，一位我并不认识的俄罗斯姑娘联系我，问我是否愿意把一些有关编程的文章编程成中文，并且在中国推广，我说先看看大概是什么文章再说，她就给我发了一个链接，我发现是一些C/C++等语言如何避免bug，如何高效编程的系统整理后的长文，就觉得每周翻译一些的这样的英文编程文章也还不错，就同意了。她问我翻译的酬劳是多少，我说随他们给——其实我的态度是：每个周末休息时翻译些有趣的技术文章也应该不错，有酬劳更好，没有也没有关系。

好像是借鉴了Java和C#的有点，C++ 11中也多了override和final关键字，这样在使用重载时C++类的二意性和可重载性更可控了，我觉得不错。

BOOL类型中TRUE的定义是多少？在C++中，有的时1，有的是0，还有的是-1……所以在出来一个不熟悉的新类型时，最好看一下实际定义的值范围。

在C++发展早期，因为一些原因，this指针有可能是0/NULL/nullptr，所以如果你对老的C++代码进行考古研究，会有if (this == NULL)这种比较的语句；新的C++规范中，this指针不可能为空，所以没有必要在进行这些比较了。

随着10多年前COM被微软放弃，对应的BSTR其实也很少用到了，所以这篇文章本身来说对现在的意义不大了。

在C/C++中，还是要减少对宏的依赖，虽然宏有时候也很有用。

很多C/C++程序员都知道++i和i++的区别，但在迭代器上，这个区别就更大了，甚至到了影响性能的地步。

关于字符的各种编码方式，我始终觉得是任何程序员的一个基础知识，另外不同平台上也需要注意不同的对应处理函数。