我不遵循 PEP 8 并把台词剪成 79 个字符是不是很糟糕？
我认为每个 Python 代码都见过 PEP 8。让我印象深刻的部分是：
Limit all lines to a maximum of 79 characters.
我坐在宽屏显示器上，并在屏幕上编码。我不在终端中编码，也不打算在终端中编码。因此，我对字符行限制没有任何问题。
有多少人真正遵守这个限制？如果您不在 80 个字符限制的终端中编码，您还会遵循它吗？我不遵守是不是很糟糕？
我讨厌这个限制如何成为 Python 的“风格指南”的一部分>。<
I think every Python code has seen PEP 8. The part that sticks out to me is:
Limit all lines to a maximum of 79 characters.
I'm sitting here on a widescreen monitor and coding right across the screen. I'm not coding in a terminal and don't plan on coding in a terminal. I therefor have no problems with character-line limits.
How many people actually follow this limit? Do you still follow it if you're not coding in a 80 character limit terminal? Is it bad that I don't follow it?
I hate how this restriction is apart of 'the style guide' for Python >.<
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
公众号 8：
PEP 8:
你是唯一一个会阅读代码的人吗？
无论您使用哪种语言进行编程，都建议您保持较短的代码行长度。
长行的原因通常有两种：
深度嵌套的代码：这种类型的代码很难理解，特别是当您有超过 2 层的嵌套时。在阅读代码时，往往会错过 else 子句，或者在阅读较长的函数时，会忘记哪个 else 是用于 if if 的。尝试将代码分解为多个函数以提高可读性。
复杂表达式：例如，当您从对象、对象、对象访问对象的值时...或者当您需要对来自 10 个不同位置的多个值执行单个操作，并且将所有函数调用和运算符合并到一行。如果使用临时变量将逻辑分割成更容易掌握的更小的部分，则将显着提高可读性。您还应该查看 this。
话虽这么说，PEP 只是一个指导方针。当您觉得有理由这样做时，请随意打破它。如果大多数时候你都破坏了它，那么你需要重新考虑编写代码的方式。
Are you the only one who's going to read the code?
No matter what language you're programming in, it's recommended practice to keep code line length down.
There are typically 2 types of causes for long lines:
Deeply nested code: this type of code is hard to follow, especially if you have more than 2 levels of nesting. There is a tendency to miss else clauses when reading the code, or forgetting which else is for what if when reading longer functions. Try to break the code in several functions to improve readability.
Complex expressions: like when you access a value from an object from an object from an object ... Or when you need to do a single operation on multiple values from 10 different places and you merge all the function calls and operators in a single line. You'll significantly improve the readability if you use temporary variables to split the logic into smaller segments that are easier to grasp. You should also look into this.
That being said, that PEP is just a guideline. Feel free to break it when you feel you're justified to do so. If you break it most of the time you need to reconsider the way you write code.
我将编辑器设置为显示 80 个字符的限制线，我将其用作警告，而不是停止标志。如果我能在达到极限之前将这一行整齐地延续到下一行，我就会这样做。然而，如果添加一个延续会使阅读变得困难或令人困惑，我就会排很长的队。我不会仅仅为了指导而使代码变得更难阅读。
I set my editor to show me the 80-character limit line, and I use it as a warning, not a stop sign. If I can continue the line neatly to the next line before hitting the limit, I do so. However, if putting in a continuation makes it hard to read or makes it confusing, I have a long line. I won't make code harder to read just for the sake of a guide.
我发现阅读超过 80 个字符的文本很困难。当我的眼睛移回左边距时，往往会失去该行。因此，从某种意义上说，这并不是由于必须在终端（或 cmd 窗口或 xterm）上查看代码而造成的限制，而是一种可读性要求。
我发现自己有时会违反一两个字符的规则，但总的来说我并不介意。另外，我几乎不需要使用 \ 延续字符，因为我利用了列表中的隐式延续。
I find it hard to read text that spans over 80 characters. My eye tends to lose the row while moving back to the left margin. So in a sense it is not a restriction due to having to view the code on a terminal (or a cmd window or xterm), but it is a readability mandate.
I find myself breaking the rule by one or two characters at times, but overall I don't mind it. Also, I hardly ever have to use the \ continuation character, as I take advantage of the implicit continuation in lists.
不可能。
✔ 我的论点：
✔ Linus Torvalds 的参数：
grep或“在文件中查找”将失败，字符串在非预期位置被切断。垂直限制（VT100终端）比80个字符水平限制更痛苦
✔ 结论：
No Way.
✔ My Arguments:
✔ Linus Torvalds' Arguments:
grepor 'find in files' will fail strings are severed at unintended location.Vertical limit(VT100 terminal) is more painful than 80 char horizontal limit
✔ The verdict:
如果这是您的代码库，您可以做任何您想做的事情。如果是别人的，那么你就必须遵守他们的规则。例如，Google 有 2 个字符缩进，但 PEP 8 表示使用 4 个空格。我相信这是 Guido 的一段话，内容是关于白天使用 2 个空格缩进，晚上使用 4 个空格进行编程。
即使使用宽屏显示器，我也喜欢字符限制，因为这样我就可以并排放置代码帧。
代码风格实际上完全取决于个人喜好。重要的部分是一致性。所以无论如何都要编写你的 Python 代码，让你开心。
You can do whatever you want if it is your codebase. If it is someone else's then you have to play by their rules. Google for example has 2 character indents but PEP 8 says to use 4 spaces. I believe their is some quote from Guido about programming with 2 space indents by day and 4 spaces by night.
I like a character limit even with a widescreen monitor because then I can put frames of code side-by-side.
Code style is really all about personal preference. The important part is consistency. So write your python code anyway that makes you happy.
只要您不必在宽显示器上水平滚动（因为我已经看到了）。
As long as you don't have to scroll horizontally on your wide monitor (because I have seen that).
与所有风格指南一样，它只是一个指南。这取决于你是否遵循它。主要目标是一致性。
也就是说，出于以下原因，我建议采用约 80 个字符的限制。
As with all style guides, it's just that, a guide. It's up to you whether or not you follow it. The main objective is consistency.
That said, I would recommend adopting an ~80 character limit for the following reasons.
PEP8 是为人类设计的，但即使你不遵循它，你的程序也会运行。
如果您不共享您的代码并且不打算这样做，请执行您想做的任何操作。
如果您计划有一天分享您的部分代码，那么您应该遵循 PEP8。我的意思是，可能没有人会关心几行是否有 85 个字符。但如果代码的宽度始终超过 200 个字符，就会很难阅读。如果您读过报纸，当文本使用分栏格式化时，就会遇到同样的问题。
行长度问题的解决方案可能既不是带有连续字符的任意换行符，也不是通过将某些表达式括在括号内来使用隐式行连续。它可能会引入中间变量和函数，以使代码在逻辑上中断少于 79 个字符。
顺便说一句，您可能想坚持更严格的限制。我更喜欢 72 个字符，因为我可以在 80 个字符的文本邮件中允许一两个额外的引用级别。如果不这样做，标识将在第一次引用时中断。
PEP8 is for humans but your program will run even if you do not follow it.
If you do not share your code and do not plan to do so, do whatever you want.
If you plan to share some part of your code someday, then you should follow PEP8. I mean, probably nobody will care if a few lines are 85 characters. But the code will be hard to read if it consistently is more than 200 characters wide. If you ever read a newspaper the same issue is involved when the text is formatted using columns.
The solution to the line length problem is probably neither arbitrary line break with continuation characters, nor using implicit lines continuation by enclosing some expressions inside parenthesis. It's probably to introduce intermediate variables and functions to have a code that logically breaks at less than 79 chars.
By the way you may want to stick to a still harder limit. I prefer 72 characters because I can allow one or two additional quoting levels inside 80 characters text mails. If not doing so the identiation will break at first quote.