一份值得了解的Google Python风格规范指南

网上有一份Google Python风格指南，非常感谢我的小密圈里的小伙伴"闪亮的日子"推荐!我周末细细读了，发现好东西真的很多。好的代码宛如艺术品，是具有工匠精神的，需要精雕细琢，现在我们来看看Google大师们对Python代码书写的指南，我加上了一些自己的理解,跟小伙伴分享一下~~

1

行的长度

一般每行不要超过80个字符.这个在大名鼎鼎的Pycharm和Spyder工具里面都是有提示的，原因很简单不易阅读. 并且建议不要使用反斜杠连接行.

1).变量申明:

如果一个文本字符串在一行放不下, 可以使用圆括号来实现隐式行连接:

2).条件判断：

3).函数入参：

但是也有例外：长的导入模块语句或者注释里的URL

2

导入格式

导入总应该放在文件顶部, 位于模块注释和文档字符串之后, 模块全局变量和常量之前

Bad:

import os,sys,re

Good:

import os

import sys

import re

导入顺序：应该按照从最通用到最不通用的顺序分组:

标准库导入

第三方库导入

应用程序指定导入

导入的分组中：应该根据每个模块的完整包路径按字典序排序, 忽略大小写.

import foo

from foo import bar

from foo.bar import baz

from foo.bar import Quux

from Foob import ar

这样看上去会非常整齐和舒服

3

命名

命名是一个时时刻刻都要碰到，也是非常基本的技能!记得我看代码大全2这本书的时候，里面就有一个章节长篇叙述如何好好命名.Python里面的风格和其他语言c++,java类似，大体分三类下面一一解读

1.全部小写

如果名字长，中间用下划线连接

1).局部变量

local_var_name

2).函数名字

function_name

3).函数的参数名字

function_parameter_name

4).模块和包的名字

module_name:

比如：from random import randint

package_name:

比如：from matplotlib.pyplot import scatter

2.全部大写

全局变量，中间用下划线连接 GLOBAL_VAR_NAME

3.驼峰式命名法

1).类的名字

ClassName

比如:PreparedRequest()

2).异常的名字

ExceptionName

比如:BaseException

4

缩进

用4个空格来缩进代码，绝对不要用tab, 也不要tab和空格混用. 对于行连接的情况, 你应该要么垂直对齐换行的元素

5

字符串

字符串是主要是格式化和引号的引用两大问题.

1).字符串格式化一般使用%或者format来格式化字符串

其实Python3里面推荐使用format方法，灵活方便而且强大。

Good :

x = '{}, {}!'.format(imperative, expletive)

2).避免在循环中用+和+=操作符来累加字符串

特别是在大的循环中连接长的字符串. 由于字符串是不可变的, 这样做会创建不必要的临时对象

Bad:

table=''

for i in range(100000):

table+='abc'

print table

因为你每加一次，就会分配一个临时内存，如果运行10万次开销非常大，时间也很长

Good:

table=[]

for i in range(10000):

table.append('abc')

print ''.join(table)

好的方法是把字符串都放在列表里面，用join方法一次性连接起来，时间会比上面那种方法快很多，内存开销也小一些.

3).引号使用

同一个文件中, 保持使用字符串引号的一致性. 使用单引号’或者双引号”之一用以引用字符串, 并在同一文件中沿用.

Bad:

Python("Why are you hiding your eyes?")

Gollum('The lint. It burns. It burns us.')

Gollum("Always the great lint. Watching. Watching.")

Good:

Python('Why are you hiding your eyes?')

Gollum("I'm scared of lint errors.")

Narrator('"Good!" thought a happy Python reviewer.')

6

函数

一个函数必须要有详细的文档字符串说明,要包含以下3个部分：

1).参数Args:

列出每个参数的名字, 并在名字后使用一个冒号和一个空格, 分隔对该参数的描述.

描述应该包括所需的类型和含义. 如果一个函数接受*foo(可变长度参数列表)或者**bar (任意关键字参数), 应该详细列出*foo和**bar.

