不：
Run Code Online (Sandbox Code Playgroud)x = 1 y = 2 long_variable = 3
如果我理解正确的话，还建议不要这样做：
salaries = {
"Alice": 1500,
"Bob": 1300,
# ^^ extra whitespace
}
这些具体建议有什么用？
这条规则是 Guido\xe2\x80\x99s 原始风格文章的一部分这条规则是 Guido\xe2\x80\x99s于 1998 年发表的，他在其中指出：
\n\n\n（不要费心在上述任何问题上与我争论——15 年来我已经习惯了这种风格。）
\n
所以他并没有直接激励这件事，但我可以想到一些你想要避免这样做的充分理由。将代码与空格对齐可能看起来在当时，
\n但大多数项目都不是静态的。你经常会看到，在现实项目中，代码会随着时间的推移而发生更改，并且您可以在仔细对齐的列表中添加、删除或重命名条目。您很容易最终不得不调整整个块的对齐方式，因为您的更改改变了现在最长的条目。
\n这些变化现在会让你做更多的工作。您必须重新对齐块。您的同事和未来的您必须做更多的工作来阅读版本控制系统中的变更集。
\n（是的，代码格式化程序可以进行重新对齐，但是自动化工具无法修复您的代码差异，现在涉及大量与您的提交无关的行，除了重新对齐之外）。
\n或者，后来的编辑可能会对必须重新对齐其他条目的前景犹豫不决。Wine 项目dlls/msi/msipriv.h文件一开始排列得很好，但随着 时间的推移， 不一致的情况逐渐出现，最终会变得有点混乱。
其次，对齐并不一定会使代码更易于阅读；如果中间有足够的空白，您很容易误解什么值与什么名称对应。
\n同时，PEP 8 是一个指南。该文件本身指出：
\n\n\n愚蠢的一致性是小头脑的恶魔
\n[...]
\n然而，知道何时要不一致——有时风格指南的建议并不适用。如有疑问，请运用您的最佳判断。查看其他示例并决定哪个看起来最好。
\n
无论如何，您需要自己决定何时使用对齐。
\nPython 标准库的某些部分违反了这一特定规则（是的，这是上面 Wine 项目示例的 Python 反映；该示例是几年前从外部项目导入的），并且还有其他违反 PEP8 规则的示例由于历史原因，但有时在某些有限的领域，打破规则也是有意义的。
\n| 归档时间： |
|
| 查看次数： |
1531 次 |
| 最近记录： |