為什么編碼規范里要求每行代碼不超過80個字符的限制是合理的

　　也許在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代碼來要難的多。 　　所以，即使這個限制最初的愿望已經和現在完全不符合，我仍然覺得這個限制能幫助我寫出更可讀緊湊的代碼。我是一個要求“可讀性”的狂熱分子，我甚至認為代碼的可讀性是一個最重要的需要考慮的方面，程序員應該在任何時候都銘記這一點

原文轉自：http://www.kuqin.com/software-engineer/20130409/334106.html