为何编码规范每行代码不超过80个字符是合理的

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

 

编辑器

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

[[69723]]

古老的VT100终端

现在很多软件公司采用的编码规范基本是PEP8,但每行80个字符的限制除外。GitHub上的项目,大多数都遵循PEP8规范(这一点似乎达到了高度的统一),但遵守80个字符限制的很少。在一些有明确规定的规范标准中,这个限制可能会增加(100或120),甚至完全删除。这样做常长见的理由是:我们已经不是使用VT100终端编程的年代了,我们有了更大,更高分辨率的屏幕。这是事实,但我发现,在Python编码中采用这个80个字符的规范,配合空格的使用,这会让我们的代码更急凑,更可读。

有一点你可以看出,在自然情况下,Python语句的长度一般会占大概35-60个字符(不包括缩进)。更长的语句很少见。如果突然有一个句子比其它的要长很多,会显得很突兀,不好看。同样,使用强制性的空格来增加行宽能够从视觉上帮助你优化减少嵌套循环的层数,一般的建议是重构代码不要让缩进多于4层。

例如,把下面这个:

  1. def search(directory, file_pattern, path_match,  
  2.            follow_symlinks=True, output=True, colored=True):  
  3.     ''' Search the files matching the pattern. The files will be returned, and can be optionally printed ''' 
  4.  
  5.     pattern = re.compile(file_pattern)  
  6.  
  7.     results = []  
  8.  
  9.     for root, sub_folders, files in os.walk(directory, followlinks=follow_symlinks):  
  10.         # Ignore hidden directories  
  11.         if '/.' in root:  
  12.             continue 
  13.  
  14.         # Search in files and subfolders  
  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)  
  19.             if match:  
  20.                 # Split the match to be able to colorize it  
  21.                 # prefix, matched_pattern, sufix  
  22.                 smatch = [to_match[:match.start()], to_match[match.start(): match.end()], to_match[match.end():]]  
  23.                 if not path_match:  
  24.                     # Add the fullpath to the prefix  
  25.                     smatch[0] = os.path.join(root, smatch[0])  
  26.  
  27.                 if output:  
  28.                     print_match(smatch, colored)  
  29.  
  30.                 results.append(full_filename)  
  31.  
  32.     return results 

和这个比较:

  1. def search(directory, file_pattern, path_match,  
  2.            follow_symlinks=True, output=True, colored=True):  
  3.     ''' Search the files matching the pattern.  
  4.         The files will be returned, and can be optionally printed '''  
  5.  
  6.     pattern = re.compile(file_pattern)  
  7.  
  8.     results = []  
  9.  
  10.     for root, sub_folders, files in os.walk(directory,  
  11.                                             followlinks=follow_symlinks):  
  12.         # Ignore hidden directories  
  13.         if '/.' in root:  
  14.             continue 
  15.  
  16.         # Search in files and subfolders  
  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)  
  21.             if match:  
  22.                 # Split the match to be able to colorize it  
  23.                 # prefix, matched_pattern, sufix  
  24.                 smatch = [to_match[:match.start()],  
  25.                           to_match[match.start(): match.end()],  
  26.                           to_match[match.end():]]  
  27.                 if not path_match:  
  28.                     # Add the fullpath to the prefix  
  29.                     smatch[0] = os.path.join(root, smatch[0])  
  30.  
  31.                 if output:  
  32.                     print_match(smatch, colored)  
  33.  
  34.                 results.append(full_filename)  
  35.  
  36.     return results 

在第一段代码里会出现滚动条,但即使是没有出现滚动条,这代码表现的也不美观,视觉上不平衡。第二段代码看起来更好,更容易阅读。

另外重要的一点是,我可以在屏幕上显示更多的东西。很多时候我们都需要屏幕上同时看一个文件的多个地方,或多个文件的内容。我喜欢的实现这个目的的方法是让它们按列排列。如果整个文件有80个宽度的限制,代码会有一个很好的呈现,我不用担心代码在编辑器里会否自动折行,不用去麻烦配置编辑器。如果我需要使用 vim在命令行里快速编辑一个文件,就不用担心文件的宽度。能专注于代码。

竖行排列显示

竖行排列显示

唯一有问题的是使用Django的时候。当使用Django框架,你需要使用很多像这样的调用:

  1. ThisIsMyModel.objects.find(field1=value1, field2=value2).count() 

在有缩进的代码里,一个‘最小’的model函数调用都会让你没有多少剩余空间…但我仍然坚持相同的原则,尽量让代码表现的清晰可读,但这比起其它Python代码来要难的多。

所以,即使这个限制最初的愿望已经和现在完全不符合,我仍然觉得这个限制能帮助我写出更可读紧凑的代码。我是一个要求“可读性”的狂热分子,我甚至认为代码的可读性是一个最重要的需要考虑的方面,程序员应该在任何时候都铭记这一点。

英文原文:80 chars per line is great

译文连接:http://www.aqee.net/80-chars-per-line-is-great/

责任编辑:林师授 来源: 外刊IT评论
相关推荐

2009-12-03 09:42:25

2019-12-16 09:26:05

Java设计操作系统

2024-10-07 10:00:00

Python代码编码

2023-04-25 15:46:51

Python字符串

2012-09-18 09:17:34

Java规范代码代码

2020-09-18 14:23:50

字符

2022-11-24 08:01:57

bash脚本字符串

2015-03-18 09:34:47

程序员编码规范

2015-06-04 11:32:35

2019-01-08 09:23:16

Java字符串编码

2013-07-10 10:07:51

编码规范编码

2024-04-03 09:55:21

代码Go开发

2020-06-28 14:18:23

Python代码开发

2023-10-23 12:28:45

模型研究

2023-08-15 09:00:00

人工智能破解密码

2012-01-13 09:22:28

2013-07-10 09:58:14

编码规范

2015-03-23 12:20:59

Mac版ChromeChrome崩溃

2013-04-08 10:33:54

编码编码规范

2021-06-07 23:23:44

函数代码结构化
点赞
收藏

51CTO技术栈公众号