在笔者十几年（本科毕业已经十一年，我想将大学时候“写玩具程式”的经验也算进去）的编码经验中，是一直想着将代码写得好看些的
前些年，追求好看只以自己的喜好为标准，直到某天遇见pylint并用它给自己的代码打打分
我发现自己为之骄傲的规则，并不标准，世界上已经有了大家都认可的Python“好看”标准
由此，我知道了PEP8
PEP8（Python Enhancement Proposal 8），是Python官方推荐的编码风格，由Guido van Rossum（Python创始人）和其它Python开发者共同制定
PEP8 标准在Python官网上可以查看：https://www.python.org/dev/peps/pep-0008/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讨论链接：https://stackoverflow.com/questions/1125653/python-using-4-spaces-for-indentation-why更多说法是，缩进使用几个空格并不很重要，当它成为约定俗成的标准之后，大家遵守这规则即可
另外，笔者学习yaml语法规则时，曾经看见yaml文件推荐的缩进为两个空格
3、一行当中最多不超过79个字符这其实是一个见仁见智的规则
这规则来源于当年的显示器很窄，不超过79个字符能带来最好的阅读体验
后来显示器变宽，一行当中显示多个字符也是可以接受的
关于这一点，笔者的观点是可以不用严格遵守：如果项目组内设定了相关规则，遵守项目组规则就好
如果是提交到开源项目或是社区代码，大家还是尽量遵守该规则啦
对于笔者来说，使用vim敲代码，最喜欢的是分屏操作
当每行代码不超过79个字符时，可读性好许多
分屏示例，笔者14寸电脑只适合左右分屏4、长句的处理方式接上条，如果一行代码实在很长不能收在79个字符以内，我们便换个行
换行时候，加上额外4个空格缩进就好
5、行与行之间的空行同一个文件中，函数和类之间需要添加两个空行；同一个类中，函数间的需要加一个空行
此条是为代码可读性
6、字典中的空格字典当中，key和冒号之间请不要添加空格，value之前，加上一个空格
如下代码：aDict = { 'keyA': 1, 'keyB': 2}7、等号两边的空格等号两边只添加且只添加一个空格
a = b8、类型注解中的空格类型注解（type annotation），是Python3中新加的语法规则：Python当中也能指定变量是什么类型了
给变量加上类型注解时，变量名后面紧跟冒号，冒号之后类型之前，请加上一个空格
如下代码示例：# 其实和dict挺像的name: str = '嘟嘟'一篇介绍类型注解的博客：https://blog.logrocket.com/understanding-type-annotation-python/#what-static-type-checking9、注释书中没有，笔者自己想添加，接着发现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还是空格主要还是需要根据具体情况而定，理解各自的作用和影响是首要的
但总的来说，遵循社区公认的标准是一个良好的习惯
以上，是本篇的全部内容
空格可以随意使用，当大家都用相同规范时，代码可读性更高
笔者认为：项目组规范的优先级应该高于社区规范
（当然，许多组的规范是基于社区规范制定的
）