So I want to add an explanation. As I see from the comments, many of you thought that the PVS-Studio analyzer warns about a function's unused argument. That's not quite so. Or, to be precise, this is so, but the analyzer processes this case smarter than most linters or compilers. Continue: https://karpov2007.medium.com/a-few-more-words-about-the-pvs...

If a diagnostic issues warnings to unused arguments - it's a weak diagnostic. PVS-Studio acts differently. Take a look at my clarifying comment below or above (not sure where it would be when you read it).

So I want to add an explanation. As I see from the comments, many of you thought that the PVS-Studio analyzer warns about a function's unused argument. That's not quite so. Or, to be precise, this is so, but the analyzer processes this case smarter than most linters or compilers.

It's a bad idea to program an analyzer so that it just issues a warning to unused arguments. Such analyzer would produce many false positives, which is why many developers don't look at (or disable) these warnings in their compilers/analyzers.

The PVS-Studio analyzer implements sort of empirical "magic". PVS-Studio relies on the fact that there are arguments of the same type and some of them are not used, while the other ones are used several times. At the same time, there are a number of exceptions to the rule. For example, the diagnostic is not triggered if the number of unused arguments exceeds two.

All this allows the V751 diagnostic to issue few false positives, which makes the tool surpass its competitors. To be exact, when developing PVS-Studio, we do not implement rules if we cannot make them better than those of the compilers - https://pvs-studio.com/en/blog/posts/0802/ . Thanks to the diagnostic I described above, one can find interesting errors - https://pvs-studio.com/en/blog/examples/v751/ .

P.S. The PVS-Studio analyzer also provides a "stupid" version of this diagnostic - V2537 https://pvs-studio.com/en/docs/warnings/v2537/ . It was developed to check code against MISRA C and MISRA C++ standards. But the case above was special and by default this diagnostic was disabled - same as the other ones related to MISRA.

Reddit discussion: https://www.reddit.com/r/linux/comments/59hba7/cc_static_cod...

Article: http://www.viva64.com/en/b/0392/

PHP Source: https://github.com/php/php-src

1. Don't do the compiler's job

2. Larger than 0 does not mean 1

3. Copy once, check twice

4. Beware of the ?: operator and enclose it in parentheses

5. Use available tools to analyze your code

6. Check all the fragments where a pointer is explicitly cast to integer types

7. Do not call the alloca() function inside loops

8. Remember that an exception in the destructor is dangerous.

9. Use the '\0' literal for the terminal null character

10. Avoid using multiple small #ifdef blocks

11. Don't try to squeeze as many operations as possible in one line

12. When using Copy-Paste, be especially careful with the last lines

13. Table-style formatting

14. A good compiler and coding style aren't always enough

15. Start using enum class in your code, if possible

16. "Look what I can do!" - Unacceptable in programming

17. Use dedicated functions to clear private data

18. The knowledge you have, working with one language isn't always applicable to another language

19. How to properly call one constructor from another

20. The End-of-file (EOF) check may not be enough

21. Check that the end-of-file character is reached correctly (EOF)

22. Do not use #pragma warning(default:X)

23. Evaluate the string literal length automatically

24. Override and final specifiers should become your new friends.

25. Do not compare 'this' to nullptr anymore

26. Insidious VARIANT_BOOL

27. Guileful BSTR strings

28. Avoid using a macro if you can use a simple function

29. Use a prefix increment operator (++i) in iterators instead of a postfix (i++) operator

30. Visual C++ and wprintf() function

31. In C and C++ arrays are not passed by value

32. Dangerous printf

33. Never dereference null pointers

34. Undefined behavior is closer than you think

35. Adding a new constant to enum don't forget to correct switch operators

36. If something strange is happening to your PC, check its memory.

37. Beware of the 'continue' operator inside do {...} while (...)

38. Use nullptr instead of NULL from now on

39. Why incorrect code works

40. Start using static code analysis

41. Avoid adding a new library to the project.

42. Don't use function names with "empty"

Issues are reported to the team https://github.com/dotnet/corefx/issues/5118

Presentation (EN): http://www.slideshare.net/Andrey_Karpov/200-open-sourceproje...

Not so simple. Review John Carmack article: http://gamasutra.com/view/news/128836/InDepth_Static_Code_An...