Post History

To extend a bit on some points already mentioned:

Regarding where to add checks on a case by case basis: If you have a static code analysis tool that can give you information about areas where provably no null pointer will be passed / no undefined behavior can occur, you can omit the checks in these areas.  (Most tools will indicate if they find a problem, but if they don't report something you are still not sure if there is provably none or if only the tool's analysis depth was exceeded - PolySpace is one example for a tool that can provide you that more precise information.)  Obviously, that only works if you have the full program code available or are looking at some `static` function.

Regarding the possibility mentioned by @chqrlie to use a configurable approach as with assertions (assuming some assertion concept adapted to your situation): Assertions are obviously a run-time mechanism to detect issues, but they are also beneficial for readers of your code - as well as for many static analysis tools that can use them to improve their analysis.  (Well, the de-referencing of a `null` pointer will be detected anyway by the analysis tools, but there will likely be more general function argument checks also...)

Regarding weighing the pros and cons: In addition to weighing the pros and cons for adding checks for the code in the field, one should also think about the pros and cons of having the checks in different development scenarios, like, static code analysis, code reviews, unit-testing, integration-testing on different levels, ... - the fact that typically in some of these cases you want the checks while you don't want them in others often makes a configurable approach desirable.