在 c + + 中，var、 method 等的变数命名原则是什么？

我来自一个 Objective-C 和 Cocoa 的世界，那里有很多约定，很多人会说它让你的代码很漂亮！ 现在用 C + + 编程，我找不到一个像这样好的 C + + 文档。

Http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/codingguidelines/codingguidelines.html

标准 C + + 可能没有像上面那样的东西，但我希望我可以坚持使用其他的 SDK 或 API (比如微软的(?))会议等)。

我希望你能给我提供一些链接。

133944 次浏览
小开

虽然许多人会建议或多或少严格的 匈牙利命名法变体(吓人!)，为命名建议，我建议你看看 Google C + + 编码指南。这可能不是最流行的命名约定，但至少它是相当完整的。除了良好的命名约定，这里还有一些有用的指导方针，但是其中的大部分应该保持谨慎(例如，禁止异常，并且倾向于远离现代的 C + + 编码风格)。

尽管我个人喜欢 STL 和 Boost 这种极端的低技术含量的约定风格;)。

小开

没有你提供的链接简洁: 但是下面的第14-24章可能会有帮助:)呵呵

档号: http://www.amazon.com/Coding-Standards-Rules-Guidelines-Practices/dp/0321113586/ref=sr_1_1?ie=UTF8&s=books&qid=1284443869&sr=8-1-catcorr

小开
最佳答案

只要它的最小值、一致性和 并不违反任何规则，就可以做任何你想做的事情。

就我个人而言，我发现 Boost 风格最简单; 它与标准库(给代码一个统一的外观)相匹配，并且很简单。我个人将 m和 p前缀分别添加到成员和参数中，给出:

#ifndef NAMESPACE_NAMES_THEN_PRIMARY_CLASS_OR_FUNCTION_THEN_HPP
#define NAMESPACE_NAMES_THEN_PRIMARY_CLASS_OR_FUNCTION_THEN_HPP


#include <boost/headers/go/first>
#include <boost/in_alphabetical/order>
#include <then_standard_headers>
#include <in_alphabetical_order>


#include "then/any/detail/headers"
#include "in/alphabetical/order"
#include "then/any/remaining/headers/in"
// (you'll never guess)
#include "alphabetical/order/duh"


#define NAMESPACE_NAMES_THEN_MACRO_NAME(pMacroNames) ARE_ALL_CAPS


namespace lowercase_identifers
{
class separated_by_underscores
{
public:
void because_underscores_are() const
{
volatile int mostLikeSpaces = 0; // but local names are condensed


while (!mostLikeSpaces)
single_statements(); // don't need braces


for (size_t i = 0; i < 100; ++i)
{
but_multiple(i);
statements_do();
}
}


const complex_type& value() const
{
return mValue; // no conflict with value here
}


void value(const complex_type& pValue)
{
mValue = pValue ; // or here
}


protected:
// the more public it is, the more important it is,
// so order: public on top, then protected then private


template <typename Template, typename Parameters>
void are_upper_camel_case()
{
// gman was here
}


private:
complex_type mValue;
};
}


#endif

那个。 (就像我在评论中说的那样，除非你的代码像变数命名原则一样无关紧要，否则 没有会采用谷歌风格指南吗?)

小开

这真的没有关系。只要确保你的变量和函数的名称是描述性的。也是一致的。

没有比看到这样的代码更糟糕的了:

int anInt;                  // Great name for a variable there ...
int myVar = Func( anInt );  // And on this line a great name for a function and myVar
// lacks the consistency already, poorly, laid out!

编辑: 正如我的评论者所指出的，整个团队需要保持一致性。因此，您选择哪种方法并不重要，只要保持一致性即可。然而，没有正确或错误的方法。我工作过的每个团队都有不同的想法，我已经适应了。

小开

命名约定的数量可能和个人的数量一样多，关于使用哪种花括号样式的争论也是无休止的(而且毫无结果) ，等等。

所以我有两个建议:

  • 在一个项目内是 始终如一
  • 不要使用保留标识符(任何带有两个下划线或以下划线开头、后跟大写字母的标识符)

剩下的就看你的了。

小开

人们在编写 C + + 时使用许多不同的系统/约定。例如，有些人喜欢使用大写字母(myVar 或 MyVar)或下划线(my _ var)来分隔单词。通常，使用下划线的变量都是小写的(根据我的经验)。
还有一种被称为匈牙利语的编码风格，我相信微软正在使用这种风格。我个人认为这是浪费时间，但它可能被证明是有用的。这是给变量命名的短前缀，比如 i，或者 f 来提示变量的类型。例如: int iVarname，char * strVarname。