2).返回值Returns: (或者 Yields: 用于生成器)

描述返回值的类型和语义. 如果函数返回None, 这一部分可以省略.

3).异常Raises:

列出与接口有关的所有异常,这个是非常正规的写法.

当然大部分我们的函数都是短小精悍的，一般都只考虑参数说明和返回值，并不是每个人都会考虑到异常处理,比如:

列表下标越界

动态变量为空

类型不匹配等等

Google这种写法其实对我们在构造一个新的函数，思考推敲函数的时候非常有借鉴意义，好的代码不仅精美还要安全.

7

类

类是非常重要的一块，我们大部分代码稍微复杂一点，都会写成类.

1).类应定义有描述该类的文档字符串

如果你的类有公共属性(Attributes), 那么文档中应该有一个属性(Attributes)段.

并且应该遵守和函数参数相同的格式.

2).如果一个类不继承自其它类, 就显式的从object继承. 嵌套类也一样

Bad:

class SampleClass:

pass

Good:

class SampleClass(object):

pass

继承自object 是为了使属性(properties)正常工作, 并且这样可以保护你的代码，避免一些隐患.

8

文件和Sockets

在文件和sockets结束时, 显式的关闭它.当然除了文件外, sockets或其他类似文件的对象在没有必要的情况下打开, 会有许多副作用, 特别是安全问题例如:

它们可能会消耗有限的系统资源, 如文件描述符. 如果这些资源在使用后没有及时归还系统, 那么用于处理这些对象的代码会将资源消耗殆尽.

仅仅是从逻辑上关闭文件和sockets, 那么它们仍然可能会被其共享的程序在无意中进行读或者写操作.

只有当它们真正被关闭后, 对于它们尝试进行读或者写操作将会抛出异常, 并使得问题快速显现出来.

其实它们都是带上下文管理器的，建议用with自动关闭

with open("hello.txt") as hello_file:

for line in hello_file:

print line

9

异常

异常这块非常重要,Google花了很多的笔墨描述异常使用，异常有利有弊小心使用

1.优点:

正常操作代码的控制流不会和错误处理代码混在一起. 当某种条件发生时, 它也允许控制流跳过多个框架. 例如, 一步跳出N个嵌套的函数, 而不必继续执行错误的代码.

2.缺点:

可能会导致让人困惑的控制流,调用库时容易错过错误情况.

3.异常必须遵守特定条件:

1).触发异常:

建议用raise MyException("Error message") 或者 raise MyException .

不要使用两个参数的形式( raise MyException, "Error message" )或者过时的字符串异常( raise "Error message" )

2).自定义异常

模块或包应该定义自己的特定域的异常基类, 这个基类应该从内建的Exception类继承.模块的异常基类应该叫做”Error”.

class Error(Exception):

pass

3).永远不要捕获所有异常：

永远不要使用 except: 语句来捕获所有异常。也不要捕获 Exception 或者 StandardError , 除非你打算重新触发该异常,

在异常这方面, Python非常宽容, except: 真的会捕获包括Python语法错误在内的任何错误. 使用 except: 很容易隐藏真正的bug.

4).尽量减少try/except块中的代码量.

try块的体积越大, 期望之外的异常就越容易被触发. 这种情况下, try/except块将隐藏真正的错误.

5).使用finally子句

用finally来执行那些无论try块中有不发生异常都应该被执行的代码. 这对于清理资源常常很有用, 例如关闭文件.

当捕获异常时, 使用 as 而不要用逗号. 这在Python3里面也是推荐使用的：

try:

raise Error

except Error as error:

pass

结论：

代码的功力不是一早一夕积累起来的，但是好的编程风格可以很快建立，越早了解越好，可以少走一些弯路. 并且减少很多debug的时间，因为好的代码风格已经帮助你规避了一些风险，希望初学者早早养成良好的编程习惯.

本文内容转载自网络，本着分享与传播的原则，版权归原作者所有，如有侵权请联系我们进行删除!