如果在工作中拿到别人而定代码是这样的：

会是什么样的感受？（多么痛的领悟）

最近看看阿里的码处高效的代码规范，看看书里面的一个小故事：

在美剧《硅谷〉中有这样一个经典镜头， 主人公Richard与同为开发工程师的女友闹分手，理由是两人对缩进方式有着截然不同的编程习惯，互相鄙视对方的代码风格。Richard认为 "one tab saves four spaces”，缩进使用Tab键操作更快，更节省存储空间;而女友坚持使用空格缩进，连续四次敲击空格的声音，把Richard折磨到几近崩溃，认为这是一种精神折磨。 Richard 觉得难以相处，吵完架下楼梯时，不小心摔倒了，还淡定地说，“I just tried to go down the stairs four steps ata time (这只是表达我的立场而已)。Tab键和空格键的争议在现实编程中确实存在。除此之外，在其他代码风格上，也存在不同的处理方式，往往是谁也说服不了谁，都站在自身"完全正确”的立场上，试图说服对方。这在团队开发效率上，往往是一个巨大的内耗，无休止的争论与最后的收益是成反比的。所以，我们认为一致性很重要，就像交通规则一样，我国规定靠右行驶，有些国家则规定靠左行驶，并没有绝对的优劣之分，但是在同一个国家或地区内必须要有统一的标准。 代码风格也是如此，无论选择哪一种处理方式，都需要部分人牺牲小我，成就大我，切实提升团队的研发效能。

代码风格并不影响程序运行，没有潜在的故障风险，通常与数据结构、逻辑表达无关，是指不可见字符的展示方式、代码元素的命名方式和代码注释风格等。比如，大括号是否换行、缩进方式、常量与变量的命名方式、注释是否统放置在代码上方等。代码风格的主要诉求是清爽统一、便于阅读和维护。统的代码风格可以让开发工程师们没有严重的代码心理壁垒，每个人都可以轻松地阅读并快速理解代码逻辑，便于高效协作，逐步形成团队的代码“味道”。

命名符合本语言的特性： 编程语言有很多种，主要分为两大部分——面向对象和面向过程，按照变量的定义和赋值要求，分为强类型语言和弱类型语言。这些语言的命名风格自成一派，但是在同一种语言当中运用多种语言的风格就会引起其他开发工程师的反感。如在java中，所有的命名均不能以下划线、美元符号($)开始或者结束。命名体现代码元素特征：类名遵循大驼峰，每个首字母大写，一般使用名词；方法名遵循小驼峰，除第一个单词外其他的单词首字母大写，一般使用动词；变量(参数，成员变量，局部变量)也是小驼峰；常量的命名方式比较特殊，字母全部大写，单词之间采用下划线连接。包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，则可以使用复数形式。抽象类命名使用Abstract或Base开头;异常类命名使用Exception结尾;测试类命名以它要测试的类名开始，以Test结尾。类型与中括号紧挨相连来定义数组。枚举类名带上Enum后缀，枚举成员名称需要全大写，单词间用下画线隔开。命名最好见名知意： 在代码命名的时候做到见名知意，可以减少注释的内容，达到自然解释的目的。在工作中做到见名知意难度是最大的，就是在给孩子起名的时候要反复斟酌一样。命名和代码内容不符的话会极大的增大理解的成本，甚至会将程序员引导进入错误的理解。因此在工作和生活中正确的英文拼写和语法可以让阅读这更容易理解，避免歧义。在某些符合语义情况下，尽量使用完整的单词组和来达到见名知意。

命名要符合语言特性、体现元素特征。命名做到望文知义、自解释是每个开发工程师的基本素质之一。我们在思量更好的代码元素命名的同时，也要敢于修改已有的不合理的命名方式。