在笔者十几年（本科毕业已经十一年，我想将大学时候“写玩具程式”的经验也算进去）的编码经验中，是一直想着将代码写得好看些的。
前些年，追求好看只以自己的喜好为标准，直到某天遇见pylint并用它给自己的代码打打分。我发现自己为之骄傲的规则，并不标准，世界上已经有了大家都认可的Python“好看”标准。由此，我知道了PEP8。
PEP8（Python Enhancement Proposal 8），是Python官方推荐的编码风格，由Guido van Rossum（Python创始人）和其它Python开发者共同制定。
PEP8 标准在Python官网上可以查看：
Effective Python，花一整个小节介绍PEP8标准。作者在书中就空格、命名、表达式和import进行特别说明：这些规则是最好都遵守的。
为修正自己关于好看代码的认知，笔者在三年前，在VS code中将Python配置为完全参照PEP8标准，一路遵守下来，就PEP8标准而言，笔者已经攒了好些条想要分享的内容。
本篇文章结合笔者过去的使用经验与书中分享，专谈空格。
首先，是书中关于空格内容的翻译（注，笔者的翻译并非直译，其中会添加许多自己的理解）：
1、使用空格代替Tab用作缩进
Python的一个很严格语法规则是，代码的缩进必须对齐，如果两行同级别代码的缩进不对齐，编译会报IndentationError错误。
笔者十年前刚使用Python时，常常将空格和Tab搞混，建议初学者注意这个问题，并在自己的编辑器中设置好空格与tab的表现形式。下图是笔者在VS Code中的设置效果：
箭头为Tab，空格为小点
设置方法：打开设置界面，搜索Render Whitespace后选择all。
2、一次缩进最好使用4个空格表示
“这大概算是一种约定俗成的规则。”在笔者敲下这句话时，多想了想，为什么约定俗成的空格数量是4个呢？
笔者在Stack Overflow上看到一个很有意思的说法是：函数的定义为def加空格，使用4空格缩进函数名刚好和下一行对齐。
Stack Overflow讨论链接：
更多说法是，缩进使用几个空格并不很重要，当它成为约定俗成的标准之后，大家遵守这规则即可。另外，笔者学习yaml语法规则时，曾经看见yaml文件推荐的缩进为两个空格。
3、一行当中最多不超过79个字符
这其实是一个见仁见智的规则。这规则来源于当年的显示器很窄，不超过79个字符能带来最好的阅读体验。后来显示器变宽，一行当中显示多个字符也是可以接受的。
关于这一点，笔者的观点是可以不用严格遵守：如果项目组内设定了相关规则，遵守项目组规则就好。如果是提交到开源项目或是社区代码，大家还是尽量遵守该规则啦。
对于笔者来说，使用vim敲代码，最喜欢的是分屏操作。当每行代码不超过79个字符时，可读性好许多。
分屏示例，笔者14寸电脑只适合左右分屏
4、长句的处理方式
接上条，如果一行代码实在很长不能收在79个字符以内，我们便换个行。换行时候，加上额外4个空格缩进就好。
5、行与行之间的空行
同一个文件中，函数和类之间需要添加两个空行；同一个类中，函数间的需要加一个空行。此条是为代码可读性。
6、字典中的空格
字典当中，key和冒号之间请不要添加空格，value之前，加上一个空格。
如下代码：
aDict = {
'keyA': 1,
'keyB': 2
}
7、等号两边的空格
等号两边只添加且只添加一个空格。
a = b
8、类型注解中的空格
类型注解（type annotation），是Python3中新加的语法规则：Python当中也能指定变量是什么类型了。
给变量加上类型注解时，变量名后面紧跟冒号，冒号之后类型之前，请加上一个空格。如下代码示例：
# 其实和dict挺像的
name: str = '嘟嘟'
一篇介绍类型注解的博客：
9、注释
书中没有，笔者自己想添加，接着发现PEP8标准中有的内容：They should start with a # and a single space.
对于注释#号来说，如果#号之后添加一个空格，会更好看些。
--分割线--
Effective Python有中文翻译版，已经上架《微信读书》，笔者会对照着中文版阅读，我在PEP 8小节中看到读者Nawyjx的关于为什么PEP8推荐使用空格而不是Tab的整理，搬运到此处：
是个很好的问题。PEP 8推荐使用空格而不是制表符(Tab)进行缩进，主要有以下几个原因：
空格的宽度是固定的，而Tab的宽度依赖于编辑器，这会导致同一段代码在不同编辑器中显示方式不同，影响可读性。
若在未来需要改变缩进宽度，使用空格更易于修改。只需要全局替换空格数即可。而如果使用Tab，则需要考虑Tab和空格混合情况，替换会比较麻烦。
空格缩进在视觉上更加清晰，因为Tab实际上是一个字符，但呈现为多个空格，这会影响代码的美观整洁度。
大多数格式化工具和linters默认使用空格缩进，如果你的代码使用Tab，它们会将Tab转换为空格，这可能产生意外效果。
若代码需要在不支持Tab的环境中显示(如主流的版本控制系统)，Tab会完全丢失，而空格可以基本兼容。
所以，总的来说，空格缩进在可移植性、一致性、美观性上都优于Tab缩进。虽然在你个人开发环境中Tab也许看起来没什么问题，但考虑到代码可能被其他开发者阅读，或者在其他环境中显示，使用空格缩进可以避免很多潜在问题。
当然，这只是PEP 8的推荐，并不是强制要求。但作为Python之父Guido致力推广的代码风格指南，其中的原则值得我们重视。你可以根据个人喜好及团队规范来选择使用Tab还是空格，但理解各自的优缺点是很有必要的。
选择使用tab还是空格主要还是需要根据具体情况而定，理解各自的作用和影响是首要的。但总的来说，遵循社区公认的标准是一个良好的习惯。
以上，是本篇的全部内容。空格可以随意使用，当大家都用相同规范时，代码可读性更高。
笔者认为：项目组规范的优先级应该高于社区规范。（当然，许多组的规范是基于社区规范制定的。）
