我认为每个 Python 代码都见过PEP 8。让我印象深刻的部分是:
Limit all lines to a maximum of 79 characters.
我坐在宽屏显示器上,在屏幕上进行编码。我没有在终端中编码,也不打算在终端中编码。因此,我对字符行限制没有任何问题。
有多少人真正遵循这个限制?如果您不在 80 个字符限制的终端中编码,您是否仍然遵循它?我不遵守它是不是很糟糕?
我讨厌这个限制是如何与 Python 的“样式指南”分开的 >.<
我认为每个 Python 代码都见过PEP 8。让我印象深刻的部分是:
Limit all lines to a maximum of 79 characters.
我坐在宽屏显示器上,在屏幕上进行编码。我没有在终端中编码,也不打算在终端中编码。因此,我对字符行限制没有任何问题。
有多少人真正遵循这个限制?如果您不在 80 个字符限制的终端中编码,您是否仍然遵循它?我不遵守它是不是很糟糕?
我讨厌这个限制是如何与 Python 的“样式指南”分开的 >.<
政治人物 8:
但最重要的是:知道何时不一致——有时风格指南并不适用。如有疑问,请使用您的最佳判断。
你是唯一一个会阅读代码的人吗?
无论您使用哪种语言进行编程,都建议您缩短代码行长度。排长队通常有两种原因:
深度嵌套的代码:这种类型的代码很难遵循,尤其是如果你有超过 2 层的嵌套。阅读代码时容易错过 else 子句,或者在阅读较长的函数时忘记了 else 是什么意思。尝试在几个函数中分解代码以提高可读性。
复杂的表达式:比如当你从一个对象中访问一个对象中的一个值时......或者当你需要对来自 10 个不同位置的多个值执行单个操作时,你将所有函数调用和运算符合并到一行中. 如果您使用临时变量将逻辑拆分为更容易掌握的更小段,您将显着提高可读性。你也应该调查一下。
话虽如此,PEP 只是一个指导方针。当你觉得你有理由这样做时,请随意打破它。如果你大部分时间都破坏了它,你需要重新考虑你编写代码的方式。
我发现很难阅读超过 80 个字符的文本。我的眼睛在移回左边距时往往会失去这一行。因此,从某种意义上说,这不是由于必须在终端(或 cmd 窗口或 xterm)上查看代码而受到的限制,但它是可读性要求。我发现自己有时会违反一两个字符的规则,但总的来说我不介意。此外,我几乎不需要使用 \ 延续字符,因为我利用了列表中的隐式延续。
我将编辑器设置为向我显示 80 个字符的限制行,并将其用作警告,而不是停止标志。如果我可以在达到极限之前整齐地继续下一行,我会这样做。但是,如果添加一个延续会让人难以阅读或让人困惑,那么我有一条很长的路线。我不会仅仅为了指南而使代码更难阅读。
没门。
✔ 我的论点:
✔ Linus Torvalds 的论点:
grep
或“在文件中查找”将失败字符串在意外位置被切断。
垂直限制(VT100终端)比80 char水平限制更痛苦
✔ 判决:
It's like try-
ing to read
a news arti-
cle written
like this.
如果它是您的代码库,您可以做任何您想做的事情。如果是别人的,那么你必须按照他们的规则玩。例如,谷歌有 2 个字符缩进,但 PEP 8 说要使用 4 个空格。我相信他们是 Guido 引用的关于在白天使用 2 个空格缩进和在晚上使用 4 个空格进行编程的引用。
即使使用宽屏显示器,我也喜欢字符限制,因为这样我就可以并排放置代码帧。
代码风格实际上完全取决于个人喜好。重要的部分是一致性。因此,无论如何都要编写让你开心的 Python 代码。
只要您不必在宽显示器上水平滚动(因为我已经看到了)。
PEP8 适用于人类 ,但即使您不遵循它,您的程序也会运行。
如果您不共享代码并且不打算这样做,请随心所欲。
如果您计划某天分享您的部分代码,那么您应该遵循 PEP8。我的意思是,如果几行是 85 个字符,可能没有人会关心。但如果代码的宽度始终超过 200 个字符,则代码将难以阅读。如果您曾经阅读过报纸,那么在使用列格式化文本时也会遇到同样的问题。
行长问题的解决方案可能既不是使用连续字符任意换行,也不是通过将一些表达式括在括号内来使用隐式续行。可能是引入中间变量和函数以使代码在逻辑上在少于 79 个字符时中断。
顺便说一句,您可能想要坚持更难的限制。我更喜欢 72 个字符,因为我可以在 80 个字符的文本邮件中允许一两个额外的引用级别。如果不这样做,识别将在第一次引用时中断。
与所有样式指南一样,它只是一个指南。你是否遵循它取决于你。主要目标是一致性。
也就是说,出于以下原因,我建议采用约 80 个字符的限制。