寻找类属性的良好命名约定 [英] Looking for good naming convention for class attributes

问题描述

多年来，我一直遵循使用前导下划线命名所有

类属性的惯例。这使我能够在

源代码中遇到它们时快速识别类属性。即使是GoF书籍也遵循这一惯例，尽管GoF书籍不是编码

指南的权威来源。

最近一位同事评论说，使用领先的下划线是一种糟糕的编程习惯，应该不惜一切代价避免。根据

对她来说，这与编译器命名修改

程序同样坚持领先的下划线并因此使用

下划线的事实有关。源代码使得跟随

后处理源代码的工作（如果有需要的话）很难

困难。


任何评论？


问候，

Sandeep

For many years I have been following the convention of naming all
class attributes with a leading underscore. This enables me to
quickly identify the class attributes when I encounter them in the
source code. Even the GoF book follows this convention, although it''s
true that the GoF book is not an authoritative source for coding
guidelines.

Recently a colleague remarked that using a leading underscore is a bad
programming practice that should be avoided at all costs. According
to her this has to do with the fact that the compiler naming mangling
procedure also sticks leading underscores and therefore using
underscores in the source code makes the job of following the
post-processed source code (should there ever be a need) very
difficult.

Any comments?

Regards,
Sandeep

推荐答案

Sandeep Sharma写道：

Sandeep Sharma wrote:

多年来，我一直遵循使用前导下划线命名所有
类属性的惯例。这使我能够在
源代码中遇到它们时快速识别类属性。即使是GoF书也遵循这一惯例，尽管GoF书并不是编码指南的权威来源。

最近一位同事评论说使用了领先的下划线是一种糟糕的编程实践，应该不惜一切代价避免。据她说，这与编译器命名修改程序也强调引导下划线这一事实有关，因此在源代码中使用
下划线使得工作跟随
后处理源代码（应该有需要）非常难。

任何评论？

问候，
Sandeep

For many years I have been following the convention of naming all
class attributes with a leading underscore. This enables me to
quickly identify the class attributes when I encounter them in the
source code. Even the GoF book follows this convention, although it''s
true that the GoF book is not an authoritative source for coding
guidelines.

Recently a colleague remarked that using a leading underscore is a bad
programming practice that should be avoided at all costs. According
to her this has to do with the fact that the compiler naming mangling
procedure also sticks leading underscores and therefore using
underscores in the source code makes the job of following the
post-processed source code (should there ever be a need) very
difficult.

Any comments?

Regards,
Sandeep

这不仅仅是你提到的（相对模糊的）问题。你不是允许使用领先的下划线; b $ b允许使用领先的下划线;根据标准的第17.4.3.1.2节，它们被保留用于

实施。你会在标准库代码中看到很多

领先的下划线;使用领导_你自己

会干扰图书馆，当然也不可移植。

It''s not just the (relatively obscure) issue you mention. You''re not
allowed to use leading underscores; they''re reserved for the
implementation, per section 17.4.3.1.2 of the standard. You see lots of
leading underscores in standard library code; using leading _ yourself
can interfere with the library, and certainly isn''t portable.

" Jeff Schwab"写道...

"Jeff Schwab" wrote...

多年来，我一直遵循以下前导命令来命名所有类属性。
这使我能够快速识别类属性书也遵循这一惯例，尽管GoF书籍确实不是编码指南的权威来源。

最近一位同事评论说使用领先的下划线是一种糟糕的编程习惯，应该不惜一切代价避免。根据她的说法，必须要做的事情是编译器命名修改程序
也会强调引导下划线，因此在源代码中使用
下划线可以完成以下工作
后处理源代码（应该有需要）非常困难。

任何评论？

问候，Sandeep

For many years I have been following the convention of
naming all class attributes with a leading underscore.
This enables me to quickly identify the class attributes
when I encounter them in the source code. Even the GoF
book follows this convention, although it''s true that
the GoF book is not an authoritative source for coding
guidelines.

Recently a colleague remarked that using a leading
underscore is a bad programming practice that should be
avoided at all costs. According to her this has to do
with the fact that the compiler naming mangling procedure
also sticks leading underscores and therefore using
underscores in the source code makes the job of following
the post-processed source code (should there ever be a
need) very difficult.

Any comments?

Regards, Sandeep

正如杰夫已经指出的那样，领先的下划线由

实现保留。使用前导下划线不仅是不好的做法，而且标准也不允许这样做。这些天很多书都喜欢

*尾随*下划线：


struct X

{

int someDataMember_;

};


我不喜欢这个约定而更喜欢m_前缀（尽管它是

与微软的关系）：


struct Y

{

int m_someDataMember;

} ;

As Jeff already pointed out, the leading underscore is reserved by the
implementation. Using leading underscores is not only bad practice
but also not permitted by the standard. These days many books prefer
the *trailing* underscore:

struct X
{
int someDataMember_;
};

I don''t like this convention and prefer an m_ prefix (despite it''s
affiliation with Microsoft):

struct Y
{
int m_someDataMember;
};

Derek在新闻中写道：bu ************ @ ID-46268.news.uni-berlin.de：

Derek wrote in news:bu************@ID-46268.news.uni-berlin.de:

正如杰夫已经指出的那样，领先的下划线由
实现保留。使用前导下划线不仅是不好的做法，而且标准也不允许这样做。这些天很多书都喜欢
*尾随*下划线：

As Jeff already pointed out, the leading underscore is reserved by the
implementation. Using leading underscores is not only bad practice
but also not permitted by the standard. These days many books prefer
the *trailing* underscore:

使用领先的下划线是leagal，只要：


A）它没有跟着另一个下划线，

B）它后面没有大写字母，

C）它没有在全局命名空间中声明一个标识符。


此外，带有2个连续下划线的标识符总是保留为
（因此上面的（A））。


Rob。

-
http://www.victim-prime.dsl.pipex.com/

这篇关于寻找类属性的良好命名约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！