RF: References

Many coding standards, rules, and guidelines have been written for C++, and especially for specialized uses of C++. Many

  • focus on lower-level issues, such as the spelling of identifiers
  • are written by C++ novices
  • see "stopping programmers from doing unusual things" as their primary aim
  • aim at portability across many compilers (some 10 years old)
  • are written to preserve decades old code bases
  • aim at a single application domain
  • are downright counterproductive
  • are ignored (must be ignored by programmers to get their work done well)

A bad coding standard is worse than no coding standard. However an appropriate set of guidelines are much better than no standards: "Form is liberating."

Why can't we just have a language that allows all we want and disallows all we don't want ("a perfect language")? Fundamentally, because affordable languages (and their tool chains) also serve people with needs that differ from yours and serve more needs than you have today. Also, your needs change over time and a general-purpose language is needed to allow you to adapt. A language that is ideal for today would be overly restrictive tomorrow.

Coding guidelines adapt the use of a language to specific needs. Thus, there cannot be a single coding style for everybody. We expect different organizations to provide additions, typically with more restrictions and firmer style rules.

Reference sections:

RF.rules: Coding rules

  • Boost Library Requirements and Guidelines. ???.
  • Bloomberg: BDE C++ Coding. Has a strong emphasis on code organization and layout.
  • Facebook: ???
  • GCC Coding Conventions. C++03 and (reasonably) a bit backwards looking.
  • Google C++ Style Guide. Geared toward C++03 and (also) older code bases. Google experts are now actively collaborating here on helping to improve these Guidelines, and hopefully to merge efforts so these can be a modern common set they could also recommend.
  • JSF++: JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS. Document Number 2RDU00001 Rev C. December 2005. For flight control software. For hard real time. This means that it is necessarily very restrictive ("if the program fails somebody dies"). For example, no free store allocation or deallocation may occur after the plane takes off (no memory overflow and no fragmentation allowed). No exception may be used (because there was no available tool for guaranteeing that an exception would be handled within a fixed short time). Libraries used have to have been approved for mission critical applications. Any similarities to this set of guidelines are unsurprising because Bjarne Stroustrup was an author of JSF++. Recommended, but note its very specific focus.
  • Mozilla Portability Guide. As the name indicates, this aims for portability across many (old) compilers. As such, it is restrictive.
  • Geosoft.no: C++ Programming Style Guidelines. ???.
  • Possibility.com: C++ Coding Standard. ???.
  • SEI CERT: Secure C++ Coding Standard. A very nicely done set of rules (with examples and rationales) done for security-sensitive code. Many of their rules apply generally.
  • High Integrity C++ Coding Standard.
  • llvm. Somewhat brief, pre-C++11, and (not unreasonably) adjusted to its domain.
  • ???

RF.books: Books with coding guidelines

RF.C++: C++ Programming (C++11/C++14)

RF.web: Websites

RS.video: Videos about "modern C++"

RF.man: Manuals

Acknowledgements

Thanks to the many people who contributed rules, suggestions, supporting information, references, etc.:

  • Peter Juhl
  • Neil MacIntosh
  • Axel Naumann
  • Andrew Pardoe
  • Gabriel Dos Reis
  • Zhuang, Jiangang (Jeff)
  • Sergey Zubkov

and see the contributor list on the github.

Copyright © trree.github.io 2017 all right reserved，powered by Gitbook该文件修订时间： 2017-04-13 12:57:30

results matching ""

    No results matching ""