Long Names Are Long

Code Reviews的意义

One smart thing Google does is rigorous code reviews. Every change, before you can land it, gets reviewed in at least two way. First, someone on the team does a normal review to make sure the code does what it’s supposed to.

google做的最明智的规定之一就是严格执行code review。每一个改动在上线之前，都要经过两种形式的review。首先，团队中的人会进行常规的review，以确保代码完成了它应该完成的功能。

既短又有意义的名字

有一点责任心，或是进取心的程序员都力争给自己的类、函数、变量起一个意义明了的名字，那是这样往往导致物极必反，使得变量的名字太长太长。

接下来就看看google如何起名字的。

命名中无需含有表示变量或参数类型的单词

直接看代码：

// Bad:
string nameString;
DockableModelessWindow dockableModelessWindow;

// Better:
string name;
DockableModelessWindow window;

对于集合使用名词的复数形式来描述
直接看代码：

// Bad:
List<DateTime> holidayDateList;
Map<Employee, Role> employeeRoleHashMap;

// Better:
List<DateTime> holidays;
Map<Employee, Role> employeeRoles;

这个规则同样适用于方法的命名：

// Bad:
mergeTableCells(List<TableCell> cells)
sortEventsUsingComparator(List<Event> events,
    Comparator<Event> comparator)

// Better:
merge(List<TableCell> cells)
sort(List<Event> events, Comparator<Event> comparator)

省略命名中无任何含义的单词
比如：data, state, amount, value, manager, engine, object, entity和instance。

省略命名中可以从上下文获取的单词

// Bad:
class AnnualHolidaySale {
  int _annualSaleRebate;
  void promoteHolidaySale() { ... }
}

// Better:
class AnnualHolidaySale {
  int _rebate;
  void promote() { ... }
}

跨平台编程

  #include "foo/foo.h"

  #include <stdint.h>
  #include <algorithm>

  #include "base/strings/utf_string_conversions.h"
  #include "chrome/common/render_messages.h"

  #if defined(OS_WIN)
  #include <windows.h>
  #include "base/win/scoped_comptr.h"
  #elif defined(OS_POSIX)
  #include "base/posix/global_descriptors.h"
  #endif