This document is a list of differences from the overallChromium Style Guide, which is in turn a set of differences from theGoogle C++ Style Guide. The long-term goal is to make both Chromium and Blink style more similar to Google style over time, so this document aims to highlight areas where Blink style differs from Chromium style.
SeeBlink readme for more details on Blink directories and their type usage.
Good:
String title;Vector<KURL> urls;HashMap<int,Deque<RefPtr<SecurityOrigin>>> origins;
Bad:
std::string title; std::vector<GURL> urls; std::unordered_map<int, std::deque<url::Origin>> origins;
When interacting with WTF types, usewtf_size_t instead ofsize_t.
new anddeleteChromiumrecommends avoiding bare new/delete; Blink bans them. In addition to the options there, Blink objects may be allocated usingblink::MakeGarbageCollected and manage their lifetimes using strong Blink GC references, depending on the type. SeeHow Blink Works for more information.
A class only can have either Create() factory functions or public constructors. In case you want to call MakeGarbageCollected<> from a Create() method, a PassKey pattern can be used. Note that the auto-generated binding classes keep using Create() methods consistently.
Good:
classHistoryItem{public:HistoryItem();~HistoryItem();...}voidDocumentLoader::SetHistoryItemStateForCommit(){ history_item_=MakeGarbageCollected<HistoryItem>();...}
Good:
classBodyStreamBuffer{public:usingPassKey=base::PassKey<BodyStreamBuffer>;staticBodyStreamBuffer*Create();BodyStreamBuffer(PassKey);...}BodyStreamBuffer*BodyStreamBuffer::Create(){auto* buffer=MakeGarbageCollected<BodyStreamBuffer>(PassKey()); buffer->Init();return buffer;}BodyStreamBuffer::BodyStreamBuffer(PassKey){}
Bad:
classHistoryItem{public:// Create() and a public constructor should not be mixed.staticHistoryItem*Create(){returnMakeGarbageCollected<HistoryItem>();}HistoryItem();~HistoryItem();...}
CamelCase for all function namesAll function names should useCamelCase()-style names, beginning with an uppercase letter.
As an exception, method names for web-exposed bindings begin with a lowercase letter to match JavaScript.
Good:
classDocument{public:// Function names should begin with an uppercase letter.virtualvoidShutdown();// However, web-exposed function names should begin with a lowercase letter.LocalDOMWindow* defaultView();// ...};
Bad:
classDocument{public:// Though this is a getter, all Blink function names must use camel case.LocalFrame* frame()const{return frame_;}// ...};
Good:
bool is_valid;bool did_send_data;
Bad:
bool valid;bool sent_data;
Precede setters with the word “set”. Prefer bare words for getters. Setter and getter names should match the names of the variable being accessed/mutated.
If a getter’s name collides with a type name, prefix it with “Get”.
Good:
classFrameTree{public:// Prefer to use the bare word for getters.Frame*FirstChild()const{return first_child_;}Frame*LastChild()const{return last_child_;}// However, if the type name and function name would conflict, prefix the// function name with “Get”.Frame*GetFrame()const{return frame_;}// ...};
Bad:
classFrameTree{public:// Should not be prefixed with “Get” since there's no naming conflict.Frame*GetFirstChild()const{return first_child_;}Frame*GetLastChild()const{return last_child_;}// ...};
Good:
classRootInlineBox{public:Node*GetLogicalStartBoxWithNode(InlineBox*&)const;// ...}
Bad:
classRootInlineBox{public:Node*LogicalStartBoxWithNode(InlineBox*&)const;// ...}
TheGoogle C++ Style Guide allows omitting parameter names out when they are unused. In Blink, you may leave obvious parameter names out of function declarations for historical reasons. A good rule of thumb is if the parameter type name contains the parameter name (without trailing numbers or pluralization), then the parameter name isn’t needed.
Good:
classNode{public:Node(TreeScope* tree_scope,ConstructionType construction_type);// You may leave them out like:// Node(TreeScope*, ConstructionType);// The function name makes the meaning of the parameters clear.voidSetActive(bool);voidSetDragged(bool);voidSetHovered(bool);// Parameters are not obvious.DispatchEventResultDispatchDOMActivateEvent(int detail,Event& underlying_event);};
Bad:
classNode{public:// ...// Parameters are not obvious.DispatchEventResultDispatchDOMActivateEvent(int,Event&);};
Prefer enums to bools for function parameters if callers are likely to be passing constants, since named constants are easier to read at the call site. Alternatively, you can usebase::StrongAlias<Tag, bool>. An exception to this rule is a setter function, where the name of the function already makes clear what the boolean is.
Good:
classFrameLoader{public:enumclassCloseType{ kNotForReload, kForReload,};boolShouldClose(CloseType){if(type==CloseType::kForReload){...}else{ DCHECK_EQ(type,CloseType::kNotForReload);...}}};// An named enum value makes it clear what the parameter is for.if(frame_->Loader().ShouldClose(FrameLoader::CloseType::kNotForReload)){// No need to use enums for boolean setters, since the meaning is clear. frame_->SetIsClosing(true);// ...
Good:
classFrameLoader{public:usingForReload=base::StrongAlias<classForReloadTag,bool>;boolShouldClose(ForReload){// A StrongAlias<_, bool> can be tested like a bool.if(for_reload){...}else{...}}};// Using a StrongAlias makes it clear what the parameter is for.if(frame_->Loader().ShouldClose(FrameLoader::ForReload(false))){// No need to use enums for boolean setters, since the meaning is clear. frame_->SetIsClosing(true);// ...
Bad:
classFrameLoader{public:boolShouldClose(bool for_reload){if(for_reload){...}else{...}}};// Not obvious what false means here.if(frame_->Loader().ShouldClose(false)){ frame_->SetIsClosing(ClosingState::kTrue);// ...
README.md to document high-level componentsDocumentation for a related-set of classes and how they interact should be done with aREADME.md file in the root directory of a component.