也许在Python编码风格指导(PEP8)中最有争议的一部分要数每行代码不超过80个字符的限制。没错，实际上是79个字符，但我使用80个字符，这个大概数，它是给程序员的一个参考值。 
古老的VT100终端 现在很多软件公司采用的编码规范基本是PEP8，但每行80个字符的限制除外。GitHub上的项目，大多数都遵循PEP8规范(这一点似乎达到了高度的统一)，但遵守80个字符限制的很少。在一些有明确规定的规范标准中，这个限制可能会增加(100或120)，甚至完全删除。这样做常长见的理由是：我们已经不是使用VT100终端编程的年代了，我们有了更大，更高分辨率的屏幕。这是事实，但我发现，在Python编码中采用这个80个字符的规范，配合空格的使用，这会让我们的代码更急凑，更可读。 有一点你可以看出，在自然情况下，Python语句的长度一般会占大概35-60个字符(不包括缩进)。更长的语句很少见。如果突然有一个句子比其它的要长很多，会显得很突兀，不好看。同样，使用强制性的空格来增加行宽能够从视觉上帮助你优化减少嵌套循环的层数，一般的建议是重构代码不要让缩进多于4层。 例如，把下面这个： 01 | def search(directory, file_pattern, path_match, |
02 | follow_symlinks=True, output=True, colored=True): |
05 | pattern = re.compile(file_pattern) |
09 | for root, sub_folders, files in os.walk(directory, followlinks=follow_symlinks): |
15 | for filename in files + sub_folders: |
16 | full_filename = os.path.join(root, filename) |
17 | to_match = full_filename if path_match else filename |
18 | match = re.search(pattern, to_match) |
22 | smatch =[to_match[:match.start()], to_match[match.start(): match.end()], to_match[match.end():]] |
25 | smatch[0] = os.path.join(root, smatch[0]) |
28 | print_match(smatch, colored) |
30 | results.append(full_filename) |
和这个比较： 01 | def search(directory, file_pattern, path_match, |
02 | follow_symlinks=True, output=True, colored=True): |
06 | pattern = re.compile(file_pattern) |
10 | for root, sub_folders, files in os.walk(directory, |
11 | followlinks=follow_symlinks): |
17 | for filename in files + sub_folders: |
18 | full_filename = os.path.join(root, filename) |
19 | to_match = full_filename if path_match else filename |
20 | match = re.search(pattern, to_match) |
24 | smatch = [to_match[:match.start()], |
25 | to_match[match.start(): match.end()], |
26 | to_match[match.end():]] |
29 | smatch[0] = os.path.join(root, smatch[0]) |
32 | print_match(smatch, colored) |
34 | results.append(full_filename) |
在第一段代码里会出现滚动条，但即使是没有出现滚动条，这代码表现的也不美观，视觉上不平衡。第二段代码看起来更好，更容易阅读。 另 外重要的一点是，我可以在屏幕上显示更多的东西。很多时候我们都需要屏幕上同时看一个文件的多个地方，或多个文件的内容。我喜欢的实现这个目的的方法是让 它们按列排列。如果整个文件有80个宽度的限制，代码会有一个很好的呈现，我不用担心代码在编辑器里会否自动折行，不用去麻烦配置编辑器。如果我需要使用 vim在命令行里快速编辑一个文件，就不用担心文件的宽度。能专注于代码。 
唯一有问题的是使用Django的时候。当使用Django框架，你需要使用很多像这样的调用： ThisIsMyModel.objects.find(field1=value1, field2=value2).count()
在有缩进的代码里，一个‘最小’的model函数调用都会让你没有多少剩余空间…但我仍然坚持相同的原则，尽量让代码表现的清晰可读，但这比起其它Python代码来要难的多。 所以，即使这个限制最初的愿望已经和现在完全不符合，我仍然觉得这个限制能帮助我写出更可读紧凑的代码。我是一个要求“可读性”的狂热分子，我甚至认为代码的可读性是一个最重要的需要考虑的方面，程序员应该在任何时候都铭记这一点。 | 
