代码风格统一管理工具black #

在之前的文章中 介绍了 Linter ⼯具：flake8。使⽤ flake8， 我们可以检验代码是否遵循 PEP 8 规范，保持项⽬⻛格统⼀。

不过，虽然 PEP 8 规范为许多代码⻛格问题提供了标准答案，但 这份答案其实⾮常宏观，在许多细节要求上并不严格。在许多场景 中，同⼀段代码在符合 PEP 8 规范的前提下，可以写成好⼏种⻛格。

以下⾯的代码为例，同⼀个⽅法调⽤语句可以写成三种⻛格。

第⼀种⻛格：在不超过单⾏⻓度限制时，把所有⽅法参数写在同⼀⾏。

User.objects.create(name='piglei', gender='M', lang='Python', status='active')

第⼆种⻛格：在第⼆个参数时折⾏，并让后⾯的参数与之对⻬。

User.objects.create(name='piglei',
					gender='M',
					language='Python',
					status='active')

第三种⻛格：统⼀使⽤⼀层缩进，每个参数单独占⽤⼀⾏。

User.objects.create(
	name='piglei',
	gender='M',
	language='Python',
	status='active' )

假如你⽤ flake8 来扫描上⾯这三段代码，会发现它们虽然⻛格 迥异，但全都符合 PEP 8 规范。

从各种⾓度来说，上⾯三种⻛格并没有绝对的优劣之分，⼀切都 只与个⼈喜好有关。但问题是，不同⼈的喜好存在差异，⽽这种差异 最终只会给项⽬带来不必要的沟通成本，影响开发效率。

举个例⼦，有⼀位开发⼈员是第⼆种编码⻛格的坚决拥护者。在 审查代码时，他发现另⼀位开发者的所有函数调⽤代码都写成了第三 种⻛格。这时，他俩可能会围绕这个问题展开讨论，互相争辩⾃⼰的 ⻛格才是最好的。到最后，代码审查⾥的⼤多数讨论变成了代码⻛格 之争，消耗了⼤家的⼤部分精⼒。那些真正需要关注的代码问题，反 ⽽变得⽆⼈问津。

此外，通过⼿动编辑代码让其维持 PEP 8 ⻛格，其实还有另⼀个问题。

假设你喜欢第⼀种编码⻛格：只要函数参数没超过⻓度限制，就 坚决都放在⼀⾏⾥。某天你在开发新功能时，给函数调⽤增加了⼀些 新参数，修改后发现新代码的⻓度超过了最⼤⻓度限制，于是⼿动对 所有参数进⾏折⾏、对⻬，整个过程即机械⼜⿇烦。

因此，在多⼈参与的项⽬中，除了⽤ flake8 来扫描代码是否符 合 PEP 8 规范外，我推荐⼀个更为激进的代码格式化⼯具：black。

black ⽤起来很简单，只要执⾏ black {filename} 命令即 可。

举个例⼦，上⾯三种⻛格的函数调⽤代码被 black ⾃动格式化 后，都会统⼀变成下⾯这样：

User.objects.create(name="piglei", gender="M", language="Python", status="active")

因为代码没有超过单⾏⻓度限制，所以 black 不会进⾏任何 换⾏，已有的换⾏也会被压缩到同⼀⾏。与此同时，代码⾥字符 串字⾯量两侧的单引号也全被替换成了双引号

当函数增加了新参数，超出单⾏⻓度限制以后，black 会根据情 况⾃动将代码格式化成以下两种⻛格：

# 1. 代码稍微⻓了⼀点⼉，black 会尝试将所有参数单独换⾏ 
User.objects.create(name="piglei", gender="M", language="Python", status="active", points=100 ) 
# 2. 代码过⻓，black 会让每个参数各占⼀⾏ 
User.objects.create(
	name="piglei",
	gender="M",
	language="Python",
	status="active",
	points=100,
	location="Shenzhen"
)

作为⼀个代码格式化⼯具，black 最⼤的特点在于它的不可配置 性。正如官⽅介绍所⾔，black 是⼀个“毫不妥协的代码格式化⼯ 具”（The Uncompromising Code Formatter）。和许多其他格式化⼯具 相⽐，black 的配置项可以⽤“贫瘠”两个字来形容。除了单⾏⻓度以 外，你基本⽆法对 black 的⾏为做任何调整。

black 配置项

从我个⼈的经验来看，虽然 black 格式化过的代码并⾮⼗全⼗ 美，肯定不能在所有细节上让⼤家都满意，但它确实能让我们不⽤在 各种编码⻛格间纠结，能有效解决许多问题。整体来看，在⼤型项⽬ 中引⼊ black，利远⼤于弊。