A coding standard is a set of rules that programmers can adopt to make their code more readable, uniform, and robust. For example, the Jet Propulsion Laboratory has a coding standard for C that includes recommendations like
- Compile with all warnings enabled; use static source code analyzers.
- Use verifiable loop bounds for all loops meant to be terminating.
- Do not use direct or indirect recursion.
- Check the validity of values passed to functions.
JPL considers these rules to be essential to producing safe and reliable code for space missions. Many of the rules specifically target memory safety issues in C, and they are helpful. However, the idea that coding standards can make C/C++ memory safe is, unfortunately, incorrect.
Consider what the Standard C++ Foundation has to say about coding standards:
The main point of a C++ coding standard is to provide a set of rules for using C++ for a particular purpose in a particular environment. It follows that there cannot be one coding standard for all uses and all users. For a given application (or company, application area, etc.), a good coding standard is better than no coding standard. On the other hand, we have seen many examples that demonstrate that a bad coding standard is worse than no coding standard. Please choose your rules with care and with solid knowledge of your application area. Some of the worst coding standards (we won’t mention names “to protect the guilty”) were written by people without solid knowledge of C++ together with a relative ignorance of the application area (they were “experts” rather than developers) and a misguided conviction that more restrictions are necessarily better than fewer.
…
A word of warning: Nearly every software engineer has, at some point, been exploited by someone who used coding standards as a “power play.” Dogmatism over minutiae is the purview of the intellectually weak. Don’t be like them. These are those who can’t contribute in any meaningful way, who can’t actually improve the value of the software product, so instead of exposing their incompetence through silence, they blather with zeal about nits. They can’t add value in the substance of the software, so they argue over form. Just because “they” do that doesn’t mean coding standards are bad, however.
Another emotional reaction against coding standards is caused by coding standards set by individuals with obsolete skills. For example, someone might set today’s standards based on what programming was like N decades ago when the standards setter was writing code. Such impositions generate an attitude of mistrust for coding standards. As above, if you have been forced to endure an unfortunate experience like this, don’t let it sour you to the whole point and value of coding standards. It doesn’t take a very large organization to find there is value in having consistency, since different programmers can edit the same code without constantly reorganizing each others’ code in a tug-of-war over the “best” coding standard.
This little excerpt tells you the only two things you need to know about coding standards:
- Programmers are arrogant
- Coding standards are power struggles
The upshot is that it is impossible to get all programmers in the world to follow a consistent coding standard. It’s possible to get fairly large groups of programmers to follow a coding standard when imposed from above (works best if you are Bill Gates), but there’s no authority that can force all C/C++ programmers in the world to abide by a voluntary set of restrictions.
The only practial way to ensure that every program in a language is memory safe is to build that into the language itself: it cannot be optional.