Google C++Style Guide(google c++ 代码规范)
Google C++Style Guide
Revision 3.188 Benjy WeinbergerCraig SilversteinGregory EitzmannMark MentovaiTashana Landray Each style point has a summary for which additional information is available by toggling the accompanying arrow button that looks this way:▽.You may toggle all summaries with the big arrow button: ▽Toggle all summaries Table of Contents
Important Note
Displaying Hidden Details in this Guide
link ▽This style guide contains many details that are initially hidden from view.They are marked by the triangle icon,which you see here on your left.Click it now.You should see"Hooray"appear below. Hooray!Now you know you can expand points to get more details.Alternatively,there's an"expand all"at the top of this document. Background
C++is the main development language used by many of Google's open-source projects.As every C++programmer knows,the language has many powerful features,but this power brings with it complexity,which in turn can make code more bug-prone and harder to read and maintain. The goal of this guide is to manage this complexity by describing in detail the dos and don'ts of writing C++code.These rules exist to keep the code base manageable while still allowing coders to use C++language features productively. Style ,also known as readability,is what we call the conventions that govern our C++code.The term Style is a bit of a misnomer,since these conventions cover far more than just source file formatting. One way in which we keep the code base manageable is by enforcing consistency .It is very important that any programmer be able to look at another's code and quickly understand it.Maintaining a uniform style and following conventions means that we can more easily use"pattern-matching"to infer what various symbols are and what invariants are true about them.Creating common,required idioms and patterns makes code much easier to understand.In some cases there might be good arguments for changing certain style rules,but we nonetheless keep things as they are in order to preserve consistency. Another issue this guide addresses is that of C++feature bloat.C++is a huge language with many advanced features.In some cases we constrain,or even ban,use of certain features.We do this to keep code simple and to avoid the various common errors and problems that these features can cause.This guide lists these features and explains why their use is restricted. Open-source projects developed by Google conform to the requirements in this guide. Note that this guide is not a C++tutorial:we assume that the reader is familiar with the language.
Header Files
In general,every .cc file should have an associated .h file.There are some common exceptions,such as unittests and small .cc files containing just a main()function. Correct use of header files can make a huge difference to the readability,size and performance of your code. The following rules will guide you through the various pitfalls of using header files.
The#define Guard
link ▽All header files should have #define guards to prevent multiple inclusion.The format of the symbol name should be
Header File Dependencies
link ▽Don't use an #include when a forward declaration would suffice.
When you include a header file you introduce a dependency that will cause your code to be recompiled whenever the header file changes.If your header file includes other header files,any change to those files will cause any code that includes your header to be recompiled.Therefore,we prefer to minimize includes,particularly includes of header files in other header files. You can significantly reduce the number of header files you need to include in your own header files by using forward declarations.For example,if your header file uses the File class in ways that do not require access to the declaration of the File class,your header file can just forward declare class File;instead of having to #include"file/base/file.h". How can we use a class Foo in a header file without access to its definition? ? We can declare data members of type Foo*or Foo&. ? We can declare(but not define)functions with arguments,and/or return values,of type Foo .(One exception is if an argument Foo or const Foo&has a non-explicit ,one-argument constructor,in which case we need the full definition to support automatic type conversion.) ? We can declare static data members of type Foo .This is because static data members are defined outside the class definition. On the other hand,you must include the header file for Foo if your class subclasses Foo or has a data member of type Foo . Sometimes it makes sense to have pointer(or better,scoped_ptr )members instead of object members.However,this complicates code readability and imposes a performance penalty,so avoid doing this transformation if the only purpose is to minimize includes in header files. Of course,.cc files typically do require the definitions of the classes they use,and usually have to include several header files. Note:If you use a symbol Foo in your source file,you should bring in a definition for Foo yourself,either via an#include or via a forward Header Files
The#define GuardHeader File DependenciesInline FunctionsThe-inl.h FilesFunction Parameter OrderingNames and Order of Includes Scoping
NamespacesNested ClassesNonmember,Static Member,and Global FunctionsLocal VariablesStatic and Global Variables Classes
Doing Work in ConstructorsDefault ConstructorsExplicit ConstructorsCopy ConstructorsStructs vs.ClassesInheritanceMultiple InheritanceInterfacesOperator OverloadingAccess ControlDeclaration OrderWrite Short Functions Google-Specific Magic
Smart Pointerscpplint Other C++Features
Reference ArgumentsFunction OverloadingDefault ArgumentsVariable-Length Arrays and alloca()FriendsExceptionsRun-Time Type Information(RTTI)CastingStreamsPreincrement and PredecrementUse of constInteger Types64-bit PortabilityPreprocessor Macros0 and NULLsizeofBoostC++0x Naming
General Naming RulesFile NamesType NamesVariable NamesConstant NamesFunction NamesNamespace NamesEnumerator NamesMacro NamesExceptions to Naming Rules Comments
Comment StyleFile CommentsClass CommentsFunction CommentsVariable CommentsImplementation CommentsPunctuation,Spelling and GrammarTODO CommentsDeprecation Comments Formatting
Line LengthNon-ASCII CharactersSpaces vs.TabsFunction Declarations and DefinitionsFunction CallsConditionalsLoops and Switch StatementsPointer and Reference ExpressionsBoolean ExpressionsReturn ValuesVariable and Array InitializationPreprocessor DirectivesClass FormatConstructor Initializer ListsNamespace FormattingHorizontal WhitespaceVertical Whitespace Exceptions to the Rules
Existing Non-conformant CodeWindows Code
declaration.Do not depend on the symbol being brought in transitively via headers not directly included.One exception is if Foo is used in https://www.sodocs.net/doc/aa10598413.html,,it's ok to#include(or forward-declare)Foo in myfile.h,instead of https://www.sodocs.net/doc/aa10598413.html,.
Inline Functions
link▽Define functions inline only when they are small,say,10 lines or less.
Definition:You can declare functions in a way that allows the compiler to expand them inline rather than calling them through the usual function call mechanism.
Pros:Inlining a function can generate more efficient object code,as long as the inlined function is small.Feel free to inline accessors and mutators,and other short,performance-critical functions.
Cons:Overuse of inlining can actually make programs slower.Depending on a function's size,inlining it can cause the code size to increase or decrease.Inlining a very small accessor function will usually decrease code size while inlining a very large function can dramatically increase code size.On modern processors smaller code usually runs faster due to better use of the instruction cache.
Decision:
A decent rule of thumb is to not inline a function if it is more than 10 lines long.Beware of destructors,which are often longer than they appear because of implicit member-and base-destructor calls!
Another useful rule of thumb:it's typically not cost effective to inline functions with loops or switch statements(unless,in the common case,the loop or switch statement is never executed).
It is important to know that functions are not always inlined even if they are declared as such;for example,virtual and recursive functions are not normally https://www.sodocs.net/doc/aa10598413.html,ually recursive functions should not be inline.The main reason for making a virtual function inline is to place its definition in the class,either for convenience or to document its behavior,e.g.,for accessors and mutators.
The-inl.h Files
link▽You may use file names with a-inl.h suffix to define complex inline functions when needed.
The definition of an inline function needs to be in a header file,so that the compiler has the definition available for inlining at the call sites.However,implementation code properly belongs https://www.sodocs.net/doc/aa10598413.html, files,and we do not like to have much actual code in.h files unless there is a readability or performance advantage.
If an inline function definition is short,with very little,if any,logic in it,you should put the code in your.h file.For example,accessors and mutators should certainly be inside a class definition.More complex inline functions may also be put in a.h file for the convenience of the implementer and callers,though if this makes the.h file too unwieldy you can instead put that code in a separate-inl.h file.This separates the implementation from the class definition,while still allowing the implementation to be included where necessary.
Another use of-inl.h files is for definitions of function templates.This can be used to keep your template definitions easy to read.
Do not forget that a-inl.h file requires a#define guard just like any other header file.
Function Parameter Ordering
link▽When defining a function,parameter order is:inputs,then outputs.
Parameters to C/C++functions are either input to the function,output from the function,or both.Input parameters are usually values or const references,while output and input/output parameters will be non-const pointers.When ordering function parameters,put all input-only parameters before any output parameters.In particular,do not add new parameters to the end of the function just because they are new;place new input-only parameters before the output parameters.
This is not a hard-and-fast rule.Parameters that are both input and output(often classes/structs)muddy the waters,and,as always,consistency with related functions may require you to bend the rule.
Names and Order of Includes
link▽Use standard order for readability and to avoid hidden dependencies:C library,C++library,other libraries'.h,your project's.h.
All of a project's header files should be listed as descendants of the project's source directory without use of UNIX directory shortcuts.(the current directory)or..(the parent directory).For example,google-awesome-project/src/base/logging.h should be included as #include"base/logging.h"
In dir/https://www.sodocs.net/doc/aa10598413.html, or dir/foo_https://www.sodocs.net/doc/aa10598413.html,,whose main purpose is to implement or test the stuff in dir2/foo2.h,order your includes as follows: 1dir2/foo2.h(preferred location—see details below).
2 C system files.
3C++system files.
4Other libraries'.h files.
5Your project's.h files.
The preferred ordering reduces hidden dependencies.We want every header file to be compilable on its own.The easiest way to achieve this is to make sure that every one of them is the first.h file#include d in https://www.sodocs.net/doc/aa10598413.html,.
dir/https://www.sodocs.net/doc/aa10598413.html, and dir2/foo2.h are often in the same directory(e.g.base/basictypes_https://www.sodocs.net/doc/aa10598413.html, and base/basictypes.h),but can be in different directories too.
Within each section it is nice to order the includes alphabetically.
For example,the includes in google-awesome-project/src/foo/internal/https://www.sodocs.net/doc/aa10598413.html, might look like this:
#include"foo/public/fooserver.h"//Preferred location.
#include
#include
#include
#include
#include"base/basictypes.h"
#include"base/commandlineflags.h"
#include"foo/public/bar.h"
Scoping
Namespaces
link▽Unnamed namespaces https://www.sodocs.net/doc/aa10598413.html, files are encouraged.With named namespaces,choose the name based on the project,and possibly its path.Do not use a using-directive.
Definition:Namespaces subdivide the global scope into distinct,named scopes,and so are useful for preventing name collisions in the global scope.
Pros:
Namespaces provide a(hierarchical)axis of naming,in addition to the(also hierarchical)name axis provided by classes.
For example,if two different projects have a class Foo in the global scope,these symbols may collide at compile time or at runtime.If each project places their code in a namespace,project1::Foo and project2::Foo are now distinct symbols that do not collide.
Cons:
Namespaces can be confusing,because they provide an additional(hierarchical)axis of naming,in addition to the(also hierarchical)name axis provided by classes.
Use of unnamed spaces in header files can easily cause violations of the C++One Definition Rule(ODR).
Decision:
Use namespaces according to the policy described below.
Unnamed Namespaces
?Unnamed namespaces are allowed and even encouraged https://www.sodocs.net/doc/aa10598413.html, files,to avoid runtime naming conflicts: namespace{//This is in https://www.sodocs.net/doc/aa10598413.html, file.
//The content of a namespace is not indented
enum{kUnused,kEOF,kError};//Commonly used tokens.
bool AtEof(){return pos_==kEOF;}//Uses our namespace's EOF.
}//namespace
However,file-scope declarations that are associated with a particular class may be declared in that class as types,static data members or static member functions rather than as members of an unnamed namespace.Terminate the unnamed namespace as shown,with a comment//namespace.
?Do not use unnamed namespaces in.h files.
Named Namespaces
Named namespaces should be used as follows:
?Namespaces wrap the entire source file after includes,gflags definitions/declarations,and forward declarations of classes from other namespaces:
//In the.h file
namespace mynamespace{
//All declarations are within the namespace scope.
//Notice the lack of indentation.
class MyClass{
public:
...
void Foo();
};
}//namespace mynamespace
//In https://www.sodocs.net/doc/aa10598413.html, file
namespace mynamespace{
//Definition of functions is within scope of the namespace.
void MyClass::Foo(){
...
}
}//namespace mynamespace
The https://www.sodocs.net/doc/aa10598413.html, file might have more complex detail,including the need to reference classes in other namespaces.
#include"a.h"
DEFINE_bool(someflag,false,"dummy flag");
class C;//Forward declaration of class C in the global namespace.
namespace a{class A;}//Forward declaration of a::A.
namespace b{
...code for b...//Code goes against the left margin.
}//namespace b
?Do not declare anything in namespace std,not even forward declarations of standard library classes.Declaring entities in namespace std is undefined behavior,i.e.,not portable.To declare entities from the standard library,include the appropriate header file.
?You may not use a using-directive to make all names from a namespace available.
//Forbidden--This pollutes the namespace.
using namespace foo;
?You may use a using-declaration anywhere in https://www.sodocs.net/doc/aa10598413.html, file,and in functions,methods or classes in.h files.
//OK https://www.sodocs.net/doc/aa10598413.html, files.
//Must be in a function,method or class in.h files.
using::foo::bar;
?Namespace aliases are allowed anywhere in https://www.sodocs.net/doc/aa10598413.html, file,anywhere inside the named namespace that wraps an entire.h file,and in functions and methods.
//Shorten access to some commonly used names https://www.sodocs.net/doc/aa10598413.html, files.
namespace fbz=::foo::bar::baz;
//Shorten access to some commonly used names(in a.h file).
namespace librarian{
//The following alias is available to all files including
//this header(in namespace librarian):
//alias names should therefore be chosen consistently
//within a project.
namespace pd_s=::pipeline_diagnostics::sidetable;
inline void my_inline_function(){
//namespace alias local to a function(or method).
namespace fbz=::foo::bar::baz;
...
}
}//namespace librarian
Note that an alias in a.h file is visible to everyone#including that file,so public headers(those available outside a project)and headers transitively#included by them,should avoid defining aliases,as part of the general goal of keeping public APIs as small as possible.
Nested Classes
link▽Although you may use public nested classes when they are part of an interface,consider a namespace to keep declarations out of the global scope.
Definition:A class can define another class within it;this is also called a member class.
class Foo{
private:
//Bar is a member class,nested within Foo.
class Bar{
...
};
};
Pros:This is useful when the nested(or member)class is only used by the enclosing class;making it a member puts it in the enclosing class scope rather than polluting the outer scope with the class name.Nested classes can be forward declared within the enclosing class and then defined in https://www.sodocs.net/doc/aa10598413.html, file to avoid including the nested class definition in the enclosing class declaration,since the nested class definition is usually only relevant to the implementation.
Cons:Nested classes can be forward-declared only within the definition of the enclosing class.Thus,any header file manipulating a Foo::Bar*pointer will have to include the full class declaration for Foo.
Decision:Do not make nested classes public unless they are actually part of the interface,e.g.,a class that holds a set of options for some method.
Nonmember,Static Member,and Global Functions
link▽Prefer nonmember functions within a namespace or static member functions to global functions;use completely global functions rarely.
Pros:Nonmember and static member functions can be useful in some situations.Putting nonmember functions in a namespace avoids polluting the global namespace.
Cons:Nonmember and static member functions may make more sense as members of a new class,especially if they access external resources or have significant dependencies.
Decision:
Sometimes it is useful,or even necessary,to define a function not bound to a class instance.Such a function can be either a static member or a nonmember function.Nonmember functions should not depend on external variables,and should nearly always exist in a namespace.Rather than creating classes only to group static member functions which do not share static data,use namespaces instead.
Functions defined in the same compilation unit as production classes may introduce unnecessary coupling and link-time dependencies when directly called from other compilation units;static member functions are particularly susceptible to this.Consider extracting a new class,or placing the functions in a namespace possibly in a separate library.
If you must define a nonmember function and it is only needed in https://www.sodocs.net/doc/aa10598413.html, file,use an unnamed namespace or static linkage(eg static int Foo(){...})to limit its scope.
Local Variables
link▽Place a function's variables in the narrowest scope possible,and initialize variables in the declaration.
C++allows you to declare variables anywhere in a function.We encourage you to declare them in as local a scope as possible,and as close to the first use as possible.This makes it easier for the reader to find the declaration and see what type the variable is and what it was initialized to.In particular,initialization should be used instead of declaration and assignment,e.g.
int i;
i=f();//Bad--initialization separate from declaration.
int j=g();//Good--declaration has initialization.
Note that gcc implements for(int i=0;i<10;++i)correctly(the scope of i is only the scope of the for loop),so you can then reuse i in another for loop in the same scope.It also correctly scopes declarations in if and while statements,e.g.
while(const char*p=strchr(str,'/'))str=p+1;
There is one caveat:if the variable is an object,its constructor is invoked every time it enters scope and is created,and its destructor is invoked every time it goes out of scope.
//Inefficient implementation:
for(int i=0;i<1000000;++i){
Foo f;//My ctor and dtor get called 1000000 times each.
f.DoSomething(i);
}
It may be more efficient to declare such a variable used in a loop outside that loop:
Foo f;//My ctor and dtor get called once each.
for(int i=0;i<1000000;++i){
f.DoSomething(i);
}
Static and Global Variables
link▽Static or global variables of class type are forbidden:they cause hard-to-find bugs due to indeterminate order of construction and destruction.
Objects with static storage duration,including global variables,static variables,static class member variables,and function static variables,must be Plain Old Data(POD):only ints,chars,floats,or pointers,or arrays/structs of POD.
The order in which class constructors and initializers for static variables are called is only partially specified in C++and can even change from build to build,which can cause bugs that are difficult to find.Therefore in addition to banning globals of class type,we do not allow static POD variables to be initialized with the result of a function,unless that function(such as getenv(),or getpid())does not itself depend on any other globals.
Likewise,the order in which destructors are called is defined to be the reverse of the order in which the constructors were called.Since constructor order is indeterminate,so is destructor order.For example,at program-end time a static variable might have been destroyed,but code still running--perhaps in another thread--tries to access it and fails.Or the destructor for a static'string'variable might be run prior to the destructor for another variable that contains a reference to that string.
As a result we only allow static variables to contain POD data.This rule completely disallows vector(use C arrays instead),or string(use const char[]).
If you need a static or global variable of a class type,consider initializing a pointer(which will never be freed),from either your main()function or from pthread_once().Note that this must be a raw pointer,not a"smart"pointer,since the smart pointer's destructor will have the order-of-destructor issue that we are trying to avoid.
Classes
Classes are the fundamental unit of code in C++.Naturally,we use them extensively.This section lists the main dos and don'ts you should follow when writing a class.
Doing Work in Constructors
link▽In general,constructors should merely set member variables to their initial values.Any complex initialization should go in an explicit Init()method.
Definition:It is possible to perform initialization in the body of the constructor.
Pros:Convenience in typing.No need to worry about whether the class has been initialized or not.
Cons:The problems with doing work in constructors are:
?There is no easy way for constructors to signal errors,short of using exceptions(which are forbidden).
?If the work fails,we now have an object whose initialization code failed,so it may be an indeterminate state.
?If the work calls virtual functions,these calls will not get dispatched to the subclass implementations.Future modification to your class can quietly introduce this problem even if your class is not currently subclassed,causing much confusion.
?If someone creates a global variable of this type(which is against the rules,but still),the constructor code will be called before main(),possibly breaking some implicit assumptions in the constructor code.For instance,gflags will not yet have been initialized.
Decision:If your object requires non-trivial initialization,consider having an explicit Init()method.In particular,constructors should not call virtual functions,attempt to raise errors,access potentially uninitialized global variables,etc.
Default Constructors
link▽You must define a default constructor if your class defines member variables and has no other constructors.Otherwise the compiler will do it for you,badly.
Definition:The default constructor is called when we new a class object with no arguments.It is always called when calling new[](for arrays).
Pros:Initializing structures by default,to hold"impossible"values,makes debugging much easier.
Cons:Extra work for you,the code writer.
Decision:
If your class defines member variables and has no other constructors you must define a default constructor(one that takes no arguments).It should preferably initialize the object in such a way that its internal state is consistent and valid.
The reason for this is that if you have no other constructors and do not define a default constructor,the compiler will generate one for you.This compiler generated constructor may not initialize your object sensibly.
If your class inherits from an existing class but you add no new member variables,you are not required to have a default constructor. Explicit Constructors
link▽Use the C++keyword explicit for constructors with one argument.
Definition:Normally,if a constructor takes one argument,it can be used as a conversion.For instance,if you define Foo::Foo(string name)and then pass a string to a function that expects a Foo,the constructor will be called to convert the string into a Foo and will pass the Foo to your function for you.This can be convenient but is also a source of trouble when things get converted and new objects created without you meaning them to.Declaring a constructor explicit prevents it from being invoked implicitly as a conversion.
Pros:Avoids undesirable conversions.
Cons:None.
Decision:
We require all single argument constructors to be explicit.Always put explicit in front of one-argument constructors in the class definition:explicit Foo(string name);
The exception is copy constructors,which,in the rare cases when we allow them,should probably not be explicit.Classes that are intended to be transparent wrappers around other classes are also exceptions.Such exceptions should be clearly marked with comments.
Copy Constructors
link▽Provide a copy constructor and assignment operator only when necessary.Otherwise,disable them with DISALLOW_COPY_AND_ASSIGN.
Definition:The copy constructor and assignment operator are used to create copies of objects.The copy constructor is implicitly invoked by the compiler in some situations,e.g.passing objects by value.
Pros:Copy constructors make it easy to copy objects.STL containers require that all contents be copyable and assignable.Copy constructors can be more efficient than CopyFrom()-style workarounds because they combine construction with copying,the compiler can elide them in some contexts,and they make it easier to avoid heap allocation.
Cons:Implicit copying of objects in C++is a rich source of bugs and of performance problems.It also reduces readability,as it becomes hard to track which objects are being passed around by value as opposed to by reference,and therefore where changes to an object are reflected.
Decision:
Few classes need to be copyable.Most should have neither a copy constructor nor an assignment operator.In many situations,a pointer or reference will work just as well as a copied value,with better performance.For example,you can pass function parameters by reference or pointer instead of by value,and you can store pointers rather than objects in an STL container.
If your class needs to be copyable,prefer providing a copy method,such as CopyFrom()or Clone(),rather than a copy constructor,because such methods cannot be invoked implicitly.If a copy method is insufficient in your situation(e.g.for performance reasons,or because your class needs to be stored by value in an STL container),provide both a copy constructor and assignment operator.
If your class does not need a copy constructor or assignment operator,you must explicitly disable them.To do so,add dummy declarations for the copy constructor and assignment operator in the private:section of your class,but do not provide any corresponding definition(so that any attempt to use them results in a link error).
For convenience,a DISALLOW_COPY_AND_ASSIGN macro can be used:
//A macro to disallow the copy constructor and operator=functions
//This should be used in the private:declarations for a class
#define DISALLOW_COPY_AND_ASSIGN(TypeName)\
TypeName(const TypeName&);\
void operator=(const TypeName&)
Then,in class Foo:
class Foo{
public:
Foo(int f);
~Foo();
private:
DISALLOW_COPY_AND_ASSIGN(Foo);
};
Structs vs.Classes
link▽Use a struct only for passive objects that carry data;everything else is a class.
The struct and class keywords behave almost identically in C++.We add our own semantic meanings to each keyword,so you should use the appropriate keyword for the data-type you're defining.
structs should be used for passive objects that carry data,and may have associated constants,but lack any functionality other than access/setting the data members.The accessing/setting of fields is done by directly accessing the fields rather than through method invocations.Methods should not provide behavior but should only be used to set up the data members,e.g.,constructor,destructor,Initialize(),Reset(),Validate().
If more functionality is required,a class is more appropriate.If in doubt,make it a class.
For consistency with STL,you can use struct instead of class for functors and traits.
Note that member variables in structs and classes have different naming rules.
Inheritance
link▽Composition is often more appropriate than inheritance.When using inheritance,make it public.
Definition:When a sub-class inherits from a base class,it includes the definitions of all the data and operations that the parent base class defines.In practice,inheritance is used in two major ways in C++:implementation inheritance,in which actual code is inherited by the child,and interface inheritance,in which only method names are inherited.
Pros:Implementation inheritance reduces code size by re-using the base class code as it specializes an existing type.Because inheritance is a compile-time declaration,you and the compiler can understand the operation and detect errors.Interface inheritance can be used to programmatically enforce that a class expose a particular API.Again,the compiler can detect errors,in this case,when a class does not define a necessary method of the API.
Cons:For implementation inheritance,because the code implementing a sub-class is spread between the base and the sub-class,it can be more difficult to understand an implementation.The sub-class cannot override functions that are not virtual,so the sub-class cannot change implementation.The base class may also define some data members,so that specifies physical layout of the base class.
Decision:
All inheritance should be public.If you want to do private inheritance,you should be including an instance of the base class as a member instead.
Do not overuse implementation https://www.sodocs.net/doc/aa10598413.html,position is often more appropriate.Try to restrict use of inheritance to the"is-a"case:Bar subclasses Foo if it can reasonably be said that Bar"is a kind of"Foo.
Make your destructor virtual if necessary.If your class has virtual methods,its destructor should be virtual.
Limit the use of protected to those member functions that might need to be accessed from subclasses.Note that data members should be private.
When redefining an inherited virtual function,explicitly declare it virtual in the declaration of the derived class.Rationale:If virtual is omitted,the reader has to check all ancestors of the class in question to determine if the function is virtual or not.
Multiple Inheritance
link▽Only very rarely is multiple implementation inheritance actually useful.We allow multiple inheritance only when at most one of the base classes has an implementation;all other base classes must be pure interface classes tagged with the Interface suffix.
Definition:Multiple inheritance allows a sub-class to have more than one base class.We distinguish between base classes that are pure interfaces and those that have an implementation.
Pros:Multiple implementation inheritance may let you re-use even more code than single inheritance(see Inheritance).
Cons:Only very rarely is multiple implementation inheritance actually useful.When multiple implementation inheritance seems like the solution,you can usually find a different,more explicit,and cleaner solution.
Decision:Multiple inheritance is allowed only when all superclasses,with the possible exception of the first one,are pure interfaces.In order to ensure that they remain pure interfaces,they must end with the Interface suffix.
Note:There is an exception to this rule on Windows.
Interfaces
link▽Classes that satisfy certain conditions are allowed,but not required,to end with an Interface suffix.
Definition:
A class is a pure interface if it meets the following requirements:
?It has only public pure virtual("=0")methods and static methods(but see below for destructor).
?It may not have non-static data members.
?It need not have any constructors defined.If a constructor is provided,it must take no arguments and it must be protected.
?If it is a subclass,it may only be derived from classes that satisfy these conditions and are tagged with the Interface suffix.
An interface class can never be directly instantiated because of the pure virtual method(s)it declares.To make sure all implementations of the interface can be destroyed correctly,they must also declare a virtual destructor(in an exception to the first rule,this should not be pure).See Stroustrup,The C++Programming Language,3rd edition,section 12.4 for details.
Pros:Tagging a class with the Interface suffix lets others know that they must not add implemented methods or non static data members.This is particularly important in the case of multiple inheritance.Additionally,the interface concept is already well-understood by Java programmers.
Cons:The Interface suffix lengthens the class name,which can make it harder to read and understand.Also,the interface property may be considered an implementation detail that shouldn't be exposed to clients.
Decision:A class may end with Interface only if it meets the above requirements.We do not require the converse,however:classes that meet the above requirements are not required to end with Interface.
Operator Overloading
link▽Do not overload operators except in rare,special circumstances.
Definition:A class can define that operators such as+and/operate on the class as if it were a built-in type.
Pros:Can make code appear more intuitive because a class will behave in the same way as built-in types(such as int).Overloaded operators are more playful names for functions that are less-colorfully named,such as Equals()or Add().For some template functions to work correctly,you may need to define operators.
Cons:While operator overloading can make code more intuitive,it has several drawbacks:
?It can fool our intuition into thinking that expensive operations are cheap,built-in operations.
?It is much harder to find the call sites for overloaded operators.Searching for Equals()is much easier than searching for relevant invocations of==.
?Some operators work on pointers too,making it easy to introduce bugs.Foo+4may do one thing,while&Foo+4does something totally different.The compiler does not complain for either of these,making this very hard to debug.
Overloading also has surprising ramifications.For instance,if a class overloads unary operator&,it cannot safely be forward-declared.
Decision:
In general,do not overload operators.The assignment operator(operator=),in particular,is insidious and should be avoided.You can define functions like Equals()and CopyFrom()if you need them.Likewise,avoid the dangerous unary operator&at all costs,if there's any possibility the class might be forward-declared.
However,there may be rare cases where you need to overload an operator to interoperate with templates or"standard"C++classes(such as operator<<(ostream&,const T&)for logging).These are acceptable if fully justified,but you should try to avoid these whenever possible.In particular,do not overload operator==or operator Some of the STL algorithms do require you to overload operator==,and you may do so in these cases,provided you document why. See also Copy Constructors and Function Overloading. Access Control link▽Make data members private,and provide access to them through accessor functions as needed(for technical reasons,we allow data members of a test fixture class to be protected when using Google Test).Typically a variable would be called foo_and the accessor function foo().You may also want a mutator function set_foo().Exception:static const data members(typically called kFoo)need not be private. The definitions of accessors are usually inlined in the header file. See also Inheritance and Function Names. Declaration Order link▽Use the specified order of declarations within a class:public:before private:,methods before data members(variables),etc. Your class definition should start with its public:section,followed by its protected:section and then its private:section.If any of these sections are empty,omit them. Within each section,the declarations generally should be in the following order: ?Typedefs and Enums ?Constants(static const data members) ?Constructors ?Destructor ?Methods,including static methods ?Data Members(except static const data members) Friend declarations should always be in the private section,and the DISALLOW_COPY_AND_ASSIGN macro invocation should be at the end of the private:section.It should be the last thing in the class.See Copy Constructors. Method definitions in the https://www.sodocs.net/doc/aa10598413.html, file should be the same as the declaration order,as much as possible. Do not put large method definitions inline in the class https://www.sodocs.net/doc/aa10598413.html,ually,only trivial or performance-critical,and very short,methods may be defined inline.See Inline Functions for more details. Write Short Functions link▽Prefer small and focused functions. We recognize that long functions are sometimes appropriate,so no hard limit is placed on functions length.If a function exceeds about 40 lines,think about whether it can be broken up without harming the structure of the program. Even if your long function works perfectly now,someone modifying it in a few months may add new behavior.This could result in bugs that are hard to find.Keeping your functions short and simple makes it easier for other people to read and modify your code. You could find long and complicated functions when working with some code.Do not be intimidated by modifying existing code:if working with such a function proves to be difficult,you find that errors are hard to debug,or you want to use a piece of it in several different contexts,consider breaking up the function into smaller and more manageable pieces. Google-Specific Magic There are various tricks and utilities that we use to make C++code more robust,and various ways we use C++that may differ from what you see elsewhere. Smart Pointers link▽If you actually need pointer semantics,scoped_ptr is great.You should only use std::tr1::shared_ptr with a non-const referent when it is truly necessary to share ownership of an object(e.g.inside an STL container).You should never use auto_ptr. Definition:"Smart"pointers are objects that act like pointers,but automate management of the underlying memory. Pros:Smart pointers are extremely useful for preventing memory leaks,and are essential for writing exception-safe code.They also formalize and document the ownership of dynamically allocated memory. Cons:We prefer designs in which objects have single,fixed owners.Smart pointers which enable sharing or transfer of ownership can act as a tempting alternative to a careful design of ownership semantics,leading to confusing code and even bugs in which memory is never deleted.The semantics of smart pointers(especially auto_ptr)can be nonobvious and confusing.The exception-safety benefits of smart pointers are not decisive,since we do not allow exceptions. Decision: scoped_ptr Straightforward and https://www.sodocs.net/doc/aa10598413.html,e wherever appropriate. auto_ptr Confusing and bug-prone ownership-transfer semantics.Do not use. shared_ptr Safe with const referents(i.e.shared_ptr cpplint link▽Use cpplint.py to detect style errors. cpplint.py is a tool that reads a source file and identifies many style errors.It is not perfect,and has both false positives and false negatives,but it is still a valuable tool.False positives can be ignored by putting//NOLINT at the end of the line. Some projects have instructions on how to run cpplint.py from their project tools.If the project you are contributing to does not,you can download cpplint.py separately. Other C++Features Reference Arguments link▽All parameters passed by reference must be labeled const. Definition:In C,if a function needs to modify a variable,the parameter must use a pointer,eg int foo(int*pval).In C++,the function can alternatively declare a reference parameter:int foo(int&val). Pros:Defining a parameter as reference avoids ugly code like(*pval)++.Necessary for some applications like copy constructors.Makes it clear,unlike with pointers,that NULL is not a possible value. Cons:References can be confusing,as they have value syntax but pointer semantics. Decision: Within function parameter lists all references must be const: void Foo(const string&in,string*out); In fact it is a very strong convention in Google code that input arguments are values or const references while output arguments are pointers.Input parameters may be const pointers,but we never allow non-const reference parameters. One case when you might want an input parameter to be a const pointer is if you want to emphasize that the argument is not copied,so it must exist for the lifetime of the object;it is usually best to document this in comments as well.STL adapters such as bind2nd and mem_fun do not permit reference parameters,so you must declare functions with pointer parameters in these cases,too. Function Overloading link▽Use overloaded functions(including constructors)only if a reader looking at a call site can get a good idea of what is happening without having to first figure out exactly which overload is being called. Definition: You may write a function that takes a const string&and overload it with another that takes const char*. class MyClass{ public: void Analyze(const string&text); void Analyze(const char*text,size_t textlen); }; Pros:Overloading can make code more intuitive by allowing an identically-named function to take different arguments.It may be necessary for templatized code,and it can be convenient for Visitors. Cons:If a function is overloaded by the argument types alone,a reader may have to understand C++'s complex matching rules in order to tell what's going on.Also many people are confused by the semantics of inheritance if a derived class overrides only some of the variants of a function. Decision:If you want to overload a function,consider qualifying the name with some information about the arguments,e.g.,AppendString(),AppendInt()rather than just Append(). Default Arguments link▽We do not allow default function parameters,except in a few uncommon situations explained below. Pros:Often you have a function that uses lots of default values,but occasionally you want to override the defaults.Default parameters allow an easy way to do this without having to define many functions for the rare exceptions. Cons:People often figure out how to use an API by looking at existing code that uses it.Default parameters are more difficult to maintain because copy-and-paste from previous code may not reveal all the parameters.Copy-and-pasting of code segments can cause major problems when the default arguments are not appropriate for the new code. Decision: Except as described below,we require all arguments to be explicitly specified,to force programmers to consider the API and the values they are passing for each argument rather than silently accepting defaults they may not be aware of. One specific exception is when default arguments are used to simulate variable-length argument lists. //Support up to 4 params by using a default empty AlphaNum. string StrCat(const AlphaNum&a, const AlphaNum&b=gEmptyAlphaNum, const AlphaNum&c=gEmptyAlphaNum, const AlphaNum&d=gEmptyAlphaNum); Variable-Length Arrays and alloca() link▽We do not allow variable-length arrays or alloca(). Pros:Variable-length arrays have natural-looking syntax.Both variable-length arrays and alloca()are very efficient. Cons:Variable-length arrays and alloca are not part of Standard C++.More importantly,they allocate a data-dependent amount of stack space that can trigger difficult-to-find memory overwriting bugs:"It ran fine on my machine,but dies mysteriously in production". Decision:Use a safe allocator instead,such as scoped_ptr/scoped_array. Friends link▽We allow use of friend classes and functions,within reason. Friends should usually be defined in the same file so that the reader does not have to look in another file to find uses of the private members of a class.A common use of friend is to have a FooBuilder class be a friend of Foo so that it can construct the inner state of Foo correctly,without exposing this state to the world.In some cases it may be useful to make a unittest class a friend of the class it tests. Friends extend,but do not break,the encapsulation boundary of a class.In some cases this is better than making a member public when you want to give only one other class access to it.However,most classes should interact with other classes solely through their public members. Exceptions link▽We do not use C++exceptions. Pros: ?Exceptions allow higher levels of an application to decide how to handle"can't happen"failures in deeply nested functions,without the obscuring and error-prone bookkeeping of error codes. ?Exceptions are used by most other modern https://www.sodocs.net/doc/aa10598413.html,ing them in C++would make it more consistent with Python,Java,and the C++that others are familiar with. ?Some third-party C++libraries use exceptions,and turning them off internally makes it harder to integrate with those libraries. ?Exceptions are the only way for a constructor to fail.We can simulate this with a factory function or an Init()method,but these require heap allocation or a new"invalid"state,respectively. ?Exceptions are really handy in testing frameworks. Cons: ?When you add a throw statement to an existing function,you must examine all of its transitive callers.Either they must make at least the basic exception safety guarantee,or they must never catch the exception and be happy with the program terminating as a result.For instance,if f()calls g()calls h(),and h throws an exception that f catches,g has to be careful or it may not clean up properly. ?More generally,exceptions make the control flow of programs difficult to evaluate by looking at code:functions may return in places you don't expect.This causes maintainability and debugging difficulties.You can minimize this cost via some rules on how and where exceptions can be used,but at the cost of more that a developer needs to know and understand. ?Exception safety requires both RAII and different coding practices.Lots of supporting machinery is needed to make writing correct exception-safe code easy.Further,to avoid requiring readers to understand the entire call graph,exception-safe code must isolate logic that writes to persistent state into a"commit"phase.This will have both benefits and costs(perhaps where you're forced to obfuscate code to isolate the commit).Allowing exceptions would force us to always pay those costs even when they're not worth it. ?Turning on exceptions adds data to each binary produced,increasing compile time(probably slightly)and possibly increasing address space pressure. ?The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so.For example,invalid user input should not cause exceptions to be thrown.We would need to make the style guide even longer to document these restrictions! Decision: On their face,the benefits of using exceptions outweigh the costs,especially in new projects.However,for existing code,the introduction of exceptions has implications on all dependent code.If exceptions can be propagated beyond a new project,it also becomes problematic to integrate the new project into existing exception-free code.Because most existing C++code at Google is not prepared to deal with exceptions,it is comparatively difficult to adopt new code that generates exceptions. Given that Google's existing code is not exception-tolerant,the costs of using exceptions are somewhat greater than the costs in a new project.The conversion process would be slow and error-prone.We don't believe that the available alternatives to exceptions,such as error codes and assertions,introduce a significant burden. Our advice against using exceptions is not predicated on philosophical or moral grounds,but practical ones.Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions,we need to advise against exceptions in Google open-source projects as well.Things would probably be different if we had to do it all over again from scratch. There is an exception to this rule(no pun intended)for Windows code. Run-Time Type Information(RTTI) link▽We do not use Run Time Type Information(RTTI). Definition:RTTI allows a programmer to query the C++class of an object at run time. Pros: It is useful in some unittests.For example,it is useful in tests of factory classes where the test has to verify that a newly created object has the expected dynamic type. In rare circumstances,it is useful even outside of tests. Cons:A query of type during run-time typically means a design problem.If you need to know the type of an object at runtime,that is often an indication that you should reconsider the design of your class. Decision: Do not use RTTI,except in unittests.If you find yourself in need of writing code that behaves differently based on the class of an object,consider one of the alternatives to querying the type. Virtual methods are the preferred way of executing different code paths depending on a specific subclass type.This puts the work within the object itself. If the work belongs outside the object and instead in some processing code,consider a double-dispatch solution,such as the Visitor design pattern.This allows a facility outside the object itself to determine the type of class using the built-in type system. If you think you truly cannot use those ideas,you may use RTTI.But think twice about it.:-)Then think twice again.Do not hand-implement an RTTI-like workaround.The arguments against RTTI apply just as much to workarounds like class hierarchies with type tags. Casting link▽Use C++casts like static_cast<>().Do not use other cast formats like int y=(int)x;or int y=int(x);. Definition:C++introduced a different cast system from C that distinguishes the types of cast operations. Pros:The problem with C casts is the ambiguity of the operation;sometimes you are doing a conversion(e.g.,(int)3.5)and sometimes you are doing a cast(e.g.,(int)"hello");C++casts avoid this.Additionally C++casts are more visible when searching for them. Cons:The syntax is nasty. Decision: Do not use C-style casts.Instead,use these C++-style casts. ?Use static_cast as the equivalent of a C-style cast that does value conversion,or when you need to explicitly up-cast a pointer from a class to its superclass. ?Use const_cast to remove the const qualifier(see const). ?Use reinterpret_cast to do unsafe conversions of pointer types to and from integer and other pointer https://www.sodocs.net/doc/aa10598413.html,e this only if you know what you are doing and you understand the aliasing issues. ?Do not use dynamic_cast except in test code.If you need to know type information at runtime in this way outside of a unittest,you probably have a design flaw. Streams link▽Use streams only for logging. Definition:Streams are a replacement for printf()and scanf(). Pros:With streams,you do not need to know the type of the object you are printing.You do not have problems with format strings not matching the argument list.(Though with gcc,you do not have that problem with printf either.)Streams have automatic constructors and destructors that open and close the relevant files. Cons:Streams make it difficult to do functionality like pread().Some formatting(particularly the common format string idiom%.*s)is difficult if not impossible to do efficiently using streams without using printf-like hacks.Streams do not support operator reordering(the%1s directive),which is helpful for internationalization. Decision: Do not use streams,except where required by a logging https://www.sodocs.net/doc/aa10598413.html,e printf-like routines instead. There are various pros and cons to using streams,but in this case,as in many other cases,consistency trumps the debate.Do not use streams in your code. Extended Discussion There has been debate on this issue,so this explains the reasoning in greater depth.Recall the Only One Way guiding principle:we want to make sure that whenever we do a certain type of I/O,the code looks the same in all those places.Because of this,we do not want to allow users to decide between using streams or using printf plus Read/Write/etc.Instead,we should settle on one or the other.We made an exception for logging because it is a pretty specialized application,and for historical reasons. Proponents of streams have argued that streams are the obvious choice of the two,but the issue is not actually so clear.For every advantage of streams they point out,there is an equivalent disadvantage.The biggest advantage is that you do not need to know the type of the object to be printing.This is a fair point.But,there is a downside:you can easily use the wrong type,and the compiler will not warn you.It is easy to make this kind of mistake without knowing when using streams. cout< cout<<*this;//Prints the contents The compiler does not generate an error because< Some say printf formatting is ugly and hard to read,but streams are often no better.Consider the following two fragments,both with the same typo.Which is easier to discover? cerr<<"Error connecting to'"< <<":"< fprintf(stderr,"Error connecting to'%s:%u:%s", foo->bar()->hostname.first,foo->bar()->hostname.second, strerror(errno)); And so on and so forth for any issue you might bring up.(You could argue,"Things would be better with the right wrappers,"but if it is true for one scheme,is it not also true for the other?Also,remember the goal is to make the language smaller,not add yet more machinery that someone has to learn.) Either path would yield different advantages and disadvantages,and there is not a clearly superior solution.The simplicity doctrine mandates we settle on one of them though,and the majority decision was on printf+read/write. Preincrement and Predecrement link▽Use prefix form(++i)of the increment and decrement operators with iterators and other template objects. Definition:When a variable is incremented(++i or i++)or decremented(--i or i--)and the value of the expression is not used,one must decide whether to preincrement(decrement)or postincrement(decrement). Pros:When the return value is ignored,the"pre"form(++i)is never less efficient than the"post"form(i++),and is often more efficient.This is because post-increment(or decrement)requires a copy of i to be made,which is the value of the expression.If i is an iterator or other non-scalar type,copying i could be expensive.Since the two types of increment behave the same when the value is ignored,why not just always pre-increment? Cons:The tradition developed,in C,of using post-increment when the expression value is not used,especially in for loops.Some find post-increment easier to read,since the"subject"(i)precedes the"verb"(++),just like in English. Decision:For simple scalar(non-object)values there is no reason to prefer one form and we allow either.For iterators and other template types,use pre-increment. Use of const link▽We strongly recommend that you use const whenever it makes sense to do so. Definition:Declared variables and parameters can be preceded by the keyword const to indicate the variables are not changed(e.g.,const int foo).Class functions can have the const qualifier to indicate the function does not change the state of the class member variables(e.g.,class Foo{int Bar(char c)const;};). Pros:Easier for people to understand how variables are being used.Allows the compiler to do better type checking,and,conceivably,generate better code.Helps people convince themselves of program correctness because they know the functions they call are limited in how they can modify your variables.Helps people know what functions are safe to use without locks in multi-threaded programs. Cons:const is viral:if you pass a const variable to a function,that function must have const in its prototype(or the variable will need a const_cast).This can be a particular problem when calling library functions. Decision: const variables,data members,methods and arguments add a level of compile-time type checking;it is better to detect errors as soon as possible.Therefore we strongly recommend that you use const whenever it makes sense to do so: ?If a function does not modify an argument passed by reference or by pointer,that argument should be const. ?Declare methods to be const whenever possible.Accessors should almost always be const.Other methods should be const if they do not modify any data members,do not call any non-const methods,and do not return a non-const pointer or non-const reference to a data member. ?Consider making data members const whenever they do not need to be modified after construction. However,do not go crazy with const.Something like const int*const*const x;is likely overkill,even if it accurately describes how const x is.Focus on what's really useful to know:in this case,const int**x is probably sufficient. The mutable keyword is allowed but is unsafe when used with threads,so thread safety should be carefully considered first. Where to put the const Some people favor the form int const*foo to const int*foo.They argue that this is more readable because it's more consistent:it keeps the rule that const always follows the object it's describing.However,this consistency argument doesn't apply in this case,because the"don't go crazy"dictum eliminates most of the uses you'd have to be consistent with.Putting the const first is arguably more readable,since it follows English in putting the"adjective"(const)before the"noun"(int). That said,while we encourage putting const first,we do not require it.But be consistent with the code around you! Integer Types link▽Of the built-in C++integer types,the only one used is int.If a program needs a variable of a different size,use a precise-width integer type from Definition:C++does not specify the sizes of its integer types.Typically people assume that short is 16 bits,int is 32 bits,long is 32 bits and long long is 64 bits. Pros:Uniformity of declaration. Cons:The sizes of integral types in C++can vary based on compiler and architecture. Decision: We use int very often,for integers we know are not going to be too big,e.g.,loop https://www.sodocs.net/doc/aa10598413.html,e plain old int for such things.You should assume that an int is at least 32 bits,but don't assume that it has more than 32 bits.If you need a 64-bit integer type,use int64_t or uint64_t. For integers we know can be"big",use int64_t. You should not use the unsigned integer types such as uint32_t,unless the quantity you are representing is really a bit pattern rather than a number,or unless you need defined twos-complement overflow.In particular,do not use unsigned types to say a number will never be negative.Instead,use assertions for this. On Unsigned Integers Some people,including some textbook authors,recommend using unsigned types to represent numbers that are never negative.This is intended as a form of self-documentation.However,in C,the advantages of such documentation are outweighed by the real bugs it can introduce.Consider: for(unsigned int i=foo.Length()-1;i>=0;--i)... This code will never terminate!Sometimes gcc will notice this bug and warn you,but often it will not.Equally bad bugs can occur when comparing signed and unsigned variables.Basically,C's type-promotion scheme causes unsigned types to behave differently than one might expect. So,document that a variable is non-negative using assertions.Don't use an unsigned type. 64-bit Portability link▽Code should be 64-bit and 32-bit friendly.Bear in mind problems of printing,comparisons,and structure alignment. printf()specifiers for some types are not cleanly portable between 32-bit and 64-bit systems.C99 defines some portable format specifiers.Unfortunately,MSVC 7.1 does not understand some of these specifiers and the standard is missing a few,so we have to define our own ugly versions in some cases(in the style of the standard include file inttypes.h): //printf macros for size_t,in the style of inttypes.h #ifdef_LP64 #define__PRIS_PREFIX"z" #else #define__PRIS_PREFIX #endif //Use these macros after a%in a printf format string //to get correct 32/64 bit behavior,like this: //size_t size=records.size(); //printf("%"PRIuS"\n",size); #define PRIdS__PRIS_PREFIX"d" #define PRIxS__PRIS_PREFIX"x" #define PRIuS__PRIS_PREFIX"u" #define PRIXS__PRIS_PREFIX"X" #define PRIoS__PRIS_PREFIX"o" Type DO NOT use DO use Notes void*(or any pointer) %lx%p int64_t%qd,%lld%"PRId64" uint64_t%qu,%llu,%llx%"PRIu64",%"PRIx64" size_t%u%"PRIuS",%"PRIxS"C99 specifies%zu ptrdiff_t%d%"PRIdS"C99 specifies%zd Note that the PRI*macros expand to independent strings which are concatenated by the compiler.Hence if you are using a non-constant format string,you need to insert the value of the macro into the format,rather than the name.It is still possible,as usual,to include length specifiers,etc.,after the%when using the PRI*macros.So,e.g.printf("x=%30"PRIuS"\n",x)would expand on 32-bit Linux to printf("x=%30""u""\n",x),which the compiler will treat as printf("x=%30u\n",x). ?Remember that sizeof(void*)!=sizeof(int).Use intptr_t if you want a pointer-sized integer. ?You may need to be careful with structure alignments,particularly for structures being stored on disk.Any class/structure with a int64_t/uint64_t member will by default end up being 8-byte aligned on a 64-bit system.If you have such structures being shared on disk between 32-bit and 64-bit code,you will need to ensure that they are packed the same on both architectures.Most compilers offer a way to alter structure alignment.For gcc,you can use__attribute__((packed)).MSVC offers#pragma pack()and__declspec(align()). ?Use the LL or ULL suffixes as needed to create 64-bit constants.For example: int64_t my_value=0x123456789LL; uint64_t my_mask=3ULL<<48; ?If you really need different code on 32-bit and 64-bit systems,use#ifdef_LP64 to choose between the code variants.(But please avoid this if possible,and keep any such changes localized.) Preprocessor Macros link▽Be very cautious with macros.Prefer inline functions,enums,and const variables to macros. Macros mean that the code you see is not the same as the code the compiler sees.This can introduce unexpected behavior,especially since macros have global scope. Luckily,macros are not nearly as necessary in C++as they are in C.Instead of using a macro to inline performance-critical code,use an inline function.Instead of using a macro to store a constant,use a const variable.Instead of using a macro to"abbreviate"a long variable name,use a reference.Instead of using a macro to conditionally compile code...well,don't do that at all(except,of course,for the#define guards to prevent double inclusion of header files).It makes testing much more difficult. Macros can do things these other techniques cannot,and you do see them in the codebase,especially in the lower-level libraries.And some of their special features(like stringifying,concatenation,and so forth)are not available through the language proper.But before using a macro,consider carefully whether there's a non-macro way to achieve the same result. The following usage pattern will avoid many problems with macros;if you use macros,follow it whenever possible: ?Don't define macros in a.h file. ?#define macros right before you use them,and#undef them right after. ?Do not just#undef an existing macro before replacing it with your own;instead,pick a name that's likely to be unique. ?Try not to use macros that expand to unbalanced C++constructs,or at least document that behavior well. ?Prefer not using##to generate function/class/variable names. 0 and NULL link▽Use 0 for integers,0.0 for reals,NULL for pointers,and'\0'for chars. Use 0 for integers and 0.0 for reals.This is not controversial. For pointers(address values),there is a choice between 0 and NULL.Bjarne Stroustrup prefers an unadorned 0.We prefer NULL because it looks like a pointer.In fact,some C++compilers,such as gcc 4.1.0,provide special definitions of NULL which enable them to give useful warnings,particularly in situations where sizeof(NULL)is not equal to sizeof(0). Use'\0'for chars.This is the correct type and also makes code more readable. sizeof link▽Use sizeof(varname)instead of sizeof(type)whenever possible. Use sizeof(varname)because it will update appropriately if the type of the variable changes.sizeof(type)may make sense in some cases,but should generally be avoided because it can fall out of sync if the variable's type changes. Struct data; memset(&data,0,sizeof(data)); memset(&data,0,sizeof(Struct)); Boost link▽Use only approved libraries from the Boost library collection. Definition:The Boost library collection is a popular collection of peer-reviewed,free,open-source C++libraries. Pros:Boost code is generally very high-quality,is widely portable,and fills many important gaps in the C++standard library,such as type traits,better binders,and better smart pointers.It also provides an implementation of the TR1 extension to the standard library. Cons:Some Boost libraries encourage coding practices which can hamper readability,such as metaprogramming and other advanced template techniques,and an excessively"functional"style of programming. Decision: In order to maintain a high level of readability for all contributors who might read and maintain code,we only allow an approved subset of Boost features.Currently,the following libraries are permitted: ?Call Traits from boost/call_traits.hpp ?Compressed Pair from boost/compressed_pair.hpp ?Pointer Container from boost/ptr_container except serialization and wrappers for containers not in the C++03 standard(ptr_circular_buffer.hpp and ptr_unordered*) ?Array from boost/array.hpp ?The Boost Graph Library(BGL)from boost/graph,except serialization(adj_list_serialize.hpp)and parallel/distributed algorithms and data structures(boost/graph/parallel/*and boost/graph/distributed/*). ?Property Map from boost/property_map,except parallel/distributed property maps(boost/property_map/parallel/*). ?The part of Iterator that deals with defining iterators:boost/iterator/iterator_adaptor.hpp,boost/iterator/iterator_facade.hpp,and boost/function_output_iterator.hpp We are actively considering adding other Boost features to the list,so this rule may be relaxed in the future. C++0x link▽Use only approved libraries and language extensions from C++0x.Currently,none are approved. Definition:C++0x is the next ISO C++standard,currently in final committee draft form.It contains significant changes both to the language and libraries. Pros:We expect that C++0x will become the next standard,and eventually will be supported by most C++compilers.It standardizes some common C++extensions that we use already,allows shorthands for some operations,and has some safety improvements. Cons: The C++0x standard is substantialy more complex than its predecessor(1,300 pages versus 800 pages),and is unfamilar to many developers.The long-term effects of some features on code readability and maintenance are unknown.We cannot predict when its various features will be implemented uniformly by tools that may be of interest(gcc,icc,clang,Eclipse,etc.). As with Boost,some C++0x extensions encourage coding practices that hamper readability—for example by removing checked redundancy(such as type names)that may be helpful to readers,or by encouraging template metaprogramming.Other extensions duplicate functionality available through existing mechanisms,which may lead to confusion and conversion costs. Decision:Use only C++0x libraries and language features that have been approved for use.Currently,no such features are approved.Features will be approved individually as appropriate. Naming The most important consistency rules are those that govern naming.The style of a name immediately informs us what sort of thing the named entity is:a type,a variable,a function,a constant,a macro,etc.,without requiring us to search for the declaration of that entity.The pattern-matching engine in our brains relies a great deal on these naming rules. Naming rules are pretty arbitrary,but we feel that consistency is more important than individual preferences in this area,so regardless of whether you find them sensible or not,the rules are the rules. General Naming Rules link▽Function names,variable names,and filenames should be descriptive;eschew abbreviation.Types and variables should be nouns,while functions should be"command"verbs. How to Name Give as descriptive a name as possible,within reason.Do not worry about saving horizontal space as it is far more important to make your code immediately understandable by a new reader.Examples of well-chosen names: int num_errors;//Good. int num_completed_connections;//Good. Poorly-chosen names use ambiguous abbreviations or arbitrary characters that do not convey meaning: int n;//Bad-meaningless. int nerr;//Bad-ambiguous abbreviation. int n_comp_conns;//Bad-ambiguous abbreviation. Type and variable names should typically be nouns:e.g.,FileOpener,num_errors. Function names should typically be imperative(that is they should be commands):e.g.,OpenFile(),set_num_errors().There is an exception for accessors,which,described more completely in Function Names,should be named the same as the variable they access. Abbreviations Do not use abbreviations unless they are extremely well known outside your project.For example: //Good //These show proper names with no abbreviations. int num_dns_connections;//Most people know what"DNS"stands for. int price_count_reader;//OK,price count.Makes sense. //Bad! //Abbreviations can be confusing or ambiguous outside a small group. int wgc_connections;//Only your group knows what this stands for. int pc_reader;//Lots of things can be abbreviated"pc". Never abbreviate by leaving out letters: int error_count;//Good. int error_cnt;//Bad. File Names link▽Filenames should be all lowercase and can include underscores(_)or dashes(-).Follow the convention that your project uses.If there is no consistent local pattern to follow,prefer"_". Examples of acceptable file names: my_useful_https://www.sodocs.net/doc/aa10598413.html,myusefulclass_https://www.sodocs.net/doc/aa10598413.html,//_unittest and_regtest are deprecated. C++files should end https://www.sodocs.net/doc/aa10598413.html, and header files should end in.h. Do not use filenames that already exist in/usr/include,such as db.h. In general,make your filenames very specific.For example,use http_server_logs.h rather than logs.h.A very common case is to have a pair of files called,e.g.,foo_bar.h and foo_https://www.sodocs.net/doc/aa10598413.html,,defining a class called FooBar. Inline functions must be in a.h file.If your inline functions are very short,they should go directly into your.h file.However,if your inline functions include a lot of code,they may go into a third file that ends in-inl.h.In a class with a lot of inline code,your class could have three files: url_table.h//The class declaration. url_https://www.sodocs.net/doc/aa10598413.html,//The class definition. url_table-inl.h//Inline functions that include lots of code. See also the section-inl.h Files Type Names link▽Type names start with a capital letter and have a capital letter for each new word,with no underscores:MyExcitingClass,MyExcitingEnum. The names of all types—classes,structs,typedefs,and enums—have the same naming convention.Type names should start with a capital letter and have a capital letter for each new word.No underscores.For example: //classes and structs class UrlTable{... class UrlTableTester{... struct UrlTableProperties{... //typedefs typedef hash_map //enums enum UrlTableErrors{... Variable Names link▽Variable names are all lowercase,with underscores between words.Class member variables have trailing underscores.For instance:my_exciting_local_variable,my_exciting_member_variable_. Common Variable names For example: string table_name;//OK-uses underscore. string tablename;//OK-all lowercase. string tableName;//Bad-mixed case. Class Data Members Data members(also called instance variables or member variables)are lowercase with optional underscores like regular variable names,but always end with a trailing underscore. string table_name_;//OK-underscore at end. string tablename_;//OK. Struct Variables Data members in structs should be named like regular variables without the trailing underscores that data members in classes have. struct UrlTableProperties{ string name; int num_entries; } See Structs vs.Classes for a discussion of when to use a struct versus a class. Global Variables There are no special requirements for global variables,which should be rare in any case,but if you use one,consider prefixing it with g_or some other marker to easily distinguish it from local variables. Constant Names link▽Use a k followed by mixed case:kDaysInAWeek. All compile-time constants,whether they are declared locally,globally,or as part of a class,follow a slightly different naming convention from other https://www.sodocs.net/doc/aa10598413.html,e a k followed by words with uppercase first letters: const int kDaysInAWeek=7; Function Names link▽Regular functions have mixed case;accessors and mutators match the name of the variable:MyExcitingFunction(),MyExcitingMethod(),my_exciting_member_variable(),set_my_exciting_member_variable(). Regular Functions Functions should start with a capital letter and have a capital letter for each new word.No underscores. If your function crashes upon an error,you should append OrDie to the function name.This only applies to functions which could be used by production code and to errors that are reasonably likely to occur during normal operation. AddTableEntry() DeleteUrl() OpenFileOrDie() Accessors and Mutators Accessors and mutators(get and set functions)should match the name of the variable they are getting and setting.This shows an excerpt of a class whose instance variable is num_entries_. class MyClass{ public: ... int num_entries()const{return num_entries_;} void set_num_entries(int num_entries){num_entries_=num_entries;} private: int num_entries_; }; You may also use lowercase letters for other very short inlined functions.For example if a function were so cheap you would not cache the value if you were calling it in a loop,then lowercase naming would be acceptable. Namespace Names link▽Namespace names are all lower-case,and based on project names and possibly their directory structure:google_awesome_project. See Namespaces for a discussion of namespaces and how to name them. Enumerator Names link▽Enumerators should be named either like constants or like macros:either kEnumName or ENUM_NAME. Preferably,the individual enumerators should be named like constants.However,it is also acceptable to name them like macros.The enumeration name,UrlTableErrors(and AlternateUrlTableErrors),is a type,and therefore mixed case. enum UrlTableErrors{ kOK=0, kErrorOutOfMemory, kErrorMalformedInput, }; enum AlternateUrlTableErrors{ OK=0, OUT_OF_MEMORY=1, MALFORMED_INPUT=2, }; Until January 2009,the style was to name enum values like macros.This caused problems with name collisions between enum values and macros.Hence,the change to prefer constant-style naming was put in place.New code should prefer constant-style naming if possible.However,there is no reason to change old code to use constant-style names,unless the old names are actually causing a compile-time problem. Macro Names link▽You're not really going to define a macro,are you?If you do,they're like this:MY_MACRO_THAT_SCARES_SMALL_CHILDREN. Please see the description of macros;in general macros should not be used.However,if they are absolutely needed,then they should be named with all capitals and underscores. #define ROUND(x)... #define PI_ROUNDED 3.0 Exceptions to Naming Rules link▽If you are naming something that is analogous to an existing C or C++entity then you can follow the existing naming convention scheme. bigopen() function name,follows form of open() uint typedef bigpos struct or class,follows form of pos sparse_hash_map STL-like entity;follows STL naming conventions LONGLONG_MAX a constant,as in INT_MAX Comments Though a pain to write,comments are absolutely vital to keeping our code readable.The following rules describe what you should comment and where.But remember:while comments are very important,the best code is self-documenting.Giving sensible names to types and variables is much better than using obscure names that you must then explain through comments. When writing your comments,write for your audience:the next contributor who will need to understand your code.Be generous—the next one may be you! Comment Style link▽Use either the//or/**/syntax,as long as you are consistent. You can use either the//or the/**/syntax;however,//is much more common.Be consistent with how you comment and what style you use where. File Comments link▽Start each file with a copyright notice,followed by a description of the contents of the file. Legal Notice and Author Line Every file should contain the following items,in order: ? a copyright statement(for example,Copyright 2008 Google Inc.) ? a license boilerplate.Choose the appropriate boilerplate for the license used by the project(for example,Apache 2.0,BSD,LGPL,GPL) ?an author line to identify the original author of the file If you make significant changes to a file that someone else originally wrote,add yourself to the author line.This can be very helpful when another contributor has questions about the file and needs to know whom to contact about it. File Contents Every file should have a comment at the top,below the copyright notice and author line,that describes the contents of the file. Generally a.h file will describe the classes that are declared in the file with an overview of what they are for and how they are https://www.sodocs.net/doc/aa10598413.html, file should contain more information about implementation details or discussions of tricky algorithms.If you feel the implementation details or a discussion of the algorithms would be useful for someone reading the.h,feel free to put it there instead,but mention in https://www.sodocs.net/doc/aa10598413.html, that the documentation is in the.h file. Do not duplicate comments in both the.h and https://www.sodocs.net/doc/aa10598413.html,.Duplicated comments diverge. Class Comments link▽Every class definition should have an accompanying comment that describes what it is for and how it should be used. //Iterates over the contents of a GargantuanTable.Sample usage: //GargantuanTableIterator*iter=table->NewIterator(); //for(iter->Seek("foo");!iter->done();iter->Next()){ //process(iter->key(),iter->value()); //} //delete iter; class GargantuanTableIterator{ ... }; If you have already described a class in detail in the comments at the top of your file feel free to simply state"See comment at top of file for a complete description",but be sure to have some sort of comment. Document the synchronization assumptions the class makes,if any.If an instance of the class can be accessed by multiple threads,take extra care to document the rules and invariants surrounding multithreaded use. Function Comments link▽Declaration comments describe use of the function;comments at the definition of a function describe operation. Function Declarations Every function declaration should have comments immediately preceding it that describe what the function does and how to use it.These comments should be descriptive("Opens the file")rather than imperative("Open the file");the comment describes the function,it does not tell the function what to do.In general,these comments do not describe how the function performs its task.Instead,that should be left to comments in the function definition. Types of things to mention in comments at the function declaration: ?What the inputs and outputs are. ?For class member functions:whether the object remembers reference arguments beyond the duration of the method call,and whether it will free them or not. ?If the function allocates memory that the caller must free. ?Whether any of the arguments can be NULL. ?If there are any performance implications of how a function is used. ?If the function is re-entrant.What are its synchronization assumptions? Here is an example: //Returns an iterator for this table.It is the client's //responsibility to delete the iterator when it is done with it, //and it must not use the iterator once the GargantuanTable object //on which the iterator was created has been deleted. // //The iterator is initially positioned at the beginning of the table. // //This method is equivalent to: //Iterator*iter=table->NewIterator(); //iter->Seek(""); //return iter; //If you are going to immediately seek to another place in the //returned iterator,it will be faster to use NewIterator() //and avoid the extra seek. Iterator*GetIterator()const; However,do not be unnecessarily verbose or state the completely obvious.Notice below that it is not necessary to say"returns false otherwise"because this is implied. //Returns true if the table cannot hold any more entries. bool IsTableFull(); When commenting constructors and destructors,remember that the person reading your code knows what constructors and destructors are for,so comments that just say something like"destroys this object"are not useful.Document what constructors do with their arguments(for example,if they take ownership of pointers),and what cleanup the destructor does.If this is trivial,just skip the comment.It is quite common for destructors not to have a header comment. Function Definitions Each function definition should have a comment describing what the function does if there's anything tricky about how it does its job.For example,in the definition comment you might describe any coding tricks you use,give an overview of the steps you go through,or explain why you chose to implement the function in the way you did rather than using a viable alternative.For instance,you might mention why it must acquire a lock for the first half of the function but why it is not needed for the second half. Note you should not just repeat the comments given with the function declaration,in the.h file or wherever.It's okay to recapitulate briefly what the function does,but the focus of the comments should be on how it does it. Variable Comments link▽In general the actual name of the variable should be descriptive enough to give a good idea of what the variable is used for.In certain cases,more comments are required. Class Data Members Each class data member(also called an instance variable or member variable)should have a comment describing what it is used for.If the variable can take sentinel values with special meanings,such as NULL or-1,document this.For example: private: //Keeps track of the total number of entries in the table. //Used to ensure we do not go over the limit.-1 means //that we don't yet know how many entries the table has. int num_total_entries_; Global Variables As with data members,all global variables should have a comment describing what they are and what they are used for.For example: //The total number of tests cases that we run through in this regression test. const int kNumTestCases=6; Implementation Comments link▽In your implementation you should have comments in tricky,non-obvious,interesting,or important parts of your code. Class Data Members Tricky or complicated code blocks should have comments before them.Example: //Divide result by two,taking into account that x //contains the carry from the add. for(int i=0;i x=(x<<8)+(*result)[i]; (*result)[i]=x>>1; x&=1; } Line Comments Also,lines that are non-obvious should get a comment at the end of the line.These end-of-line comments should be separated from the code by 2 spaces.Example: //If we have enough memory,mmap the data portion too. mmap_budget=max if(mmap_budget>=data_size_&&!MmapData(mmap_chunk_bytes,mlock)) return;//Error already logged. Note that there are both comments that describe what the code is doing,and comments that mention that an error has already been logged when the function returns. If you have several comments on subsequent lines,it can often be more readable to line them up: DoSomething();//Comment here so the comments line up. DoSomethingElseThatIsLonger();//Comment here so there are two spaces between //the code and the comment. {//One space before comment when opening a new scope is allowed, //thus the comment lines up with the following comments and code. DoSomethingElse();//Two spaces before line comments normally. } NULL,true/false,1,2,3... When you pass in NULL,boolean,or literal integer values to functions,you should consider adding a comment about what they are,or make your code self-documenting by using constants.For example,compare: bool success=CalculateSomething(interesting_value, 10, false, NULL);//What are these arguments?? versus: bool success=CalculateSomething(interesting_value, 10,//Default base value. false,//Not the first time we're calling this. NULL);//No callback. Or alternatively,constants or self-describing variables: const int kDefaultBaseValue=10; const bool kFirstTimeCalling=false; Callback*null_callback=NULL; bool success=CalculateSomething(interesting_value, kDefaultBaseValue, kFirstTimeCalling, null_callback); Don'ts Note that you should never describe the code itself.Assume that the person reading the code knows C++better than you do,even though he or she does not know what you are trying to do: //Now go through the b array and make sure that if i occurs, //the next element is i+1. ...//Geez.What a useless comment. Punctuation,Spelling and Grammar link▽Pay attention to punctuation,spelling,and grammar;it is easier to read well-written comments than badly written ones. Comments should usually be written as complete sentences with proper capitalization and periods at the end.Shorter comments,such as comments at the end of a line of code,can sometimes be less formal,but you should be consistent with your https://www.sodocs.net/doc/aa10598413.html,plete sentences are more readable,and they provide some assurance that the comment is complete and not an unfinished thought. Although it can be frustrating to have a code reviewer point out that you are using a comma when you should be using a semicolon,it is very important that source code maintain a high level of clarity and readability.Proper punctuation,spelling,and grammar help with that goal. TODO Comments link▽Use TODO comments for code that is temporary,a short-term solution,or good-enough but not perfect. TODO s should include the string TODO in all caps,followed by the name,e-mail address,or other identifier of the person who can best provide context about the problem referenced by the TODO.A colon is optional.The main purpose is to have a consistent TODO format that can be searched to find the person who can provide more details upon request.A TODO is not a commitment that the person referenced will fix the problem.Thus when you create a TODO,it is almost always your name that is given. //TODO(kl@https://www.sodocs.net/doc/aa10598413.html,):Use a"*"here for concatenation operator. //TODO(Zeke)change this to use relations. If your TODO is of the form"At a future date do something"make sure that you either include a very specific date("Fix by November 2005")or a very specific event("Remove this code when all clients can handle XML responses."). Deprecation Comments link▽Mark deprecated interface points with DEPRECATED comments. You can mark an interface as deprecated by writing a comment containing the word DEPRECATED in all caps.The comment goes either before the declaration of the interface or on the same line as the declaration. After the word DEPRECATED,write your name,e-mail address,or other identifier in parentheses. A deprecation comment must include simple,clear directions for people to fix their callsites.In C++,you can implement a deprecated function as an inline function that calls the new interface point. Marking an interface point DEPRECATED will not magically cause any callsites to change.If you want people to actually stop using the deprecated facility,you will have to fix the callsites yourself or recruit a crew to help you. New code should not contain calls to deprecated interface https://www.sodocs.net/doc/aa10598413.html,e the new interface point instead.If you cannot understand the directions,find the person who created the deprecation and ask them for help using the new interface point. Formatting Coding style and formatting are pretty arbitrary,but a project is much easier to follow if everyone uses the same style.Individuals may not agree with every aspect of the formatting rules,and some of the rules may take some getting used to,but it is important that all project contributors follow the style rules so that they can all read and understand everyone's code easily. To help you format code correctly,we've created a settings file for emacs. Line Length link▽Each line of text in your code should be at most 80 characters long. We recognize that this rule is controversial,but so much existing code already adheres to it,and we feel that consistency is important. Pros:Those who favor this rule argue that it is rude to force them to resize their windows and there is no need for anything longer.Some folks are used to having several code windows side-by-side,and thus don't have room to widen their windows in any case.People set up their work environment assuming a particular maximum window width,and 80 columns has been the traditional standard.Why change it? Cons:Proponents of change argue that a wider line can make code more readable.The 80-column limit is an hidebound throwback to 1960s mainframes;modern equipment has wide screens that can easily show longer lines. Decision: 80 characters is the maximum. Exception:if a comment line contains an example command or a literal URL longer than 80 characters,that line may be longer than 80 characters for ease of cut and paste. Exception:an#include statement with a long path may exceed 80 columns.Try to avoid situations where this becomes necessary. Exception:you needn't be concerned about header guards that exceed the maximum length. Non-ASCII Characters link▽Non-ASCII characters should be rare,and must use UTF-8 formatting. You shouldn't hard-code user-facing text in source,even English,so use of non-ASCII characters should be rare.However,in certain cases it is appropriate to include such words in your code.For example,if your code parses data files from foreign sources,it may be appropriate to hard-code the non-ASCII string(s)used in those data files as delimiters.More commonly,unittest code(which does not need to be localized)might contain non-ASCII strings.In such cases,you should use UTF-8,since that is an encoding understood by most tools able to handle more than just ASCII.Hex encoding is also OK,and encouraged where it enhances readability—for example,"\xEF\xBB\xBF"is the Unicode zero-width no-break space character,which would be invisible if included in the source as straight UTF-8. Spaces vs.Tabs link▽Use only spaces,and indent 2 spaces at a time. We use spaces for indentation.Do not use tabs in your code.You should set your editor to emit spaces when you hit the tab key. Function Declarations and Definitions link▽Return type on the same line as function name,parameters on the same line if they fit. Functions look like this: ReturnType ClassName::FunctionName(Type par_name1,Type par_name2){ DoSomething(); ... } If you have too much text to fit on one line: ReturnType ClassName::ReallyLongFunctionName(Type par_name1,Type par_name2, Type par_name3){ DoSomething(); ... } or if you cannot fit even the first parameter: ReturnType LongClassName::ReallyReallyReallyLongFunctionName( Type par_name1,//4 space indent Type par_name2, Type par_name3){ DoSomething();//2 space indent ... } Some points to note: ?The return type is always on the same line as the function name. ?The open parenthesis is always on the same line as the function name. ?There is never a space between the function name and the open parenthesis. ?There is never a space between the parentheses and the parameters. ?The open curly brace is always at the end of the same line as the last parameter. ?The close curly brace is either on the last line by itself or(if other style rules permit)on the same line as the open curly brace. ?There should be a space between the close parenthesis and the open curly brace. ?All parameters should be named,with identical names in the declaration and implementation. ?All parameters should be aligned if possible. ?Default indentation is 2 spaces. ?Wrapped parameters have a 4 space indent. If your function is const,the const keyword should be on the same line as the last parameter: //Everything in this function signature fits on a single line ReturnType FunctionName(Type par)const{ ... } //This function signature requires multiple lines,but //the const keyword is on the line with the last parameter. ReturnType ReallyLongFunctionName(Type par1, Type par2)const{ ... } If some parameters are unused,comment out the variable name in the function definition: //Always have named parameters in interfaces. class Shape{ public: virtual void Rotate(double radians)=0; } //Always have named parameters in the declaration. class Circle:public Shape{ public: virtual void Rotate(double radians); } //Comment out unused named parameters in definitions. void Circle::Rotate(double/*radians*/){} //Bad-if someone wants to implement later,it's not clear what the //variable means. void Circle::Rotate(double){} Function Calls link▽On one line if it fits;otherwise,wrap arguments at the parenthesis. Function calls have the following format: bool retval=DoSomething(argument1,argument2,argument3); If the arguments do not all fit on one line,they should be broken up onto multiple lines,with each subsequent line aligned with the first argument.Do not add spaces after the open paren or before the close paren: bool retval=DoSomething(averyveryveryverylongargument1, argument2,argument3); If the function has many arguments,consider having one per line if this makes the code more readable: bool retval=DoSomething(argument1, argument2, argument3, argument4); If the function signature is so long that it cannot fit within the maximum line length,you may place all arguments on subsequent lines: if(...){ ... ... if(...){ DoSomethingThatRequiresALongFunctionName( very_long_argument1,//4 space indent argument2, argument3, argument4); } Conditionals link▽Prefer no spaces inside parentheses.The else keyword belongs on a new line. There are two acceptable formats for a basic conditional statement.One includes spaces between the parentheses and the condition,and one does not. The most common form is without spaces.Either is fine,but be consistent.If you are modifying a file,use the format that is already present.If you are writing new code,use the format that the other files in that directory or project use.If in doubt and you have no personal preference,do not add the spaces. if(condition){//no spaces inside parentheses ...//2 space indent. }else{//The else goes on the same line as the closing brace. ... } If you prefer you may add spaces inside the parentheses: if(condition){//spaces inside parentheses-rare ...//2 space indent. }else{//The else goes on the same line as the closing brace. ... } Note that in all cases you must have a space between the if and the open parenthesis.You must also have a space between the close parenthesis and the curly brace,if you're using one. if(condition)//Bad-space missing after IF. if(condition){//Bad-space missing before{. if(condition){//Doubly bad. if(condition){//Good-proper space after IF and before{. Short conditional statements may be written on one line if this enhances readability.You may use this only when the line is brief and the statement does not use the else clause. if(x==kFoo)return new Foo(); if(x==kBar)return new Bar(); This is not allowed when the if statement has an else: //Not allowed-IF statement on one line when there is an ELSE clause if(x)DoThis(); else DoThat(); In general,curly braces are not required for single-line statements,but they are allowed if you like them;conditional or loop statements with complex conditions or statements may be more readable with curly braces.Some projects require that an if must always always have an accompanying brace. if(condition) DoSomething();//2 space indent. if(condition){ DoSomething();//2 space indent. } However,if one part of an if-else statement uses curly braces,the other part must too: //Not allowed-curly on IF but not ELSE if(condition){ foo; }else bar; //Not allowed-curly on ELSE but not IF if(condition) foo; else{ bar; } //Curly braces around both IF and ELSE required because //one of the clauses used braces. if(condition){ foo; }else{ bar; } Loops and Switch Statements link▽Switch statements may use braces for blocks.Empty loop bodies should use{}or continue. case blocks in switch statements can have curly braces or not,depending on your preference.If you do include curly braces they should be placed as shown below. If not conditional on an enumerated value,switch statements should always have a default case(in the case of an enumerated value,the compiler will warn you if any values are not handled).If the default case should never execute,simply assert: switch(var){ case 0:{//2 space indent ...//4 space indent break; } case 1:{ ... break; } default:{ assert(false); } } Empty loop bodies should use{}or continue,but not a single semicolon. while(condition){ //Repeat test until it returns false. } for(int i=0;i while(condition)continue;//Good-continue indicates no logic. while(condition);//Bad-looks like part of do/while loop. Pointer and Reference Expressions link▽No spaces around period or arrow.Pointer operators do not have trailing spaces. The following are examples of correctly-formatted pointer and reference expressions: x=*p; p=&x; x=r.y; x=r->y; Note that: ?There are no spaces around the period or arrow when accessing a member. ?Pointer operators have no space after the*or&. When declaring a pointer variable or argument,you may place the asterisk adjacent to either the type or to the variable name: //These are fine,space preceding. char*c; const string&str; //These are fine,space following. char*c;//but remember to do"char*c,*d,*e,...;"! const string&str; char*c;//Bad-spaces on both sides of* const string&str;//Bad-spaces on both sides of& You should do this consistently within a single file,so,when modifying an existing file,use the style in that file. Boolean Expressions link▽When you have a boolean expression that is longer than the standard line length,be consistent in how you break up the lines. In this example,the logical AND operator is always at the end of the lines: if(this_one_thing>this_other_thing&& a_third_thing==a_fourth_thing&& yet_another&&last_one){ ... } Note that when the code wraps in this example,both of the&&logical AND operators are at the end of the line.This is more common in Google code,though wrapping all operators at the beginning of the line is also allowed.Feel free to insert extra parentheses judiciously,because they can be very helpful in increasing readability when used appropriately.Also note that you should always use the punctuation operators,such as&&and~,rather than the word operators,such as and and compl. Return Values link▽Do not needlessly surround the return expression with parentheses. Use parentheses in return expr;only where you would use them in x=expr;. return result;//No parentheses in the simple case. return(some_long_condition&&//Parentheses ok to make a complex another_condition);//expression more readable. return(value);//You wouldn't write var=(value); return(result);//return is not a function! Variable and Array Initialization link▽Your choice of=or(). You may choose between=and();the following are all correct: int x=3; int x(3); string name("Some Name"); string name="Some Name"; Preprocessor Directives link▽The hash mark that starts a preprocessor directive should always be at the beginning of the line. Even when preprocessor directives are within the body of indented code,the directives should start at the beginning of the line. //Good-directives at beginning of line if(lopsided_score){ #if DISASTER_PENDING//Correct--Starts at beginning of line DropEverything(); #if NOTIFY//OK but not required--Spaces after# NotifyClient(); #endif #endif BackToNormal(); } //Bad-indented directives if(lopsided_score){ #if DISASTER_PENDING//Wrong!The"#if"should be at beginning of line DropEverything(); #endif//Wrong!Do not indent"#endif" BackToNormal(); } Class Format link▽Sections in public,protected and private order,each indented one space. The basic format for a class declaration(lacking the comments,see Class Comments for a discussion of what comments are needed)is: class MyClass:public OtherClass{ public://Note the 1 space indent! MyClass();//Regular 2 space indent. explicit MyClass(int var); ~MyClass(){} void SomeFunction(); void SomeFunctionThatDoesNothing(){ } void set_some_var(int var){some_var_=var;} int some_var()const{return some_var_;} private: bool SomeInternalFunction(); int some_var_; int some_other_var_; DISALLOW_COPY_AND_ASSIGN(MyClass); }; Things to note: ?Any base class name should be on the same line as the subclass name,subject to the 80-column limit. ?The public:,protected:,and private:keywords should be indented one space. ?Except for the first instance,these keywords should be preceded by a blank line.This rule is optional in small classes. ?Do not leave a blank line after these keywords. ?The public section should be first,followed by the protected and finally the private section. ?See Declaration Order for rules on ordering declarations within each of these sections. Constructor Initializer Lists link▽Constructor initializer lists can be all on one line or with subsequent lines indented four spaces. There are two acceptable formats for initializer lists: //When it all fits on one line: MyClass::MyClass(int var):some_var_(var),some_other_var_(var+1){} or //When it requires multiple lines,indent 4 spaces,putting the colon on //the first initializer line: MyClass::MyClass(int var) :some_var_(var),//4 space indent some_other_var_(var+1){//lined up ... DoSomething(); ... } Namespace Formatting link▽The contents of namespaces are not indented. Namespaces do not add an extra level of indentation.For example,use: namespace{ void foo(){//Correct.No extra indentation within namespace. ... } }//namespace Do not indent within a namespace: namespace{ //Wrong.Indented when it should not be. void foo(){ ... } }//namespace When declaring nested namespaces,put each namespace on its own line. namespace foo{ namespace bar{ Horizontal Whitespace link▽Use of horizontal whitespace depends on location.Never put trailing whitespace at the end of a line. General void f(bool b){//Open braces should always have a space before them. ... int i=0;//Semicolons usually have no space before them. int x[]={0};//Spaces inside braces for array initialization are int x[]={0};//optional.If you use them,put them on both sides! //Spaces around the colon in inheritance and initializer lists. class Foo:public Bar{ public: //For inline function implementations,put spaces between the braces //and the implementation itself. Foo(int b):Bar(),baz_(b){}//No spaces inside empty braces. void Reset(){baz_=0;}//Spaces separating braces from implementation. ... Adding trailing whitespace can cause extra work for others editing the same file,when they merge,as can removing existing trailing whitespace.So:Don't introduce trailing whitespace.Remove it if you're already changing that line,or do it in a separate clean-up operation(preferably when no-one else is working on the file). Loops and Conditionals if(b){//Space after the keyword in conditions and loops. }else{//Spaces around else. } while(test){}//There is usually no space inside parentheses. switch(i){ for(int i=0;i<5;++i){ switch(i){//Loops and conditions may have spaces inside if(test){//parentheses,but this is rare.Be consistent. for(int i=0;i<5;++i){ for(;i<5;++i){//For loops always have a space after the ...//semicolon,and may have a space before the //semicolon. switch(i){ case 1://No space before colon in a switch case. ... case 2:break;//Use a space after a colon if there's code after it. Operators x=0;//Assignment operators always have spaces around //them. x=-5;//No spaces separating unary operators and their ++x;//arguments. if(x&&!y) ... v=w*x+y/z;//Binary operators usually have spaces around them, v=w*x+y/z;//but it's okay to remove spaces around factors. v=w*(x+z);//Parentheses should have no spaces inside them. Templates and Casts vector y=static_cast //<,or between>(in a cast. vector //okay,but be consistent. set set //symmetric spacing in<<. Vertical Whitespace link▽Minimize use of vertical whitespace. This is more a principle than a rule:don't use blank lines when you don't have to.In particular,don't put more than one or two blank lines between functions,resist starting functions with a blank line,don't end functions with a blank line,and be discriminating with your use of blank lines inside functions. The basic principle is:The more code that fits on one screen,the easier it is to follow and understand the control flow of the program.Of course,readability can suffer from code being too dense as well as too spread out,so use your judgement.But in general,minimize use of vertical whitespace. Some rules of thumb to help when blank lines may be useful: ?Blank lines at the beginning or end of a function very rarely help readability. ?Blank lines inside a chain of if-else blocks may well help readability. Exceptions to the Rules The coding conventions described above are mandatory.However,like all good rules,these sometimes have exceptions,which we discuss here. Existing Non-conformant Code link▽You may diverge from the rules when dealing with code that does not conform to this style guide. If you find yourself modifying code that was written to specifications other than those presented by this guide,you may have to diverge from these rules in order to stay consistent with the local conventions in that code.If you are in doubt about how to do this,ask the original author or the person currently responsible for the code.Remember that consistency includes local consistency,too. Windows Code link▽Windows programmers have developed their own set of coding conventions,mainly derived from the conventions in Windows headers and other Microsoft code.We want to make it easy for anyone to understand your code,so we have a single set of guidelines for everyone writing C++on any platform. It is worth reiterating a few of the guidelines that you might forget if you are used to the prevalent Windows style: ?Do not use Hungarian notation(for example,naming an integer iNum).Use the Google naming conventions,including https://www.sodocs.net/doc/aa10598413.html, extension for source files. ?Windows defines many of its own synonyms for primitive types,such as DWORD,HANDLE,etc.It is perfectly acceptable,and encouraged,that you use these types when calling Windows API functions.Even so,keep as close as you can to the underlying C++types.For example,use const TCHAR*instead of LPCTSTR. ?When compiling with Microsoft Visual C++,set the compiler to warning level 3 or higher,and treat all warnings as errors. ?Do not use#pragma once;instead use the standard Google include guards.The path in the include guards should be relative to the top of your project tree. ?In fact,do not use any nonstandard extensions,like#pragma and__declspec,unless you absolutely https://www.sodocs.net/doc/aa10598413.html,ing__declspec(dllimport)and__declspec(dllexport)is allowed;however,you must use them through macros such as DLLIMPORT and DLLEXPORT,so that someone can easily disable the extensions if they share the code. However,there are just a few rules that we occasionally need to break on Windows: ?Normally we forbid the use of multiple implementation inheritance;however,it is required when using COM and some ATL/WTL classes.You may use multiple implementation inheritance to implement COM or ATL/WTL classes and interfaces. ?Although you should not use exceptions in your own code,they are used extensively in the ATL and some STLs,including the one that comes with Visual C++.When using the ATL,you should define_ATL_NO_EXCEPTIONS to disable exceptions.You should investigate whether you can also disable exceptions in your STL,but if not,it is OK to turn on exceptions in the compiler.(Note that this is only to get the STL to compile.You should still not write exception handling code yourself.) ?The usual way of working with precompiled headers is to include a header file at the top of each source file,typically with a name like StdAfx.h or precompile.h.To make your code easier to share with other projects,avoid including this file explicitly(except in https://www.sodocs.net/doc/aa10598413.html,),and use the/FI compiler option to include the file automatically. ?Resource headers,which are usually named resource.h and contain only macros,do not need to conform to these style guidelines. Parting Words Use common sense and BE CONSISTENT. If you are editing code,take a few minutes to look at the code around you and determine its style.If they use spaces around their if clauses,you should,too.If their comments have little boxes of stars around them,make your comments have little boxes of stars around them too. The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you are saying,rather than on how you are saying it.We present global style rules here so people know the vocabulary.But local style is also important.If code you add to a file looks drastically different from the existing code around it,the discontinuity throws readers out of their rhythm when they go to read it.Try to avoid this. OK,enough writing about writing code;the code itself is much more interesting.Have fun! Revision 3.188 Benjy WeinbergerCraig SilversteinGregory EitzmannMark MentovaiTashana Landray 晒晒知名公司的福利清单 谷歌的超级福利令很多人艳羡，也经常出台惊人之举：谷歌员工如果在职期间死亡，其配偶或伴侣将在未来十年，获得该员工薪水的50％。这项“遗属福利”对所有员工一视同仁。除此之外，配偶还可以获得该员工在公司里的股份。如果他们有孩子，孩子将每月获得1000美元，直至19岁。 有人把公司分成四个时代，大家不必对号入座。奴隶时代—女人当男人用，男人当骡子用；封建时代—老板就是皇上，独裁、暴政；工业时代—严格打卡，迟到扣钱，死命加班；信息化时代—弹性工作时间，个性化办公，最重要的是，满足生活所需的人性化福利。 福利是提升企业品牌和口碑的绝佳武器，是锁住员工的温柔锁链，是公司与员工情感沟通的重要手段，更是HR提升员工满意度的幸福课题。对公司来说，一项人性化的福利，往往让员工感受到公司的贴心关爱，其精神支持远远大于物质付出。 2012年光棍节，成都某公司颁布了两项新福利：恋爱奖金和失恋假期。员工入职半年后即可享受，每人最多两次机会。恋爱成功的单身男女，可获得1112元恋爱奖金（由1111+1得来，双数意味“脱单”）。鼓励员工吃“窝边草”，除奖金外，内部会再开party以示庆祝；鼓励员工“挖墙脚”，凡与其他IT公司员工谈恋爱的，可再获得“潜力墙角奖金”（随机抽500-1000元）。失恋假期：考虑到失恋的员工精神状况不佳，影响工作效率，在员工失恋的一个月内可提出带薪休假两天。这种福利设置大胆、新颖。 但在大多数公司，福利还是司空见惯的做法，有些只有“五险一金”，有些逢年过节发些米面油或购物卡。那些真正以员工满意甚至惊喜为目的，包含公司心意和创意的独特福利项目很少，有也往往出自标杆企业，一经推出，迅速被人关注，为员工推崇，更为其他企业吸收和借鉴，也激发更多企业设计和推出更多特别的福利项目。 2012年湖南卫视《百变大咖秀》非常火爆，我们也借时下很热的新词“大咖”（台湾闽南语里“大咖”本意为大角色），盘点一下福利那点事儿，网罗令人艳羡的福利里的大咖。其中，特色福利中的新意指数，意味着不落俗套，以新的方式或模式，基于员工受益角度设计福利。满意指数意味着讲求实效，真正能让员工从工作体验和实际收益方面得以提高。 特色福利大盘点 福利名称：员工免息住房贷款 标杆企业：腾讯、阿里巴巴、人人网 福利档案： 2011年6月，腾讯投资10亿启动安居计划，为已满3年的基层员工，在北上广深等一线城市，提供免息贷款20～30万，每年还款一次，无需任何担保，最快2天、最晚5天即可得到贷款。截止2012年12月底，已有815位腾讯员工享受到该福利。 航空公司代码 Document number：NOCG-YUNOO-BUYTT-UU986-1986UT 1.国际航空公司代码： 2.国内各航空公司两字代码： 公司标志两字代码三字代码中文名英文名 CA999中国国际航空公司AirChina MU781中国东方航空公司ChinaEasternAirlines CZ784中国南方航空（集团）公司ChinaSouthernAirlines SZ785中国西南航空公司ChinaSouthwestAirlines WH783中国西北航空公司ChinaNorthwestAirlines CJ782中国北方航空公司ChinaNorthernAirlines F6中国航空股份有限公司ChinaNationalAviationCorporation XO651新疆航空公司XinjiangAirlines 3Q592云南航空公司YunnanAirlines MF731厦门航空有限公司XiamenAirlinesLtd. 3UC10四川省航空公司SichuanAirlines FM774上海航空公司ShanghaiAirlines G8长城航空公司GreatwallAirlines WUC12武汉航空公司WuhanAirlines Z2中原航空公司ZhongyuanAirlines G4贵州省航空公司GuizhouAirlines H4880海南省航空公司HainanAirlines X2779中国新华航空公司ChinaXinhuaAirlines 4GC09深圳航空公司ShenzhenAirlines 2Z长安航空公司Chang`anAirlines IV791福建航空公司FujianAirlines SCC07山东航空公司ShandongAirlines 8C山西航空公司ShanxiAirlines 3.《国内通航城市三字代码》 谷歌员工福利 Google（Google Inc.，NASDAQ：GOOG）是一家美国上市公司（公有股份公司），于1998年9月7日以私有股份公司的形式创立，以设计并管理一个互联网搜索引擎。Google 目前被公认为是全球规模最大的搜索引擎，它提供了简单易用的免费服务。2012年5月，谷歌以125亿美元收购摩托罗拉移动。2012年9月7日，谷歌称已经收购了网络安全创业公司VirusTotal。 在2011年最佳雇主榜单中，谷歌高居榜首。谷歌制订了高标准的员工福利政策，包括免费美食，现场洗衣、干洗、以及改衣服务，户外运动中心，邀请各路名人到访演讲。待遇之丰厚，鲜有公司能与之匹敌。下面，我们介绍谷歌最新推出的几项福利。正是这些措施帮助谷歌成功入选了《财富》杂志（Fortune）评选出的最适宜工作的公司排行榜。 综合户外运动中心不惜血本 为了让员工保持健康体魄，谷歌从来不惜花费重金。公司开设了一座大型的户外体育中心。加菲尔德运动中心以其所在街道的名字命名，内设一个足球场、一个篮球场、两个网球场、两个室外地滚球场、两个用于掷马蹄游戏的马蹄坑、一个高尔夫球场、以及一个曲棍球场。 室内娱乐设施丰富多彩 如果雇员们不想在室外玩滚球的话，还可以回到谷歌总部的室内玩保龄球，一共4个保龄球道，可以让大家进行比赛。而在谷歌的舞蹈室里，雇员可以选择31种不同的舞蹈课程，从非洲的民族舞到实用的宴会舞。而上课的除了外聘的专业舞蹈老师，还有谷歌自己的志愿者们。 工作方式坐立自由 久坐不利于健康。美国癌症学会（American Cancer Society）指出，每天坐着的时间超过6个小时的妇女英年早逝的几率比每天坐着的时间不足3小时的妇女高出37%（男性的相应的数字是18%）。也许这就是为何一些谷歌员工宁愿站着工作的原因所在。去年开始，用立式办公桌代替标准的坐式办公桌在谷歌蔚然成风。谷歌员工只需使用公司的Ergolab软件下单，从众多的办公桌类型中任意选择一款，然后就能收到一台与其身高相配的办公桌。据非官方数字统计，目前谷歌已有数百人在使用立式办公桌。 安卓新品免费派发 效力于拥有全球最大移动操作系统的公司有一个优厚的条件，那就是可以免费使用高科技产品。谷歌有向员工派发安卓智能手机的传统，去年12月也不例外。据报道，去年12月，该公司向大量（如果不是全部的话）员工免费发放了三星Galaxy Nexus手机，作为假期礼物。这些手机零售价通常为299美元，其中含有为期2年的Verizon合约。而且，每部手机的背板都是定制的，嵌有谷歌服务部门的图标。 谷歌人力资源管理分析 前言 人力资源是指一定时期内组织中的人所拥有的能够被企业所用，且对价值创造起贡献作用的教育、能力、技能、经验、体力等的总称。狭义讲就是企事业单位独立的经营团体所需人员具备的能力。 人力资源管理是企业发展动力的源泉；是企业可持续发展的根本保障。人力资源管理涉及了管理学、法学、经济学、心理学、社会学等多个学科，是一个复杂的管理工作。 人力资源管理重要性的突显是市场竞争加剧的结果。随着社会主义市场经济的快速发展，人力资源管理在企业管理中的作用也变得日益重要。一个企业能否健康发展，在很大程度上取决于员工素质的高低与否，取决于人力资源管理在企业管理中的受重视程度。 基本情况概述 谷歌，是一家美国的跨国科技企业，致力于互联网搜索、云计算、广告技术等领域，开发并提供大量基于互联网的产品与服务，其主要利润来自于AdWords 等广告服务。Google由当时在斯坦福大学攻读理工博士的拉里·佩奇和谢尔盖·布卢姆共同创建。 Google的成功的很大程度上来源于其独特的人力资源管理，用CEO埃里克·施密特的话说，就是“份额第一，收入第二”。Google公司之所以在自己的领域成功在很大的程度上来自于企业成功的战略计划、不断增加更新的核心能力、高效的企业绩效与薪酬管理、严格的人力资源培训、广泛的人力资源外包，这些都离不开Google杰出的人力资源管理。 Google公司的核心能力来源于五个方面：一是建立了适合企业特点的公司治理结构和企业理念，二是高效的管理团队，三是独特的企业价值观，四是建立了一套成功的商业模式，五是能够拥有自己的核心技术。 谷歌人力资源分析 招聘 GOOGLE的招聘部门，其内部包括招聘研究与分析、职位候选人发开、招聘流程协调、职位候选人甄选、大学毕业生招聘、技术管理与领导招聘、国际招聘、招聘项目管理等专业分工明确的岗位。GOOGLE的庞大招聘机器每月要处理四五万份简历，从中选拔真正优秀人才。 1.招聘人员筛选 Google招聘流程的第一步是从技术性要求、教育程度以及工作经验来筛选应聘者。如果你的简历不合适，你会得到一个礼貌的“您暂时不合适”回应，但是你的简历会被存档。而且Google的招聘人员会在一个新的职位开放招聘之后检查现有的存档简历，如果他们认为你合适，招聘人员会联系你并进行一个电话筛选面试。 2.电话筛选 一位Google的招聘人员会联系你，解释这个流程，并让你知道预期状况。如果这是一个技术性的工程师职位，招聘人员可能会询问你的大学入学成绩和在大学的GPA。 3.现场面试 第一次的面试会安排4-5个求职者，每人面45分钟。面试官包括经理以及相似职位的工作人员。这次面试会深入了解你的技术能力和特定领域知识。如果你应聘的是一个技术职位，你会被要求当场解决一些技术问题，包括写出一个解决方案的代码或者在白板上写出你的设计。这些问题对于那些没有准备好的求职者是相当困难的，但是如果你真的喜欢这种工作，它们会带来无比的乐趣和激励。 4.面试反馈 每个面试官都会在一个标准表格中填写他们的反馈，并给应聘者打分。招聘人员会处理这些反馈，并把它和其他应聘相同或类似职位的应聘者比较。如果这个应聘者在反馈中被一致认为是合适的人选，接下来就轮到Google的招聘委员会了。 英文国家中文国家二字代码AFGHANISTAN阿富汗AF ALANDISLANDS奥兰群岛AX ALBANIA阿尔巴尼亚AL ALGERIA阿尔及利亚DZ AMERICANSAMOA美国萨摩亚AS ANDORRA安道尔AD ANGOLA安哥拉AO ANGUILLA安圭拉岛AI ANTARCTICA南极AQ ANTIGUAANDBARBUDA安提瓜和巴布达AG ARGENTINA阿根廷AR ARMENIA亚美尼亚AM AUSTRALIA澳大利亚AU AUSTRIA奥地利AT AZERBAIJAN阿塞拜疆AZ BAHRAIN巴林BH BANGLADESH孟加拉国BD BARBADOS巴巴多斯BB BELARUS白俄罗斯BY BELGIUM比利时BE BELIZE伯利兹BZ BENIN贝宁湾BJ BERMUDA百慕大BM BHUTAN不丹BT BOLIVIA,PLURINATIONALSTATEOF玻利维亚BO Bosnia&Herzegovina波斯尼亚黑塞哥BA BOTSWANA博茨瓦纳BW BOUVETISLAND布韦岛BV BRAZIL巴西BR BRITISHINDIANOCEANTERRITORY英属印度洋领地IO BRUNEIDARUSSALAM文莱达鲁萨兰国BN BULGARIA保加利亚BG BURKINAFASO布基纳法索BF BURUNDI布隆迪BI CAMBODIA柬埔寨KH CANADA加拿大CA CAPEVERDE佛得角CV CAYMANISLANDS开曼群岛KY CENTRALAFRICANREPUBLIC中非共和国CF CHAD乍得TD CHILE智利CL CHINA中国CN COCOS(KEELING)ISLANDS科科斯群岛CC COLOMBIA哥伦比亚CO COMOROS科摩罗KM CONGO刚果CG CONGO,THEDEMOCRATICREPUBLICOFTHE刚果民主共和国CD COOKISLANDS库克群岛CK COSTARICA哥斯达黎加CR COTED'IVOIRE科特迪瓦CI G o o g l e 第一.福利 1月27日，在《财富》杂志日前评选的2008年度“美国100家最佳雇主”中，Google 继去年之后再度封王。为此，《财富》杂志记者亲自前往Google总部，揭开了Google 不为人所知的九个秘密。 第一：自行车取代滑板车 Google位于加州山景城的总部曾为员工准备两轮Segways电动车及滑板车作为代步工具。但是，由于segway经常容易损坏，而滑板车又容易使员工摔跤，自行车目前已成为Google在公司内部最主要的交通工具。 第二：包场看电影 如何使超过6000名公司员工观看电影的首映式？当然是把整个电影院全天都包下来。作为额外福利，每个人还能带上一位客人。 第三：宝宝也有福利 Google员工的子女现在就在Google上班可能年龄还太小了，不过这并不意味着Google就不关心员工子女的健康。事实上，Google刚出台了一项新政策，允许年轻的 妈妈们每年带薪休假18周，专门回家照顾孩子。当然，爸爸们也可以休假，不过时间要短一些，只有7周。 第四：Google 自己的“ Facebook” Google的内部网Moma提供了各种丰富的信息，除了企业介绍、福利、内部信、员工手册这些常规内容。不过Moms最经常被用来查找其他的Google员工。为什么呢？因为MomO!供了公司15916名员工的照片。 第五：Google的空气 太阳能电池、可回收的地毯和环保交通工具只是Google环保行动的一小部分，最近，Google在山景城的总部安装了一种特制的、对环境无害的空气过滤系统，可以清除空气中的有毒物质和杂质。如果你是Google员工，在办公室里待个通宵编写代码，至少不用担心呼吸不到新鲜的空气了。 第六：Google的恶作剧 不要相信在Google上看到了任何多西。每年愚人节跟用户和求职员工搞个恶作剧是Google的传统。例如，Google曾在愚人节发布招聘工程师广告，条件是能在月球上工作。Google还曾号称推出了一种有益大脑的保健饮料“ Google Gulp”。不过这种传统有时候也会自食其果，例如,Google在2004年4月1日曾发布了容量1GB的Gmail， 国家名称及缩写 Af -------Afghanistan 阿富汗 AL -------Albania 阿尔巴尼亚 DZ -------Algeria 阿尔及利亚 AS -------American Samoa 东萨摩亚 AD -------Andorra 安道尔 AO -------Angola 安哥拉 Av -------Anguilla 安圭拉岛 AQ -------Antarctica 南极洲 AG -------Antigua and Barbuda 安提瓜和巴布达 AR -------Argentina 阿根廷 AM -------Armenia 亚美尼亚 AA -------Aruba 阿鲁巴 AU -------Australia 澳大利亚 AT -------Austria 奥地利 AZ -------Azerbaijan 阿塞拜疆 BH -------Bahrain 巴林 BB -------Barbados 巴巴多斯 BD -------Bangladesh 孟加拉 BY -------Belarus 白俄罗斯 BE -------Belgium 比利时 BZ -------Belize 伯里兹 BJ -------Benin 贝宁 BM -------Bermuda 百慕大 BS -------Bahamas 巴哈马 BF -------Bahamas 巴哈马 BT -------Bhutan 不丹 BW -------Botswana 博茨瓦纳 BO -------Bolivia 玻利维亚 BA -------Bosnia and Herzegovina 波黑 BV -------Bouvet Island 布韦岛 BR -------Brazil 巴西 IO -------British Indian Ocean Territory 英属印度洋领地BN -------Brunei Darussalam 文莱布鲁萨兰 BG -------Bulgaria 保加利亚 BF -------Burkina Faso 布基纳法索 BI -------Burundi 布隆迪 KH -------Cambodia (Internet) 柬埔寨 CB -------Cambodia (CIA World Fact Book) 柬埔寨CM -------Cameroon 喀麦隆 中文名称英文名称数字代码2位代码3位代码港龙航空公司Dragon Air043 KA KDA 大韩航空公司Korean Air Lines Co.,Ltd. 180 KE KAL 韩亚航空公司Asiana Airlines Inc. 988 OZ AAR 日本航空公司Japan Airlines Company Ltd. 131 JL JAL 全日航空公司All Nippon Airways Co.,Ltd. 205 NH ANA 新加坡航空公司Singapore Airlines 618 SQ SIA 泰国国际航空公司Thai Airways International 217 TG THA 美国西北航空公司Northwest Airlines 012 NW NWA 加拿大国际航空公司Canadian Airlines International 018 CP CDN 美国联合航空公司United Airlines 016 UA UAL 英国航空公司British Airways 125 BA BAW 荷兰皇家航空公司Klm Royal Dutch Airlines 074 KL KLM 德国汉莎航空公司Lufthansa Cargo AG 020 LH GEC 法国航空公司Air France 057 AF AFR 瑞士航空公司Swissair 085 SR SWR 奥地利航空公司Austrian Airlines 257 OS AUA 俄罗斯国际航空公司Aeroflot Russian International 555 SU AFL 澳洲航空公司Qantas Airways 081 QF QFA 芬兰航空公司Finnair Airlines 105 AY FIN F Emirates 176 EK UAE 斯堪的纳维亚(北欧)航空公司Scandinavian Airlines 117 SK SAS 文莱皇家航空公司Royal Brunei Airlines 672 BI RBA 印度尼西亚鹰航空公司Garuda Indonesia Airlines 126 GA GIA 新加坡胜安航空公司SilkAir(Singapore) Pty.Ltd. 629 MI SLK 马来西亚航空公司Malaysian Airlines System Berhad 232 MH MAS 埃塞俄比亚航空公司Ethiopian Airlines Enterprise 071 ET ETH 美国长青国际航空公司Evergeen International Airlines Inc 494 EZ EIA 波兰航空公司Lot-Polish Airlines 080 LO LOT 罗马尼亚航空公司Tarom Romanian Air Transport 281 RO ROT 乌兹别克斯坦航空公司Uzbekistan Airirways 250 HY UZB 台湾长荣航空公司EVA Airways Corporation 695 BR EVA 乌克兰航空公司Air Ukraine 891 6U UKR 中国南方航空公司China Southern Airlines 784 CZ CSN 蒙古航空公司Miat Mongolian Airlines 289 OM MGL 巴基斯坦国际航空公司Pakistan International Airlines 214 PK PIA 菲律宾航空公司Philippine Airlines 079 PR PAL 尼泊尔王家航空公司Royal Nepal Airlines 285 RA RNA 伊朗航空公司Iran Air-The Airlines of Isamic 096 IR IRA 日本航空系统株氏会航空公司Japan Air System 234 JD JAS 朝鲜航空公司Air Koryo 120 JS KOR 绩效与薪酬管理 教学号：11130133 姓名：刘明慧专业：人力资源管理 谷歌公司薪酬激励分析 一、谷歌公司简介 谷歌（Google）是一家美国上市的公司，于1998年9月以私有股份公司的创立，不久之后它就成为了全球搜索领域的先驱。2004年8月，谷歌公司的股票在纳斯达克（Nasdaq）上市，成为公有股份公司。谷歌公司的总部称作“Googleplex”，位于美国加州圣克拉拉县的芒廷维尤。“Googol”是一个数学术语，表示 1 后面带有100个零，它是由美国数学家爱德华·卡斯纳的侄子米尔顿·西洛塔所创造，因出现在凯斯纳和詹姆士·纽曼合著的“数学与想象力”一书中而得到普及。谷歌（Google）公司对这个词作了微小改变，借以反映公司的使命，意在组织网上无边无际的信息资。谷歌的实用性及便利性赢得了众多用户的青睐，它几乎完全是在用户的交口称颂下成为全球最知名的品牌之一的。 目前谷歌被公认为全球规模最大的搜索引擎，它提供了简单易用的免费服务。谷歌将自己定位为创新的源泉，在这里IT人士可以找到充满挑战的工作以及改变世界的机遇。 二、谷歌公司薪酬管理现状及优势 薪酬管理是人力资源管理乃至整个企业管理的核心内容之一，不仅涉及企业的经济核算与效益，而且与员工切身利益息息相关。科学有效的薪酬激励机制能够让员工发挥出最佳的潜能，为企业创造出更大的价值。 在《财富》杂志的2012年美国100家最佳雇主排行榜上，谷歌排名第一，并非浪得虚名。高福利、高薪酬，再加上贴心的人文关怀，谷歌公司无可厚非的受到人才们的青睐。 ㈠谷歌公司的薪酬体系 据调查，2012年谷歌公司平均薪水为：106,104美元；薪水最高的职位；高级软件工程师（140,481美元）；薪水最低职位：客户策略师（60,909美元）。 谷歌推出以绩效为导向的富有竞争力的全面薪酬：谷歌的全面薪酬包括工资、津贴、奖金、福利、保险、股票期权等。在对员工的短期、中期、和长期激励上，各自发挥着不同的作用。 对外，谷歌整体薪酬保持着市场上的强大竞争力；对内，充分考虑不同岗位，职级以及员工工作表现的差异性，建立了全方位的以业绩为导向的薪资理念。谷歌为所有正式员工发放股票期权，并且每年都会根据员工上一年度的业绩表现再授予股票期权。业 世界所有航空公司代码从1-9，从A-Z排列，最全，全好 下述航空公司将以2字代码进行排列。 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0-9 1 1A: 西班牙艾玛迪斯全球旅游分销系统公司(Amadeus Global Travel Distribution) 1B: 新加坡环亚旅游资讯系统有限公司(Abacus International) 1C: EDS InＦＯＲＭation Business (瑞士) 1D: Radixx Solutions International (美国) 1E: 中国民航信息网络股份有限公司(Travelsky Technology) 1F: INFINI Travel InＦＯＲＭation (日本) 1G: 美国伽利略国际公司(美国) 1H: Siren-Travel (俄罗斯) 1I: Netjets Aviation(Execjet, 美国) Deutsche Rettungsflugwacht(Civil Air Ambulance, 德国) Nova Airlines(Navigator, 瑞典) Sky Trek International Airlines(Phazer, 美国) Sierra Nevada Airlines(美国) Pegasus Hava Tasimaciligi(Sunturk, 土耳其) 1J: 爱克森斯国际科技有限公司(日本) 1K: Sutra (美国), Southern Cross Distribution (澳大利亚) 1L: Open Skies (美国) 1M: JSC Transport Automated InＦＯＲＭation Systems (TAIS) (俄罗斯) 1N: Navitaire (美国) 1P: WorldSpan (美国) 1Q: Sirena (俄罗斯) 1R: Hainan Phoenix InＦＯＲＭation Systems (中国) 1S: Sabre (美国) 1T: 1Time Airline (南非) 1U: Polyot Sirena (俄罗斯) 1V: Galileo International (美国) 1Y: Electronic Data Systems Corporation (美国) 干货分享-深度认识谷歌推广的各种计费方式 鉴于Google在搜索引擎行业上的龙头地位，出海企业深知Google广告的价值和重要性，都纷纷加入了谷歌广告推广这支大军。想要做好谷歌推广需要有一定的知识储备，而了解清楚谷歌推广的各种计费方式就是其中重要一点。 CPM（Cost Per Mille）：千人展现成本 简单说，就是广告主为广告被展现给1000个用户所支付的成本。按CPM计费模式的广告，只按展现量收费，用户的点击、下载、注册等行为是不会被收费的。按此计费的广告一般是以品牌展示和产品发布为主，曝光效果通常比较好，所以如果想要提升品牌或产品的知名度，CPM是一个不错的选择。不要忘记的是，CPM仅适用于展示广告网络的广告系列。 CPC（Cost Per Click）：单次点击费用 CPC是根据广告被点击次数来收费的，该结算方式从某种程度上来说可以加强作弊难度，每一次点击都会给广告主带来真实的流量或潜在客户，是常见的收费方式之一。现行的网络广告中，典型的按点击收费的模式就是搜索引擎的竞价排名。这种模式在信息流广告、图片展示广告中比较常见。此外，CPC模式还可以让广告主观察用户点击或者不点击广告的原因，为广告主提供有价值的洞见性分析。 CPA（Cost Per Action）：每次行动的费用 CPA广告计费模式是以用户行为作为指标来计费，且不限广告投放量。用户行为可以定义为达成一次交易、获得一个注册用户、获取一个用户的留言或者对网络广告的一次点击 等，此模式直指APP、手游推广的核心需求—应用下载和用户注册。CPA追求广告投放的实际效果，充分考虑广告主的利益，受到了众多广告主的青睐。 CPV（Cost Per View）：按显示效果付费 CPV是一种按照实际广告显示量来计费的广告模式，即当用户访问了会员站点，广告主的广告被展示出来，展示一次收费一次。CPV又叫富媒体，可投放图片，图文、Flash、视频等。此形式价格低、效果丰富，可满足不同广告需求。 CPT（Cost Per Time）：按时长付费 CPT是一种以展示时长来计费的模式，广告主选择广告位和投放时间，费用与广告点击量无关。CPT是一种很省心的广告计费模式，广告主可以直接在媒体上购买广告位进行自助投放，并进行人工预算分配，其中，广告位的价格由网站主自行设定。门户网站的包月广告就是这种模式。 希望以上介绍的计费方式对广大广告主在进行谷歌推广时有所帮助。但是，谷歌广告推广过程繁杂，需要花费大量的精力和时间，业务繁忙的广告主可以选择与谷歌授权的代理商如汇量科技等公司合作，它们有着丰富的海外广告投放经验以及专业的推广技术，可以帮助广告主最大化提升营销ROI。 世界各国国家代码简称A AE-阿联酋(UNITED EMIRATES) AF-阿富汗(AFGHANISTAN) AL-阿尔巴尼亚(ALBANIA) AM-亚美尼亚(ARMENIA) AO-安哥拉(ANGOLA) AR-阿根廷(ARGENTINA) AT-奥地利(AUSTRIA) AU-澳大利亚(AUSTRALIA) AZ-阿塞拜疆(AZERBAIJAN(REPUBLIC)) B BD-孟加拉(BANGLADESH) BE-比利时(BELGIUM) BF-布基纳法索(BURKINA FASO) BG-保加利亚(BULGARIA) BH-巴林(BAHREIN) BI-布隆迪(BURUNDI) BJ-贝宁(BENIN) BL-巴勒斯坦() BN-文莱(BRUNEI DARUSSALAM) BO-玻利维亚(BOLIVIA) BR-巴西(BRAZIL) BW-博茨瓦纳(BOTSWANA) BY-白俄罗斯(BYELORUSSIA) C CA-加拿大(CANADA) CF-中非(CENTRAL AFRICA) CG-刚果(CONGO) CH-瑞士(SWITZERLAND) CL-智利(CHILE) CM-喀麦隆(CAMEROON) CN-中国(CHINA) CO-哥伦比亚(COLOMBIA) CR-哥斯达黎加(COSTA RICA) CS-捷克(CZECH REPUBIC) CU-古巴(CUBA) CY-塞浦路斯(CYPRUS) D DE-德国(GERMANY) DK-丹麦(DENMARK) DO-多米尼加共和国(DOMINICAN REPUBLIC) DZ-阿尔及利亚(ALGERIA) E Google 第一.福利 1月27日，在《财富》杂志日前评选的2008年度“美国100家最佳雇主”中，Google继去年之后再度封王。为此，《财富》杂志记者亲自前往Google总部，揭开了Google不为人所知的九个秘密。 第一：自行车取代滑板车 Google位于加州山景城的总部曾为员工准备两轮Segways 电动车及滑板车作为代步工具。但是，由于segway经常容易损坏，而滑板车又容易使员工摔跤，自行车目前已成为Google在公司内部最主要的交通工具。 第二：包场看电影 如何使超过6000名公司员工观看电影的首映式？当然是把整个电影院全天都包下来。作为额外福利，每个人还能带上一位客人。 第三：宝宝也有福利 Google员工的子女现在就在Google上班可能年龄还太小了，不过这并不意味着Google就不关心员工子女的健康。事实上，Google刚出台了一项新政策，允许年轻的妈妈们每年带薪休假 18周，专门回家照顾孩子。当然，爸爸们也可以休假，不过时 间要短一些，只有7周。 第四：Google自己的“Facebook” Google的内部网Moma，提供了各种丰富的信息，除了企业 介绍、福利、内部信、员工手册这些常规内容。不过Moma最经 常被用来查找其他的Google员工。为什么呢？因为Moma提供了公司15916名员工的照片。 第五：Google的空气 太阳能电池、可回收的地毯和环保交通工具只是Google环保行动的一小部分，最近，Google在山景城的总部安装了一种特制的、对环境无害的空气过滤系统，可以清除空气中的有毒物质和杂质。如果你是Google员工，在办公室里待个通宵编写代码，至少不用担心呼吸不到新鲜的空气了。 世界各国国家代码简称 A AE-阿联酋(UNITED EMIRATES) AF-阿富汗(AFGHANISTAN) AL-阿尔巴尼亚(ALBANIA) AM-亚美尼亚(ARMENIA) AO-安哥拉(ANGOLA) AR-阿根廷(ARGENTINA) AT-奥地利(AUSTRIA) AU-澳大利亚(AUSTRALIA) AZ-阿塞拜疆(AZERBAIJAN(REPUBLIC)) B BD-孟加拉(BANGLADESH) BE-比利时(BELGIUM) BF-布基纳法索(BURKINA FASO) BG-保加利亚(BULGARIA) BH-巴林(BAHREIN) BI-布隆迪(BURUNDI) BJ-贝宁(BENIN) BL-巴勒斯坦() BN-文莱(BRUNEI DARUSSALAM) BO-玻利维亚(BOLIVIA) BR-巴西(BRAZIL) BW-博茨瓦纳(BOTSWANA) BY-白俄罗斯(BYELORUSSIA) C CA-加拿大(CANADA) CF-中非(CENTRAL AFRICA) CG-刚果(CONGO) CH-瑞士(SWITZERLAND) CL-智利(CHILE) CM-喀麦隆(CAMEROON) CN-中国(CHINA) CO-哥伦比亚(COLOMBIA) CR-哥斯达黎加(COSTA RICA) CS-捷克(CZECH REPUBIC) CU-古巴(CUBA) CY-塞浦路斯(CYPRUS) D DE-德国(GERMANY) DK-丹麦(DENMARK) DO-多米尼加共和国(DOMINICAN REPUBLIC) DZ-阿尔及利亚(ALGERIA) HRM薪酬福利案例 1、Google公司员工福利诱惑动摇微软士气 史蒂夫.巴尔默遇到了很棘手的员工士气问题。几年来，微软公司的股价一直增长乏力，在华盛顿州雷德蒙德市的公司总部里，员工们对Google公司的向往之情也在不断扩散。 2、HR如何凭借科学和艺术“玩转”调薪 A公司是一家民营家具制造企业，近两年业绩非常突出，员工也已经达到1000多人。但是，每到调薪时期，HR经理都被搞得焦头烂额。 3、打造高竞争性的薪酬管理体系 从简单的社会功能来讲，企业作为以赢利为目的的组织，其特性决定了一点：企业必须在一个高度开放的市场中保持高度的竞争性与优越性，无论是销售管理、客户管理还是内部流程管理，这个原则贯穿于企业的产生与发展。 4、戴蒙德国际工厂的100分俱乐部 1981年，在马萨诸塞州巴莫尔的戴蒙德国际工厂制造纸板装蛋箱的325名雇员正面临着一个无法预测的未来。斯泰罗佛姆式集装箱的问世，使竞争不断激化；纸板装蛋箱的价格暴跌，使生产厂家受到致命的打击；工人们都在为将被解雇而担忧；劳资关系非常紧张。 5、画饼充饥的学问 对于快速成长型公司来说，“分的是理想，经营的是未来，享受的是过程” ——企业分配中“现货”与“期货”激励的平衡 每年我都会为他们画一张饼 2000年初，作为国内第一家在香港创业板上市的民营企业，生产学习机、跳舞毯在当时小有名气的裕兴公司一下子成为媒体关注的焦点。曾经与世界首富盖茨握过手的裕兴总裁祝维沙，在谈及创业及在艰苦环境下的快速成长经验时经常说这句话。 6、太和之道：员工薪酬的动态调整和管理 “不公平！”某工程建设公司的项目经理李先生忿忿地说，“目前我的基本工资和别的项目经理一样多，可我们这个项目难度这么大、项目周期这么长，而且业主要求很高、很难对付，业绩风险这么大，奖金收入也很难保障。还不如做个小项目，又容易完成，收入也高。我的下属也都有这样的抱怨，让我怎么去管理、激励他们？从另一个角度说吧，公司有任务，我也不好挑肥拣瘦的，但这样的薪酬制度确实让人感觉不公平。” 7、为什么员工的积极性越来越低 F公司是一家生产电信产品的公司。在创业初期，依靠一批志同道合的朋友，大家不怕苦不怕累，从早到晚拼命干。公司发展迅速，几年之后，员工由原来的十几人发展到几百人，业务收入由原来的每月十来万发展到每月上千万。企业大了，人也多了，但公司领导明显感觉到，大家的工作积极性越来越低，也越来越计较。 8、薪酬与“学习曲线”操作 著名经济学家Wright曾经根据飞机制造提出了“学习曲线”理论：每当产量有所提升时，每架飞机的成本也会有所下降；而员工通过学习，可以达到上述效果。对于提倡“以人为本”的企业而言，将“学习曲线”理论运用到薪酬管理中，是一个重大的突破。 9、用福利计划留住关键人才 航空公司代码表 国内航空公司 中文名称英文名称2位代码3位代码中国国际航空公司Air China CA CCA 中国北方航空公司China Northern Airlines CJ CBF 中国南方航空公司China Southern Airlines CZ CSN 中国西南航空公司China Southwest Airlines SZ CXN 中国西北航空公司China Northwest Airlines WH CWN 东方航空公司China Eastern Airlines MU CES 厦门航空公司Xiamen Airlines MF CXA 山东航空公司Shandong Airlines SC CDG 上海航空公司Shanghai Airlines FM CSF 深圳航空公司Shenzhen Airlines 4G CSJ 中国新华航空公司Chinaxinhua Airlines X2 CXH 中国航空股份公司F6 CAG 云南航空公司Yunnan Airlines 3Q CYH 新疆航空公司Xinjiang Airlines XO CXJ 四川航空公司Sichuan Airlines 3U CSC 中原航空公司Z2 CYN 武汉航空公司Wuhan Airlines WU CWU 贵州航空公司Guizhou Airlines G4 CGH 海南航空公司Hainan Airlines H4 CHH 中国通用航空公司GP CTH 南京航空公司3W CNJ 浙江航空公司ZJ CJG 长城航空公司GW CGW 福建航空公司Fujian Airlines FJ CFJ 长安航空公司2Z CGN 国际航空公司 中文名称英文名称2位代码3位代码港龙航空公司Dragon Air KA KDA 大韩航空公司Korean Air KE AKA 韩亚航空公司Asiana Airways OZ AAR 日本航空公司Japan Airlines JL JAL 全日空公司All Nippon Airways NH ANA 新加坡航空公司Singapore Airlines SQ SIA 泰国国际航空公司Thai Airways International TG THA 美国西北航空公司Northwest Airlines NW NW A 加拿大国际航空公司Canadian Airlines International AC 美国联合航空公司United Airlines UA UAL 英国航空公司British Airways BA BAW 荷兰皇家航空公司Klm Royal Dutch Airlines KL KLM 是的，中国电话国家代码是0086，从国外打回国内要播86这个国家代码的。打国际长途总是以“00”开头的，这个“00”是国际冠字，打任何国家的国际长途都是这样，“00”之后的数字就是各个国家的国际长途代码了，中国的代码是“86”，所以，从国外打中国的电话，开头播的就是0086，然后就是各省、直辖市的区号（不要加0的），再往后就是被叫号码了。如：从美国打北京的电话，就播：0086-10-88888888，打长沙的就是：0086+731+888888，0086中其实只有86才是中国的国际区号，00是中国的国际长途直拨接入码，每个国家或者同一个国家不同电信公司的国际长途直拨接入码都是不同的，有的是001、有的是002，还有01、009、031之类，所以国际上用一个通用符号+来代替。如果从国外往中国打电话，就要在86前加上当地的国际接入码来拨号了。 世界各国长途电话国家代码： 中国 86 阿富汗 93 阿尔巴尼亚 355 阿尔及利亚 213 安道尔 376 安哥拉 244 安圭拉岛(英) 1 809 安提瓜和巴布达 1 268 阿根廷 54 亚美尼亚 374 阿鲁巴岛 297 阿森松(英) 247 澳大利亚 61 奥地利 43 阿塞拜疆 994 巴哈马国 1 242 巴林 973 孟加拉国 880 巴巴多斯 1 246 白俄罗斯 375 比利时 32 伯利兹 501 贝宁 229 百慕大群岛(英) 1 809 不丹 975 玻利维亚 591 博茨瓦纳 267 巴西 55 文莱 673 保加利亚 359 布基纳法索 226 布隆迪 257 喀麦隆 237 加拿大 1 加那利群岛(西) 34 佛得角 238 乍得 235 中非 236 智利 56 开曼群岛(英) 1 809 圣诞岛 619164 科科斯岛 619162 哥伦比亚 57 多米尼加联邦 1 809 科摩罗 269 刚果 242 科克群岛(新) 682 哥斯达黎加 506 克罗地亚 384 古巴 53 塞浦路斯 357 捷克 42 丹麦 45 迪戈加西亚 246 法罗群岛 298 格陵兰岛 299 吉布提 253 多米尼加共和国 1 809 厄瓜多尔 593 埃及 20 萨尔瓦多 503 赤道几内亚 240 爱沙尼亚 372 埃塞俄比亚 251 厄立特里亚 291 福克兰群岛 306 斐济 679 芬兰 358 法国 33 法属圭亚那 594 加蓬 241 冈比亚 220 格鲁吉亚 995 德国 49 加纳 233 直布罗陀(英) 350 谷歌公司人力资源管理分析 0911061125 陆芸“Google”是一个凡是互联网使用者几乎都知道的名字，越来越多的人离不开这个公司提供的服务，这个公司也不断的推出新鲜理念的服务让更多的互联网使用者受益，也有越来越多的人为加入这个神秘的公司做着不懈的努力。Google的使命：整合全球的信息，使其为每个人所用，让所有人受益。Google是目前被公认为全球最大的搜索引擎，用户通过访问Google简单的不能再简单的网页，可以瞬间找到所有想要的隶属与全球各个角落的信息。 在经历2004年上市之后，Google开始井喷式的发展，一举成为市值最高的企业，企业规模也随之扩张，快速的扩张让Google面临着方方面面的考验，对于一个以人才见长的企业，人力资源管理能否适应Google的快速发展？能否帮助变成大象的Google一如既往地前行，并支撑这个新巨头的，这是Google面临的最大的挑战。 其实，Google几年来的发展说明，他们已经解决了这个挑战，不断吸纳顶尖人才，远低于同业的员工流失率，创新而富有特色的企业文化等，都是不同侧面的佐证。 本篇文章就是从不同的角度来分析和表述谷歌公司人力资源管理的特点、它存在的问题以及一些改进的建议，以支持我国互联网创新企业的实现和可持续的发展。 首先是谷歌公司的人力资源管理的特点，我认为谷歌公司的管理特色最重要的一个特点就是创新，摒除了传统公司管理环节的不足之处，而采纳了针对公司自身特点的创新管理方式是它成功的重要因素。 文化管理： 不断创新是互联网企业的生存法则之一，以工程师为主体是互联网行业的人才架构的特色。Google作为互联网行业的巨头一直秉承着“我们只雇佣最聪明的人”的人才宗旨，Google 相信，只有“最聪明的人”才能在这个全新的互联网领域不断创新。其两位创始人甚至对于所有领域的人才都偏爱有加，如果你是脑外科或是火箭研究领域的博士，也可能有机会去Google工作，现在Google的员工中就包含一名火箭领域的科学家和一名脑外科医生。 “Google是以研发人员为中心的公司，倡导“工程师文化”。因此Google倡导并鼓励一种创新、民主的企业文化，从工程师的观念创新，落实到产品设计，最后延伸到管理，在Google的每一个环节都有体现。”Google大中华区人力资源总监邓涛说。 毫无疑问，Google的成功，从很大程度上要归功于其吸引人才的能力，以及适合新人发挥的企业文化。 Google主张开放自由、民主的企业文化，“Google一直秉承吸引最聪明的人才来Google 工作的理念，要想吸引最聪明的人来创新，就要先给人才创造一个非常开放、宽松的环境。管理上的“民主”就要求每一个管理者面对下属的提议不能直接回复“NO”，而是得说可以考虑如何帮助他发展。” “Google希望创造一个百家争鸣的氛围，使大家能够和敢于发表自己的看法，给各种创意一个去试验的机会。可以想象，如果在互联网企业中形成“领导说不可以就不可以”的文化，企业又怎能领先技术发展？产品又怎能满足客户多变的需求？所以，在Google，我们强调：第一是要允许你做；第二是给你资源帮你做；第三是允许你犯错误。这就是我们追求的创新文化，要让每个人的想法、有机会去实现。” Google拥有Google文化委员会，在督导文化推广的同时，也倡导一些活动主题，由员工来组织相应的活动，比如社区活动、活动和资助残疾人活动等。员工拥有更多的主动权，参与的兴趣也会更加浓厚。 有人把Google式文化创新称为德鲁克式理想“工作应当体现人的社会价值，如机会、社交、认同以及个人满足，而非仅仅反映成本、效率一类的商业价值”。Google成功证明了晒晒知名公司的福利清单
航空公司代码
谷歌员工福利
谷歌人力资源管理分析
世界国家二字代码
google雇主品牌经营
全球世界国家名称及缩写代码
国际国内航空公司代码表
谷歌公司薪酬激励分析
世界所有航空公司代码 从1-9,从A-Z排列,最全,全好
干货分享-深度认识谷歌推广的各种计费方式
世界各国国家代码简称
google雇主品牌经营
世界各国国家代码简称
HRM薪酬福利案例
世界各大航空公司代码表
各国的电话国家代码及中国国内各市的长途代码
谷歌公司人力资源管理分析