GNU的C++代码书写规范

转载 2011年01月18日 16:12: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:

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 <dr@att.com>

* 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<typename T>
void
template_function(args)
{ }
-NOT-
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
{
public:
// Types:
};
-NOT-
template<class _CharT, class _Traits>
class basic_ios : public ios_base
{
public:
// Types:
};
-NOT-
template<class _CharT, class _Traits>
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<typename _Formal_argument>
void
public_template() const throw();

template<typename _Iterator>
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<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) {
// ...
}
}

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

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

}

 

C/C++源代码书写规范

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

GNU的C++代码书写规范

GNU的C++代码书写规范,C语言之父Dennis Ritchie亲自修订C++ Standard Library Style Guidelines  DRAFT 1999-02-26--------...
  • zyyuce
  • zyyuce
  • 2004年11月22日 19:22
  • 562

Verilog HDL代码书写规范

1. 目的 本规范的目的是提高书写代码的可读性、可修改性、可重用性,优化代码综合和仿真的结 果,指导设计工程师使用VerilogHDL规范代码和优化电路,规范化可编程技术部的FPGA设计输 入,从而做...
  • kobesdu
  • kobesdu
  • 2013年11月16日 14:31
  • 3287

C++常用命名法与书写规范

常用命名法有三种:驼峰命名法、匈牙利命名法、帕斯卡命名法。   这三种命名方法各有千秋,以庄子的齐物论来说就是“道无终始,物有死生,不恃其成”。我们要“吸百家之长,圆我代 码功夫”,废话说了三行了,...
  • u014597198
  • u014597198
  • 2016年09月01日 13:37
  • 1086

c++编码规范

 背景每一个C++程序员也都知道,C++具有很多强大的语言特性,但这种强大不可避免的导致它的复杂,而复杂性会使得代码更容易出现bug、难于阅读和维护。本规范的目的是通过详细阐述如何进行C++来规避其复...
  • AfricaHyena
  • AfricaHyena
  • 2009年08月24日 16:31
  • 7261

代码书写规范(Java)

        前几天整理出来的一个JAVA的代码书写规范!代码书写规范一、目的      对于代码,首要要求是它必须正确,能够按照程序员的真实思想去运行;第二个的要求是代码必须清晰易懂,使别的程序员...
  • rivershan
  • rivershan
  • 2002年11月07日 18:18
  • 3714

python 编码规范及习惯写法范例

python代码习惯写法:转自  http://www.fantascienza.net/leonardo/ar/python_best_practices.html python代码编写过程中有一...
  • chenbaoke
  • chenbaoke
  • 2014年08月19日 18:13
  • 1464

C++ 代码书写规范

根据平时写代码总结出来的个人代码风格习惯。根据遇到的情况不断更新。       头文件中避免多重包含 #ifndef    XXXXXX_H #indefine XXXXXX_H #end...
  • lovebird_27
  • lovebird_27
  • 2016年02月24日 14:47
  • 375

C语言的规范书写..【Pnoter】

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

前端代码书写规范

看了以下这个网址,不错哦。 http://www.css88.com/archives/5361 这是一份旨在增强团队的开发协作,提高代码质量和打造开发基石的编码风格规范,其中包含了 HTML...
  • xtyj0526
  • xtyj0526
  • 2017年05月04日 16:59
  • 205
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:GNU的C++代码书写规范
举报原因:
原因补充:

(最多只允许输入30个字)