Invalid null pointers can either be caused by programmer error or by runtime error. Runtime errors are something a programmer can't fix, like a malloc failing due to low memory or the network dropping a packet or the user entering something stupid. Programmer errors are caused by a programmer using the function incorrectly.
The general rule of thumb I've seen is that runtime errors should always be checked, but programmer errors don't have to be checked every time. Let's say some idiot programmer directly called graph_get_current_column_color(0). It will segfault the first time it's called, but once you fix it, the fix is compiled in permanently. No need to check every single time it's run.
Sometimes, especially in third party libraries, you'll see an assert to check for the programmer errors instead of an if statement. That allows you to compile in the checks during development, and leave them out in production code. I've also occasionally seen gratuitous checks where the source of the potential programmer error is far removed from the symptom.
Obviously, you can always find someone more pedantic, but most C programmers I know favor less cluttered code over code that is marginally safer. And "safer" is a subjective term. A blatant segfault during development is preferable to a subtle corruption error in the field.
Put another way, you're asking if you should jump-start your team's coding standards by borrowing external standards that you've found. It doesn't sound like anyone on the team has super-strong opinions (yet) on what those standards should be.
Unequivocally, the answer is yes.
An externally sourced standard is superior to nothing. Look at the answers in "https://softwareengineering.stackexchange.com/q/84203/53019" in order to see some of the advantages for having a standard. Consistency and having a basis to change from are critical from your point of view.
Also have a look at "Handling Coding Standards at Work (I'm not the boss)" as it goes into some of the team dynamics that your team needs to consider when selecting what the standard(s) should be. The team needs to own their coding standard(s) so everyone willingly complies with the restrictions it places upon how each person codes.
You linked to this question, but it's worth pointing out the top answer and its focus on understanding why the requirements are in place. If you use an external standard, it will be hard for your team to understand the basis behind all of those requirements. But if you accept that they are there simply because your team needed something to start with, then it's easy to move on to changing that external standard to something that works better for your team.
Having any standard in place allows your to populate the formatting rules you'll use with your IDE (Eclipse in your case). "Advantages and Disadvantages of Forced Code Reformat" goes into the benefits for everyone on the team for having that consistency with the code they are working on, and gives you the ability to reformat snippets you may borrow from other projects. An added bonus of using an external standard is that it may already be pre-populated in the code formatting portion of your IDE.
Someone on the team will likely complain about a particular portion of the standard and will blame it on the fact that you used an external standard as the base. Have them read over:
- I hate one of our coding standards and it drives me insane, how to process it?
- How do you overcome your own coding biases when handed legacy code?
and then realize they likely would have complained about something within the standard no matter where it came from. Across the number of teams I have worked on, I have yet to see a standard that everyone a) universally liked and b) agreed with every portion of the standard. Reference back to some of the early links to see how to deal with those concerns.
Addendum, you asked about "which one" you should use. I'm specifically not going to answer that as any answer is potentially frought with opinion fueled flame wars. However, you could look at your IDE (Eclipse) and see what options it provides as standard configuration. I'd also search a bit and see if there are any projects that plugin to your IDE and provide additional standards options to pick from. Right or wrong, those standards are already populated for you and can save your team a chunk of work in configuring it for everyone.
Best Answer
It is basically the way standard C++ is intended and encouraged (by the committee and the community) to be used:
This is what we have been calling "modern C++" for almost 10 years now. But most C++ developers start only now to realize it makes code looks like there is not much need for raw pointers, writing new/delete, and other error-prone constructs.
Now these constructs (C or not) are still there both for retrocompatibilty and for allowing you to write libraries to, again, free the other developers from having to play with them. Also, C should be used to interface with C libraries, for low level constructs that require C-style code. Any other case, you can avoid using C idioms when you have C++ available.
For clarification: using C style doesn't improve performance (assuming you understand C++ constructs and RAII). In fact, a lot of algorithms written in C++ are faster than the same in C, just because C++ give more info to the compiler to make him optimize in calling context (I'm thinking about template algorithms/types for example).
So performance is not necessarily a valid reason to use C idioms when you write C++.