为何编码规范每行代码不超过80个字符是合理的
2018-03-28 13:39
253 查看
转载地址:https://linux.cn/article-1193-1.html也许在Python编码风格指导(PEP8)中最有争议的一部分要数每行代码不超过80个字符的限制。没错,实际上是79个字符,但我使用80个字符,这个大概数,它是给程序员的一个参考值。
编辑器 也许在Python编码风格指导(PEP8)中最有争议的一部分要数每行代码不超过80个字符的限制。没错,实际上是79个字符,但我使用80个字符,这个大概数,它是给程序员的一个参考值。
古老的VT100终端现在很多软件公司采用的编码规范基本是PEP8,但每行80个字符的限制除外。GitHub上的项目,大多数都遵循PEP8规范(这一点似乎达到了高度的统一),但遵守80个字符限制的很少。在一些有明确规定的规范标准中,这个限制可能会增加(100或120),甚至完全删除。这样做常长见的理由是:我们已经不是使用VT100终端编程的年代了,我们有了更大,更高分辨率的屏幕。这是事实,但我发现,在Python编码中采用这个80个字符的规范,配合空格的使用,这会让我们的代码更急凑,更可读。有一点你可以看出,在自然情况下,Python语句的长度一般会占大概35-60个字符(不包括缩进)。更长的语句很少见。如果突然有一个句子比其它的要长很多,会显得很突兀,不好看。同样,使用强制性的空格来增加行宽能够从视觉上帮助你优化减少嵌套循环的层数,一般的建议是重构代码不要让缩进多于4层。例如,把下面这个:
竖行排列显示唯一有问题的是使用Django的时候。当使用Django框架,你需要使用很多像这样的调用:ThisIsMyModel.objects.find(field1=value1, field2=value2).count()在有缩进的代码里,一个‘最小’的model函数调用都会让你没有多少剩余空间…但我仍然坚持相同的原则,尽量让代码表现的清晰可读,但这比起其它Python代码来要难的多。所以,即使这个限制最初的愿望已经和现在完全不符合,我仍然觉得这个限制能帮助我写出更可读紧凑的代码。我是一个要求“可读性”的狂热分子,我甚至认为代码的可读性是一个最重要的需要考虑的方面,程序员应该在任何时候都铭记这一点。 [英文原文:80 chars per line is great ]VIA http://www.aqee.net/80-chars-per-line-is-great/
编辑器 也许在Python编码风格指导(PEP8)中最有争议的一部分要数每行代码不超过80个字符的限制。没错,实际上是79个字符,但我使用80个字符,这个大概数,它是给程序员的一个参考值。
古老的VT100终端现在很多软件公司采用的编码规范基本是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代码来要难的多。所以,即使这个限制最初的愿望已经和现在完全不符合,我仍然觉得这个限制能帮助我写出更可读紧凑的代码。我是一个要求“可读性”的狂热分子,我甚至认为代码的可读性是一个最重要的需要考虑的方面,程序员应该在任何时候都铭记这一点。 [英文原文:80 chars per line is great ]VIA http://www.aqee.net/80-chars-per-line-is-great/
相关文章推荐
- 为何编码规范每行代码不超过80个字符是合理的
- 为什么编码规范里要求每行代码不超过80个字符的限制是合理的
- 代码的缩进、方法的命名、文字常量、成员变量、一行不超过80个字符
- linux编码规范 - 代码中的标记
- SecureCRT的时候超过80个字符就会缩写成$的解决方法,长命令,出现串行问题
- Java编码规范,让你的代码赏心悦目--有意义的命名
- Java编码规范,让你的代码赏心悦目--函数
- Java编码规范,让你的代码赏心悦目--格式
- Java编码规范,让你的代码赏心悦目--对象和数据结构
- 技术总结--android篇(三)--代码规格和编码规范
- java在命令行中编译代码出现 错误: 编码GBK的不可映射字符
- Java编码规范,让你的代码赏心悦目--错误处理
- Java/Android 编码规范,从第一行代码开始
- 团队项目开发"编码规范"之二:代码外观
- PHP团队 编码规范 & 代码样式风格规范
- Android 编码规范 | 代码风格指南
- java主类结构、基本数据类型、 变量与常量、运算符、数据类型转换、代码注释与编码规范
- Java编码规范,让你的代码赏心悦目--有意义的命名
- Java编码规范,让你的代码赏心悦目--函数
- Java编码规范,让你的代码赏心悦目--格式