Python 代碼一致性的重要性

本文是 Python 之禪特殊系列的一部分,重點是第十二、十三和十四原則:模糊性和明確性的作用。

最小驚喜原則是設計用戶界面時的一個 準則。它是說,當用戶執行某項操作時,程序執行的事情應該使用戶儘量少地感到意外。這和孩子們喜歡一遍又一遍地讀同一本書的原因是一樣的:沒有什麼比能夠預測並讓預測成真更讓人欣慰的了。

在開發 ABC 語言(Python 的靈感來源)的過程中,一個重要的見解是,編程設計是用戶界面,需要使用與 UI 設計者相同的工具來設計。值得慶幸的是,從那以後,越來越多的語言採用了 UI 設計中的可承受性affordance和人體工程學ergonomics的概念,即使它們的應用並不嚴格。

這就引出了 Python 之禪 中的三個原則。

面對歧義,要拒絕猜測的誘惑In the face of ambiguity, refuse the temptation to guess

1 + "1" 的結果應該是什麼? "11" 和 2 都是猜測。這種表達方式是歧義的:無論如何做都會讓一些人感到驚訝。

一些語言選擇猜測。在 JavaScript 中,結果爲 "11"。在 Perl 中,結果爲 2。在 C 語言中,結果自然是空字符串。面對歧義,JavaScript、Perl 和 C 都在猜測。

在 Python 中,這會引發 TypeError:這不是能忽略的錯誤。捕獲 TypeError 是非典型的:它通常將終止程序或至少終止當前任務(例如,在大多數 Web 框架中,它將終止對當前請求的處理)。

Python 拒絕猜測 1 + "1" 的含義。程序員必須以明確的意圖編寫代碼:1 + int("1"),即 2;或者 str(1) + "1",即 "11";或 "1"[1:],這將是一個空字符串。通過拒絕猜測,Python 使程序更具可預測性。

儘量找一種,最好是唯一一種明顯的解決方案There should be one—and preferably only one—obvious way to do it

預測也會出現偏差。給定一個任務,你能預知要實現該任務的代碼嗎?當然,不可能完美地預測。畢竟,編程是一項具有創造性的任務。

但是,不必有意提供多種冗餘方式來實現同一目標。從某種意義上說,某些解決方案或許 “更好” 或 “更 Python 化Pythonic”。

對 Python 美學欣賞部分是因爲,可以就哪種解決方案更好進行健康的辯論。甚至可以持不同觀點而繼續編程。甚至爲使其達成一致,接受不同意的觀點也是可以的。但在這一切之下,必須有一種這樣的認識,即正確的解決方案終將會出現。我們必須希望,通過商定實現目標的最佳方法,而最終達成真正的一致。

雖然這種方式一開始可能並不明顯(除非你是荷蘭人)Although that way may not be obvious at first (unless you're Dutch)

這是一個重要的警告:首先,實現任務的最佳方法往往明顯。觀念在不斷髮展。Python 也在進化。逐塊讀取文件的最好方法,可能要等到 Python 3.8 時使用 walrus 運算符:=)。

逐塊讀取文件這樣常見的任務,在 Python 存在近 30年 的歷史中並沒有 “唯一的最佳方法”。

當我在 1998 年從 Python 1.5.2 開始使用 Python 時,沒有一種逐行讀取文件的最佳方法。多年來,知道字典中是否有某個鍵的最佳方法是使用關鍵字 .haskey,直到 in 操作符出現才發生改變。

只是要意識到找到實現目標的一種(也是唯一一種)方法可能需要 30 年的時間來嘗試其它方法,Python 纔可以不斷尋找這些方法。這種歷史觀認爲,爲了做一件事用上 30 年是可以接受的,但對於美國這個存在僅 200 多年的國家來說,人們常常會感到不習慣。

從 Python 之禪的這一部分來看,荷蘭人,無論是 Python 的創造者 Guido van Rossum 還是著名的計算機科學家 Edsger W. Dijkstra,他們的世界觀是不同的。要理解這一部分,某種程度的歐洲人對時間的感受是必不可少的。


via: https://opensource.com/article/19/12/zen-python-consistency

作者:Moshe Zadka 選題:lujun9972 譯者:stevenzdg988 校對:wxy

本文由 LCTT 原創編譯,Linux中國 榮譽推出



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章