I\'ve heard that the automotive industry has something called MISRA C.
What are the relevant standards for other high reliability/availability/security industries, such
NIST provides a whole slew of related documents, you can dive in and peruse their work - but there is a lot of it, and it's all quite verbose, so I dont have a specific one to point you at.
If you want to be more specific with your needs, I might be able to narrow it down a bit...
In addition, Carnegie Mellon is pretty much the definitive when it comes to development processes for reliability, easy enough to find their standards but also quite verbose.
Also, specific industries often have their own standards, depending also on the country. For instance, credit card industry - PCI-DSS; Banking industry in EU - Basel II; Medical - HIPAA (though thats pretty high-level); anything US government related, various NIST docs; etc.
Check out the Goddard Space Flight Center and its coding standards. One of the C standards, which I've adopted in my own code, is that headers must be self-contained, and they provide a simple way to enforce that -- a module's header must be the first file included in the module, so if the file is not self-contained, it won't compile.
FDA has General Principles of Software Validation, Design Control Guidance For Medical Device Manufacturers, Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices, etc.
For programming high reliability systems in Ada, there is: ISO/IEC TR 15942:"Information technology — Programming languages — Guide for the use of the Ada programming language in high integrity systems":
Introduction
As a society, we are increasingly reliant upon high integrity systems: for safety systems (such as fly-by-wire aircraft), for security systems (to protect digital information) or for financial systems (e.g., cash dispensers). As the complexity of these systems grows, so do the demands for improved techniques for the production of the software components of the system. These high integrity systems must be shown to be fully predictable in operation and have all the properties required of them. This can only be achieved by analysing the software, in addition to the use of conventional dynamic testing. There is, currently, no mainstream high level language where all programs in that language are guaranteed to be predictable and analysable. Therefore for any choice of implementation language it is essential to control the ways that the language is used by the application. The Ada language [ARM] is designed with specific mechanisms for controlling the use of certain aspects of the language. Furthermore,
The semantics of Ada programs are well-defined, even in error situations. Specifically, the effect of a program can be predicted from the language definition with few implementation dependencies or interactions between language features.
The strong typing within the language can be used to reduce the scope (and cost) of analysis to verify key properties.
The Ada language has been successfully used on many high integrity applications. This demonstrates that validated Ada compilers have the quality required for such applications.
Guidance can be provided to facilitate the use of the language and to encourage the development of tools for further verification.
Ada is therefore ideally suited for implementing high integrity software and this document provides guidance in the controls that are required on the use of Ada to ensure that programs are predictable and analysable.
You may find it instructive to look at some of the requirements of Carrier Grade Linux. While they (as the name suggests!) are specifying linux requirements, they are doing so for use in the high availability segment of telecommunications equipment.
if you're asking specifically about coding, the MISRA presents some guidelines for avoiding common mistakes in C.
however, there's a lot more to good software than coding. The "bible" of the aviation industry for sw development is DO-178B. It tells you what questions need to be addressed in the various design phases and how the answers should be documented. It's an ENORMOUS amount of paperwork, but if you're trying to keep planes in the air, you want the weakest point to be the human (pilot), not the software.