也许在Python编码风格指导(PEP8)中最有争议的一部分要数每行代码不超过80个字符的限制。没错,实际上是79个字符,但我使用80个字符,这个大概数,它是给程序员的一个参考值。

也许在Python编码风格指导(PEP8)中最有争议的一部分要数每行代码不超过80个字符的限制。没错,实际上是79个字符,但我使用80个字符,这个大概数,它是给程序员的一个参考值。
现在很多软件公司采用的编码规范基本是PEP8,但每行80个字符的限制除外。GitHub上的项目,大多数都遵循PEP8规范(这一点似乎达到了高度的统一),但遵守80个字符限制的很少。在一些有明确规定的规范标准中,这个限制可能会增加(100或120),甚至完全删除。这样做常长见的理由是:我们已经不是使用VT100终端编程的年代了,我们有了更大,更高分辨率的屏幕。这是事实,但我发现,在Python编码中采用这个80个字符的规范,配合空格的使用,这会让我们的代码更急凑,更可读。
有一点你可以看出,在自然情况下,Python语句的长度一般会占大概35-60个字符(不包括缩进)。更长的语句很少见。如果突然有一个句子比其它的要长很多,会显得很突兀,不好看。同样,使用强制性的空格来增加行宽能够从视觉上帮助你优化减少嵌套循环的层数,一般的建议是重构代码不要让缩进多于4层。
例如,把下面这个:
def search(directory, file_pattern, path_match, follow_symlinks=True, output=True, colored=True): ''' Search the files matching the pattern. The files will be returned, and can be optionally printed ''' pattern = re.compile(file_pattern) results = [] for root, sub_folders, files in os.walk(directory, followlinks=follow_symlinks): # Ignore hidden directories if '/.' in root: continue # Search in files and subfolders for filename in files + sub_folders: full_filename = os.path.join(root, filename) to_match = full_filename if path_match else filename match = re.search(pattern, to_match) if match: # Split the match to be able to colorize it # prefix, matched_pattern, sufix smatch = [to_match[:match.start()], to_match[match.start(): match.end()], to_match[match.end():]] if not path_match: # Add the fullpath to the prefix smatch[0] = os.path.join(root, smatch[0]) if output: print_match(smatch, colored) results.append(full_filename) return results
和这个比较:
def search(directory, file_pattern, path_match, follow_symlinks=True, output=True, colored=True): ''' Search the files matching the pattern. The files will be returned, and can be optionally printed ''' pattern = re.compile(file_pattern) results = [] for root, sub_folders, files in os.walk(directory, followlinks=follow_symlinks): # Ignore hidden directories if '/.' in root: continue # Search in files and subfolders for filename in files + sub_folders: full_filename = os.path.join(root, filename) to_match = full_filename if path_match else filename match = re.search(pattern, to_match) if match: # Split the match to be able to colorize it # prefix, matched_pattern, sufix smatch = [to_match[:match.start()], to_match[match.start(): match.end()], to_match[match.end():]] if not path_match: # Add the fullpath to the prefix smatch[0] = os.path.join(root, smatch[0]) if output: print_match(smatch, colored) results.append(full_filename) return results
在第一段代码里会出现滚动条,但即使是没有出现滚动条,这代码表现的也不美观,视觉上不平衡。第二段代码看起来更好,更容易阅读。
另外重要的一点是,我可以在屏幕上显示更多的东西。很多时候我们都需要屏幕上同时看一个文件的多个地方,或多个文件的内容。我喜欢的实现这个目的的方法是让它们按列排列。如果整个文件有80个宽度的限制,代码会有一个很好的呈现,我不用担心代码在编辑器里会否自动折行,不用去麻烦配置编辑器。如果我需要使用vim在命令行里快速编辑一个文件,就不用担心文件的宽度。能专注于代码。
唯一有问题的是使用Django的时候。当使用Django框架,你需要使用很多像这样的调用:
ThisIsMyModel.objects.find(field1=value1, field2=value2).count()
在有缩进的代码里,一个‘最小’的model函数调用都会让你没有多少剩余空间…但我仍然坚持相同的原则,尽量让代码表现的清晰可读,但这比起其它Python代码来要难的多。
所以,即使这个限制最初的愿望已经和现在完全不符合,我仍然觉得这个限制能帮助我写出更可读紧凑的代码。我是一个要求“可读性”的狂热分子,我甚至认为代码的可读性是一个最重要的需要考虑的方面,程序员应该在任何时候都铭记这一点。
objc碰上80列限制简直泪流满面
也许对于业余选手,选择一个大的显示器更方便一些……
咦,开头的代码片段是clojure
太多折行反而不好读,我觉得可以放宽到120或160,现在22+宽屏照样一行能显示得下。当然你如果非要用小笔记本写代码,也没折。
我也觉得是这样
PEP8,有空学学
字符串没有这么容易处理的,你不能随便帮人家字符串空行啊
如果靠拼接 则显得不直观 看上去是有换行的但其实不是 容易造成误解
我觉得80字符的限制在现在确实过时了
Objective C的代码风格追求变量名函数名完整易懂,所以都长的不得了……
不清楚python,不过C&C++里显然这个限制是过时的
没必要限制这么死,你还在用VT100吗?适合主流显示器并有利于颈椎健康即可
没行代码都很长很长,然后还那么多的if else一起嵌套,这样的c,c++代码我见的很多,真是是个悲剧!