GNU的C++代码书写规范,C语言之父Dennis Ritchie亲自修订

原创 2002年02月01日 16:58:00
C++ Standard Library Style Guidelines  DRAFT 1999-02-26

This library is written to appropriate C++ coding standards.  As such,
it is intended to precede the recommendations of the GNU Coding
Standard, which can be referenced here:

ChangeLog entries for member functions should use the
classname::member function name syntax as follows:

1999-04-15  Dennis Ritchie  <>

* src/ (__basic_file::open): Fix thinko in

Notable areas of divergence from what may be previous local practice
(particularly for GNU C) include:

01. Pointers and references
  char* p = "flop";
  char& c = *p;
  char *p = "flop";  // wrong
  char &c = *p;      // wrong
    Reason: In C++, definitions are mixed with executable code.  Here,      
    p          is being initialized, not *p.  This is near-universal
            practice among C++ programmers; it is normal for C hackers
            to switch spontaneously as they gain experience.

02. Operator names and parentheses
  operator == (type)  // wrong
    Reason: The == is part of the function name.  Separating
            it makes the declaration look like an expression.

03. Function names and parentheses
  void mangle()
  void mangle ()  // wrong

     Reason: no space before parentheses (except after a control-flow
     keyword) is near-universal practice for C++.  It identifies the
     parentheses as the function-call operator or declarator, as
     opposed to an expression or other overloaded use of parentheses.

04. Template function indentation
  template<typename T>
    { }
  template<class T>
  void template_function(args) {};
     Reason: In class definitions, without indentation whitespace is
             needed both above and below the declaration to distinguish
     it visually from other members.  (Also, re: "typename"
     rather than "class".)  T often could be int, which is
     not a class.  ("class", here, is an anachronism.)

05. Template class indentation
  template<typename _CharT, typename _Traits>
    class basic_ios : public ios_base
      // Types:
  template<class _CharT, class _Traits>
  class basic_ios : public ios_base
      // Types:
  template<class _CharT, class _Traits>
    class basic_ios : public ios_base
      // Types:

06. Enumerators
    space = _ISspace,
    print = _ISprint,
    cntrl = _IScntrl,
  enum { space = _ISspace, print = _ISprint, cntrl = _IScntrl };

07. Member initialization lists
   All one line, separate from class name.

  : _M_private_data(0), _M_more_stuff(0), _M_helper(0);
  { }
  gribble::gribble() : _M_private_data(0), _M_more_stuff(0), _M_helper(0);
  { }