用 _ t 结束 struct/class 名称是可以接受的，这样可以将它与变量名称区分开来。例如:

class cat_t {
...
};


cat_t myCat;

通常还可以添加一个后缀来指示指针，例如 pVariable 或 variable _ p。

总而言之，实际上没有任何单一的 标准，而是有很多。您对命名变量所做的选择并不重要，只要它是可以理解的，而且最重要的是，一致的。一致性，一致性，一致性！(试着打三遍!)

如果一切都失败了，谷歌一下。

小开

我们遵循本页列出的指南: C + + 编程风格指南

我还建议你阅读 米斯菲尔德等的《 C + + 风格的要素》，这是一本关于这个主题的非常好的书。

小开

我实际上经常使用 Java 风格: PascalCase 用于类型名称，camelCase 用于函数和变量，CAPITAL _ WORDS 用于预处理宏。相对于 Boost/STL 约定，我更喜欢这种方式，因为您不必在 _type中使用类型的后缀。例如。

Size size();

而不是

size_type size();   // I don't like suffixes

这样做还有一个额外的好处: StackOverflow 代码格式化程序将 Size识别为类型名; -)

小开

一致性和可读性(自记录代码)很重要。一些线索(例如大小写)可以而且应该被用来避免冲突，并且表明是否需要一个实例。

我采用的最佳实践之一是使用代码格式化程序(style 和 uncrutify 是两个例子)。代码格式化程序可以破坏您的代码格式化-配置格式化程序，并让它完成其工作。认真地说，忘掉手动格式化，开始实践使用它们。他们会节省很多时间。

正如前面提到的，命名要非常具有描述性。此外，对范围(类类型/数据/名称空间/匿名名称空间)要非常具体。总的来说，我非常喜欢 java 常见的书面形式——这是一个很好的参考，类似于 c + + 。

至于具体的外观/命名，这是一个类似于我使用的小例子(变量/参数是低骆驼，这只展示了语言的一部分功能) :

/** MYC_BEGIN_FILE_ID::FD_Directory_nanotimer_FN_nanotimer_hpp_::MYC_BEGIN_FILE_DIR::Directory/nanotimer::MYC_BEGIN_FILE_FILE::nanotimer.hpp::Copyright... */
#ifndef FD_Directory_nanotimer_FN_nanotimer_hpp_
#define FD_Directory_nanotimer_FN_nanotimer_hpp_


/* typical commentary omitted -- comments detail notations/conventions. also, no defines/macros other than header guards */


namespace NamespaceName {


/* types prefixed with 't_' */
class t_nanotimer : public t_base_timer {
/* private types */
class t_thing {
/*...*/
};
public:
/* public types */
typedef uint64_t t_nanosecond;


/* factory initializers -- UpperCamel */
t_nanotimer* WithFloat(const float& arg);
/* public/protected class interface -- UpperCamel */
static float Uptime();
protected:
/* static class data -- UpperCamel -- accessors, if needed, use Get/Set prefix */
static const t_spoke Spoke;
public:
/* enums in interface are labeled as static class data */
enum { Granularity = 4 };
public:
/* construction/destruction -- always use proper initialization list */
explicit t_nanotimer(t_init);
explicit t_nanotimer(const float& arg);


virtual ~t_nanotimer();


/*
public and protected instance methods -- lowercaseCamel()
- booleans prefer is/has
- accessors use the form: getVariable() setVariable().
const-correctness is important
*/
const void* address() const;
virtual uint64_t hashCode() const;
protected:
/* interfaces/implementation of base pure virtuals (assume this was pure virtual in t_base_timer) */
virtual bool hasExpired() const;
private:
/* private methods and private static data */
void invalidate();
private:
/*
instance variables
- i tend to use underscore suffix, but d_ (for example) is another good alternative
- note redundancy in visibility
*/
t_thing ivar_;
private:
/* prohibited stuff */
explicit t_nanotimer();
explicit t_nanotimer(const int&);
};
} /* << NamespaceName */
/* i often add a multiple include else block here, preferring package-style inclusions */
#endif /* MYC_END_FILE::FD_Directory_nanotimer_FN_nanotimer_hpp_ */
小开

无论如何，比雅尼·斯特劳斯特鲁普 c + + 的最初作者有他自己喜欢的风格，这里描述的是: http://www.stroustrup.com/bs_faq2.html


提交答案