在c++中，vars、方法等的良好命名约定是什么?

I come from a the Objective-C and Cocoa world where there are lots of conventions and many people will say it makes your code beautiful! Now programming in C++ I cannot find a good document like this one for C++.

我来自Objective-C和Cocoa世界，有很多惯例，很多人会说它让你的代码更漂亮!现在，在c++中编程，我找不到像这样好的c++文档。

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

http://developer.apple.com/library/mac/文档/可可/概念/ CodingGuidelines / CodingGuidelines.html

Standard C++ probably does not have something like above but I hope I can stick to some other SDK or APIs (like Microsoft's(?),etc) conventions.

标准c++可能没有类似的东西，但是我希望我能坚持一些其他的SDK或api(比如Microsoft的(?)等)约定。

I hope you can provide me with some links.

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

11 个解决方案

#1

Do whatever you want as long as its minimal, consistent, and doesn't break any rules.

做任何你想做的，只要它是最小的，一致的，并且不违反任何规则。

Personally, I find the Boost style easiest; it matches the standard library (giving a uniform look to code) and is simple. I personally tack on m and p prefixes to members and parameters, respectively, giving:

就我个人而言，我觉得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

That. (And like I've said in comments, do not adopt the Google Style Guide for your code, unless it's for something as inconsequential as naming convention.)

那(就像我在评论中说的，不要在代码中采用谷歌样式指南，除非它是针对一些无关紧要的命名约定。)

#2

There are probably as many naming conventions as there are individuals, the debate being as endless (and sterile) as to which brace style to use and so forth.

可能有很多的命名惯例和个人的一样多，关于使用哪种括号风格的争论是无穷无尽的(和枯燥的)。

So I'll have 2 advices:

我有两个建议:

• be consistent within a project
• 在项目中保持一致。
• don't use reserved identifiers (anything with two underscores or beginning with an underscore followed by an uppercase letter)
• 不要使用保留标识符(任何带有两个下划线或以下划线和大写字母开头的标识符)

The rest is up to you.

剩下的由你决定。

#3

I actually often use Java style: PascalCase for type names, camelCase for functions and variables, CAPITAL_WORDS for preprocessor macros. I prefer that over the Boost/STL conventions because you don't have to suffix types with _type. E.g.

实际上，我经常使用Java样式:类型名的PascalCase，函数和变量的camelCase，预处理器宏的CAPITAL_WORDS。与Boost/STL约定相比，我更喜欢这样，因为不需要用_type作为后缀类型。如。

Size size();

instead of

而不是

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

This has the additional benefit that the * code formatter recognizes Size as a type name ;-)

这有一个额外的好处，*代码格式化程序将大小识别为类型名;

#4

We follow the guidelines listed on this page: C++ Programming Style Guidelines

我们遵循本页列出的准则:c++编程风格准则

---

I'd also recommend you read The Elements of C++ Style by Misfeldt et al, which is quite an excellent book on this topic.

我还建议您阅读Misfeldt等人的c++风格的元素，这是一本非常优秀的关于这个主题的书。

#5

For what it is worth, Bjarne Stroustrup, the original author of C++ has his own favorite style, described here: http://www.stroustrup.com/bs_faq2.html

无论如何，《c++》的作者Bjarne Stroustrup有他自己最喜欢的风格:http://www.stroustrup.com/bs_faq2.html

#6

To address the broader issue of style guides I suggest picking one and sticking to it.
The Google style guide is very detailed/comprehensive, so it's a good choice.

为了解决更广泛的风格指南问题，我建议选择一个并坚持下去。谷歌风格指南非常详细/全面，所以是一个不错的选择。

A common convention just for naming is:

一个仅用于命名的通用约定是:

• camelCase for all names (except constants).
• 所有名称的camelCase(除了常量)。
• Beginning with a capital if it's a class.
• 从大写开始，如果它是一个类。
• Lowercase if not.
• 如果不是小写。
• Constants in ALL_CAPS with underscore separating works.
• 用下划线分隔的ALL_CAPS中的常量。
• Functions can be written the same as variables, camelCase (you can tell it's a function because it requires () after it).
• 函数可以与变量camelCase(您可以看出它是一个函数，因为它后面需要()))相同。
• And member variables prefixed with an m and thus would be written mCamelCase.
• 并且成员变量前缀为m，因此写入mCamelCase。

It's really up to you or alternatively the people you work for/with or the university you study at.

这完全取决于你，或者你的同事，或者你就读的大学。

For a detail look at a variety of style guides / rationales behind them, check out Pragmatic Programmer by Andrew Hunt and David Thomas.