08. Try/Catch blocks
  try {
  catch(...) {
  try { // } catch(...) { // }

09. Member functions declarations and defintions
   Keywords such as extern, static, export, explicit, inline, etc
   go on the line above the function name. Thus

  virtual int  
  virtual int foo()

Reason: GNU coding conventions dictate return types for functions
     are on a separate line than the function name and parameter list
     for definitions. For C++, where we have member functions that can
.    be either inline definitions or declarations, keeping to this
     standard allows all member function names for a given class to be
aligned to the same margin, increasing readibility.

10. Invocation of member functions with "this->"
   For non-uglified names, use this->name to call the function.


The library currently has a mixture of GNU-C and modern C++ coding
styles.  The GNU C usages will be combed out gradually.

Name patterns:

For nonstandard names appearing in Standard headers, we are constrained
to use names that begin with underscores.  This is called "uglification".
The convention is:

  Local and argument names:  __[a-z].*

    Examples:  __count  __ix  __s1 

  Type names and template formal-argument names: _[A-Z][^_].*

    Examples:  _Helper  _CharT  _N

  Member data and function names: _M_.*

    Examples:  _M_num_elements  _M_initialize ()

  Static data members, constants, and enumerations: _S_.*

    Examples: _S_max_elements  _S_default_value

Don't use names in the same scope that differ only in the prefix,
e.g. _S_top and _M_top.  See BADNAMES for a list of forbidden names.
(The most tempting of these seem to be and "_T" and "__sz".)

Names must never have "__" internally; it would confuse name
unmanglers on some targets.  Also, never use "__[0-9]", same reason.


#ifndef  _HEADER_
#define  _HEADER_ 1

namespace std
  class gribble
    // ctor, op=, dtor
    gribble() throw();

    gribble(const gribble&);

    gribble(int __howmany);

    operator=(const gribble&);

    ~gribble() throw ();

    // argument
    inline void 
    public_member(const char* __arg) const;

    // in-class function definitions should be restricted to one-liners.
    one_line() { return 0 }

    two_lines(const char* arg)
      { return strchr(arg, 'a'); }

    inline int
    three_lines();  // inline, but defined below.

    // note indentation
    template<typename _Formal_argument>
      public_template() const throw();

    template<typename _Iterator>

    class _Helper;

    int _M_private_data;
    int _M_more_stuff;
    _Helper* _M_helper;
    int _M_private_function();

    enum _Enum

    static void

// More-or-less-standard language features described by lack, not presence:
# ifndef _G_NO_LONGLONG
  extern long long _G_global_with_a_good_long_name;  // avoid globals!
# endif

  // avoid in-class inline definitions, define separately;
  //   likewise for member class definitions:
  inline int
  gribble::public_member() const
  { int __local = 0; return __local; }

  class gribble::_Helper
    int _M_stuff;

    friend class gribble;

// Names beginning with "__": only for arguments and
//   local variables; never use "__" in a type name, or
//   within any name; never use "__[0-9]".

#endif /* _HEADER_ */

namespace std {

  template<typename T>  // notice: "typename", not "class", no space
    long_return_value_type<with_many, args> 
    function_name(char* pointer,               // "char *pointer" is wrong.
  char* argument,
  const Reference& ref)
      // int a_local;  /* wrong; see below. */
      if (test)
  nested code
      int a_local = 0;  // declare variable at first use.

      //  char a, b, *p;   /* wrong */
      char a = 'a';
      char b = a + 1;
      char* c = "abc";  // each variable goes on its own line, always.

      // except maybe here...
      for (unsigned i = 0, mask = 1; mask; ++i, mask <<= 1) {
  // ...
  : _M_private_data(0), _M_more_stuff(0), _M_helper(0);
  { }

  inline int
    // doesn't fit in one line.



GNU的C++代码书写规范,C语言之父Dennis Ritchie亲自修订

C++ Standard Library Style Guidelines  DRAFT 1999-02-26 ------------------------------------- Th...
  • ManFred2ManFred
  • ManFred2ManFred
  • 2013年07月25日 19:16
  • 460


C/C++源代码书写规范 1. 在.cpp的开头应有一段格式统一的说明,内容包括: a. 文件名 (FileName); b. 简短说明文件功能、用途 (Comment); c. 创建人 ...
  • piaocoder
  • piaocoder
  • 2015年05月16日 22:28
  • 2144


c语言编程规范和范例 1 排版 1    1-1:程序块要采用缩进风格编写,缩进的空格数为4个。 说明:对于由开发工具自动生成的代码可以有不一致。 1    1-2:相对独立的程序块之间、变量说明之...
  • benpaobagzb
  • benpaobagzb
  • 2016年02月29日 21:46
  • 1899


  • wenrenhua08
  • wenrenhua08
  • 2014年09月27日 00:00
  • 14025


C语言, 语言规范, 计算机语言规范, 编辑器, 设计, 注释, 语言注释, 如何编辑C语言, 如何规范编辑计算机语言, 如何规范编辑C语言...
  • Pnoter
  • Pnoter
  • 2014年12月06日 23:40
  • 1363


在1998年的元旦,Bjarne Stroustrup(C++之父)接受了IEEE《计算机》杂志记者的专访。编辑很自然的认为他会对于过去七年来使用他创建的语言进行面对对象设计做一个历史性的回顾。而在这...
  • u011549107
  • u011549107
  • 2013年11月22日 10:17
  • 812


  • u010590568
  • u010590568
  • 2017年04月24日 14:31
  • 405

C语言 程序代码编写规范

前言 一个好的程序编写规范是编写高质量程序的保证。清晰、规范的源程序不仅仅是方便阅读,更重要的是能够便于检查错误,提高调试效率,从而最终保证软件的质量和可维护性。 说明 l 本文档主要适用于...
  • weiqifa0
  • weiqifa0
  • 2016年04月28日 15:47
  • 805


C++代码编写规范 1        头文件 1.1    使用头文件保护 使用#define进行头文件保护,而不使用微软的#pragma once。 为了保证唯一性,头文件保护的命名需要基于...
  • Lady__Killer
  • Lady__Killer
  • 2016年11月30日 10:35
  • 682

C++ 高效编程之代码规范

  • u011686361
  • u011686361
  • 2017年01月02日 16:55
  • 409
您举报文章:GNU的C++代码书写规范,C语言之父Dennis Ritchie亲自修订