GNU的C++代码书写规范,C语言之父Dennis Ritchie亲自修订 (转)[@more@]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:

http://www.gnu.ai.mit.edu/prep/standards_toc.html

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

1999-04-15  Dennis Ritchie

* src/basic_file.cc (__basic_file::open): Fix thinko in
_G_HAVE_IO_FILE_OPEN bits.

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;
  -NOT-
  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)
  -NOT-
  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()
  -NOT-
  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
  void
  template_function(args)
  { }
  -NOT-
  template
  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
  class basic_ios : public ios_base
  {
  public:
  // Types:
  };
  -NOT-
  template
  class basic_ios : public ios_base
  {
  public:
  // Types:
  };
  -NOT-
  template
  class basic_ios : public ios_base
  {
  public:
  // Types:
  };

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

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

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

08. Try/Catch blocks
  try {
  //
  } 
  catch(...) {
  //
  } 
  -NOT-
  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 
  foo()
  -NOT-
  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.

this->sync()
  -NOT-
  sync()

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.

--------------------------

[BY EXAMPLE]
 
#ifndef  _HEADER_
#define  _HEADER_ 1

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

gribble(const gribble&);

explicit
  gribble(int __howmany);

gribble&
  operator=(const gribble&);

virtual
  ~gribble() throw ();

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

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

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

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

// note indentation
  template
  void
  public_template() const throw();

template
  void
  other_template();

private:
  class _Helper;

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

enum _Enum
  {
_S_one,
_S_two
  };

static void
  _S_initialize_library();
  };

// 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  // notice: "typename", not "class", no space
  long_return_value_type 
  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) {
  // ...
  }
  }
 
  gribble::gribble()
  : _M_private_data(0), _M_more_stuff(0), _M_helper(0);
  { }

inline int
  gribble::three_lines()
  {
  // doesn't fit in one line.
  }

}

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10748419/viewspace-1004555/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/10748419/viewspace-1004555/

GNU的C++代码书写规范,C语言之父Dennis Ritchie亲自修订 (转)相关推荐

  1. GNU的C++代码书写规范

    GNU的C++代码书写规范,C语言之父Dennis Ritchie亲自修订 C++ Standard Library Style Guidelines  DRAFT 1999-02-26 ------ ...

  2. C语言之父Dennis Ritchie辞世

    C语言之父Dennis Ritchie辞世 2011-10-13 10:24 | 38388次阅读 | 来源:CSDN整理 [已有698条评论]发表评论 关键词:C语言发明人,Dennis,Ritch ...

  3. 缅怀计算机界老一辈无产阶级革命家--C语言之父Dennis Ritchie辞世

    摘要: 北京时间10月13日上午消息,据国外媒体报道,美国著名计算机专家.C语言发明人之一Dennis Ritchie已于10月9日去世,享年70岁.Dennis Ritchie生于1941年9月9日 ...

  4. 反思:乔布斯和丹尼斯·里奇的去世 C语言之父Dennis Ritchie辞世

    C语言发明人之一 Dennis Ritchie 北京时间10月13日上午消息,据国外媒体报道,美国著名计算机专家.C语言发明人之一Dennis Ritchie已于10月9日去世,享年70岁. Denn ...

  5. 天勤考研中数据结构的代码书写规范以及C与C++语言基础

    考研综合应用题中算法设计部分的代码书写规范 头文件 头文件部分如果题目没有特殊说明可以去掉. 常量 如果题目中要用到一个常量,则在用的地方加上一句注释,说明某某常量已定义即可,不必在前面补上#defi ...

  6. java 代码书写规范_代码书写规范和命名规范

    上一篇给大家分享了一下,关于文档编写的几个概念.这篇文章阐述如果编写代码书写规范以及命名规范文档.[以java语言为例] 1.代码书写规范 代码书写规范,能够让不同的人,写出相同风格的代码.很多人都看 ...

  7. 网页编程代码书写规范

    网页编程,也就是网页代码的编写,其实也就是编程代码的书写,一个好的网站,其网页编码,是比较规范的,条理清晰,格式简洁美观,可读性强,那到底怎样才能规范好代码的编写规范,是一个值得大家深思的问题,想想自 ...

  8. WEB前端代码书写规范

    WEB前端代码书写规范 1. 命名规范 a.ClassName命名 ClassName的命名应该尽量精短.明确,必须以单页面字母开头命名,且全部字母为小写,单词之间统一使用下划线 "_&qu ...

  9. c#书写规范之---代码书写规范

    代码书写规范          格式化使代码的逻辑结构很明显.花时间确保源代码以一致的逻辑方式进行格式化,这对于您和你的开发小组,以及以后维护源代码的其他开发人员都有很大的帮助. 以下几点是推荐的格式 ...

最新文章

  1. 生成N个不相等的随机数
  2. 关于BitmapImage EndInit()时报值不在范围内的异常
  3. 用Docker搭建Nexus私服
  4. 我要彻底给你讲清楚,Java就是值传递,不接受争辩的那种!
  5. Java中Socket通信-客户端与服务端相互传输对象数据
  6. 大数据WEB阶段(十五)JavaEE三大核心技术之过滤器
  7. Spring 操作数据库
  8. 鲲鹏展翅 力算未来 | openEuler操作系统源代码正式开放
  9. 远程连接windows系统提示:其他用户要远程登录,需要通过远程桌面服务进行登录的权限......
  10. (转)Flex compc ant 编译
  11. win7_32下编译FFmpeg
  12. python tan图
  13. HTML5中 audio标签的样式修改
  14. python读取txt文件中的内容并用逗号分割_数据分析—gt;文件读写
  15. 设置一绝对地址为0x67a9的整型变量的值为0xaa66
  16. 2023年全国最新交安安全员精选真题及答案4
  17. 校招选择题汇总【图形推理(1)】含答案解析
  18. windows程序和控制台程序
  19. Python数学建模系列(五):微分方程
  20. 中柏zpad6 android x86,Windows平板轻应用 中柏EZpad 6评测

热门文章

  1. 25-方向传感器实现指南针
  2. 如何高效阅读技术类书籍?
  3. idea修改代码提示时间
  4. Suzy找到实习了吗 | 字符串结束啦 今天学习kmp 题还没做!!!记得回来补!!!
  5. og标签对SEO的作用及用法
  6. 怎么退出自适应巡航_吉利ICON ACC自适应巡航系统
  7. 国际网络收款工具Paypal注册图文教程
  8. 艺赛旗 (RPA) Python 的数据类型
  9. python实数运算
  10. 基于位置(Lbsn)的社交网络中混合推荐算法的设计