The Ultimate Question of Programming, Refactoring, and Everything

By Andrey Karpov | Apr 14, 2016 05:25 AM | Tags: refactoring intermediate c++11 bugs book basics advanced

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort.

The Ultimate Question of Programming, Refactoring, and Everything

by Andrey Karpov

From the article:

The scope of my interests − the C/C++ language and the promotion of code analysis methodology. I have been Microsoft MVP in Visual C++ for 5 years. The main aim of my articles and work in general - is to make the code of programs safer and more secure. I'll be really glad if these recommendations help you write better code, and avoid typical errors. Those who write code standards for companies may also find some helpful information here.

New updates of CppHints.com, service of recommendations on C++ programming from PVS-Studio team

By Andrey Karpov | Nov 2, 2015 06:03 AM | Tags: intermediate errors bugs basics

New updates of C++Hints, service of recommendations on C++ programming

Changes in CppHints.com

by PVS-Studio Team

We got a lot of positive feedback from our readers and continue developing the C++Hints project. We have also answered two requests, that we saw quite often in the letters:

• The RSS feed is added (http://cpphints.com/rss)
• The up-to-date full list of hints is created at: http://cpphints.com/archive

By this moment we have published the following articles:

• Why incorrect code works
• Don't forget that the loop termination conditions are always evaluated completely
• Undefined behavior is closer than you think
• Visual C++ and wprintf() function
• Use a prefix increment operator (++i) in iterators instead of a postfix (i++) operator
• Avoid using a macro if you can use a simple function
• Don't name functions "empty"
• Hot on the heels
• Make your code more stable
• Insidious VARIANT_BOOL
• Do not compare 'this' to nullptr anymore
• Use the keyword "override" when overriding virtual functions
• Evaluate the string literal length automatically
• Do not use #pragma warning(default:X)
• Table-style formatting (continuation)
• Make sure you work with data in streams the right way
• Delegating constructors make life easier
• Use dedicated functions to clear private data
• Table-style formatting
• Don't spare code lines
• Start using enum class in your code, if possible
• A good compiler and coding style aren't always enough
• When using Copy-Paste, be especially careful with the last lines
• Don't try to squeeze as many operations as possible in one line
• Use the '\0' literal for the terminal null character
• Avoid using multiple small #ifdef blocks
• Beware of throwing exceptions in destructors
• Check all the fragments where a pointer is explicitly cast to integer types
• Do not call the alloca() function inside loops
• Don't Do the Compiler's Job
• Use available tools to analyze your code
• Larger than 0 does not mean 1
• Copy once, check thrice
• Beware of the ?: operator and enclose it in parentheses

The compiler is to blame for everything -- Andrey Karpov

By Andrey Karpov | Jun 4, 2015 11:48 PM | Tags: errors compilers compiler bugs basics

Many programmers are very fond of blaming the compiler for different errors. Let's talk about it.

The compiler is to blame for everything

by Andrey Karpov

From the article:

When a programmer tells you that the compiler causes an error, it is a lie in 99% of cases. When you start investigating the problem, you usually find out the following reasons:

• an array overrun;
• an uninitialized variable;
• a misprint;
• a synchronization error in a parallel program;
• a non-volatile variable used;
• code leading to undefined behavior;
• etc.