要详细了解它们背后的各种风格指南/理由，请参阅Andrew Hunt和David Thomas的实用程序员。

#7

While many people will suggest more or less strict Hungarian notation variants (scary!), for naming suggestions I'd suggest you take a look at Google C++ Coding Guidelines. This may well be not the most popular naming conventions, but at least it's fairly complete. Apart from sound naming conventions, there's some useful guidelines there, however much of it should be taken with a grain of salt (exception ban for example, and the tendency to keep away from modern C++ coding style).

虽然很多人会推荐或多或少严格的匈牙利符号变体(太可怕了!)，但对于命名建议，我建议您看看谷歌c++编码指南。这可能不是最流行的命名约定，但至少它是相当完整的。除了良好的命名约定之外，还有一些有用的指导原则，但是这些指导原则在很大程度上应该有所保留(例如，例外禁令，以及远离现代c++编码风格的倾向)。

Although personally I like the extreme low-tech convention style of STL and Boost ;).

虽然我个人喜欢极低技术的会议风格的STL和Boost;)。

#8

consistency and readability (self-documenting code) are important. some clues (such as case) can and should be used to avoid collisions, and to indicate whether an instance is required.

一致性和可读性(自文档化代码)是很重要的。一些线索(例如case)可以也应该用来避免冲突，并指示是否需要一个实例。

one of the best practices i got into was the use of code formatters (astyle and uncrustify are 2 examples). code formatters can destroy your code formatting - configure the formatter, and let it do its job. seriously, forget about manual formatting and get into the practice of using them. they will save a ton of time.

我采用的最佳实践之一是使用代码格式器(astyle和uncrustify是两个示例)。代码格式化器可以破坏您的代码格式化——配置格式化程序，并让它完成它的工作。认真地说，忘记手工格式化并开始使用它们。它们将节省大量的时间。

as mentioned, be very descriptive with naming. also, be very specific with scoping (class types/data/namespaces/anonymous namespaces). in general, i really like much of java's common written form - that is a good reference and similar to c++.

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

as for specific appearance/naming, this is a small sample similar to what i use (variables/arguments are lowerCamel and this only demonstrates a portion of the language's features):

关于特定的外观/命名，这是一个与我使用的类似的小示例(变量/参数是小写的，这只展示了语言的一部分特性):

/** 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_ */

#9

There are many different sytles/conventions that people use when coding C++. For example, some people prefer separating words using capitals (myVar or MyVar), or using underscores (my_var). Typically, variables that use underscores are in all lowercase (from my experience).
There is also a coding style called hungarian, which I believe is used by microsoft. I personally believe that it is a waste of time, but it may prove useful. This is were variable names are given short prefixes such as i, or f to hint the variables type. For example: int iVarname, char* strVarname.

在编写c++时，人们使用许多不同的系统/惯例。例如，有些人喜欢用大写(myVar或myVar)或下划线(my_var)分隔单词。通常，使用下划线的变量都是小写的(根据我的经验)。还有一种叫做匈牙利语的编码风格，我相信微软也在使用匈牙利语。我个人认为这是浪费时间，但它可能被证明是有用的。这是给变量名加上简短的前缀如i或f来提示变量类型。例如:int iVarname、char* strVarname。

It is accepted that you end a struct/class name with _t, to differentiate it from a variable name. E.g.:

您可以使用_t结束一个struct/类名称，以将其与变量名区分开来。例如:

class cat_t {
  ...
};

cat_t myCat;

It is also generally accepted to add a affix to indicate pointers, such as pVariable or variable_p.

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

In all, there really isn't any single standard, but many. The choices you make about naming your variables doesn't matter, so long as it is understandable, and above all, consistent. Consistency, consistency, CONSISTENCY! (try typing that thrice!)

总的来说，确实没有任何单一的标准，但有很多。选择命名变量并不重要，只要它是可以理解的，而且最重要的是，是一致的。一致性、连贯性、一致性!(试着输入三次!)

And if all else fails, google it.

如果所有这些都失败了，谷歌。

#10

It really doesn't matter. Just make sure you name your variables and functions descriptively. Also be consistent.

它真的不重要。只需要确定你的变量和函数的名称是描述性的。也是一致的。

Nowt worse than seeing code like this:

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

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! 

Edit: As pointed out by my commenter that consistency needs to be maintained across an entire team. As such it doesn't matter WHAT method you chose, as long as that consistency is maintained. There is no right or wrong method, however. Every team I've worked in has had different ideas and I've adapted to those.

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

#11

not nearly as concise as the link you provided: but the following chapter 14 - 24 may help :) hehe

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

ref: 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

裁判: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