1、代碼風格

剛開始學的時候就要注意編碼規範了，因此整理了一下，以便養成一個編碼好習慣。否則之後真的很差改。

代碼被讀的次數遠大於被寫的次數。

做爲一名程序員（使用任何語言），你能作出最重要的事情之一就是寫出易於閱讀的代碼。

原則

在開始討論Python社區所採用的具體標準或是由其餘人推薦的建議以前，考慮一些整體原則很是重要。

請記住，可讀性標準的目標是提高可讀性。這些規則存在的目的就是爲了幫助人讀寫代碼。

一、假定你的代碼須要維護

你很容易相信在某時本身所完成的工做在將來不須要添加內容或對其進行維護。在編寫代碼時，你很難預料到將來的需求，而且會低估本身引入Bug的傾向。然而，所編寫的代碼不多不須要修改一直存在的。

若是你假設本身的編寫的代碼會‘一勞永逸’，以後無需再閱讀、調試或修補，那麼就會很是容易陷入忽視其餘可讀性原則的境地。這僅僅是由於你相信‘此次你編寫的代碼不會須要修改，因此不用花費時間編寫可讀性高的代碼’。

所以，對本身所寫代碼不需維護的直覺不相信纔是上策。穩賺不賠的辦法是賭本身將會再次看到本身編寫的代碼。即便你不維護，別人也會維護。

二、保持一致性

一致性的兩個方面分別爲：內部一致性和外部一致性。

不管是從代碼風格和代碼結構層面來說，代碼都要儘量的保持內部一致性。不管是哪一種格式化規則，代碼風格都要貫穿項目保持一致性。代碼結構的一致性也就是將一樣類型的代碼放到一塊兒，這樣項目容易把控。

代碼還應該保持外部一致性。項目與代碼的結構應與其餘人保持一致，若是一個新的開發人員打開你的項目，你不該該讓他的反應是：「我歷來沒看過像這樣的東西」。社區指導原則很重要，由於這些原則是開發人員加入到你的項目所指望的原則。相似的，請認真看待在使用特定框架時完成任務以及組織代碼時所採用的標準。

三、考慮對象在程序中存在的方式，尤爲是那些帶有數據的對象

存在論（Ontology）的主要意思是「關於存在的研究」。在哲學的上（在該領域這個詞很經常使用），存在論是關於現實與存在本質的研究，是形而上學的子集。

而對於寫軟件程序來講，存在論指的是關注不一樣的「事物」在應用程序中的存在方式。如何在數據庫中表示概念？或是用類結構來表示？

這類問題最終影響你編寫或組織代碼的方式。是否使用繼承或組合來組織兩個類之間的關係？使用數據庫的哪一個表來完成這項功能或是這個列屬於那個表？

這些建議最終歸結爲「在編寫代碼以前先思考‘’，尤爲是思考程序但願實現的目標，以及應用程序之間如何交互，應用程序是一個對象與數據交互的世界。那麼，它們之間的協做須要遵循的規則是什麼？

四、不要作重複工做

在編寫代碼時，請考慮隨着時間的推移重複使用的值將會變動的狀況。該值是否被用於多個模塊或函數中？若是有必要修改，須要花費多大的代價？

一樣的原則用於函數。在應用程序中你是否擁有大量的重複代碼？若是這些重複代碼行數較多，能夠先將其抽象到一個函數中去，若是出現修改的必要，則更容易管理。

另外一方面，對於這個原則不要過猶不及。並非全部的值都須要在某塊中定義常量（這樣有損可讀性和維護性）。請明智判斷，不斷問本身這樣的問題：「若是須要變動該代碼，在全部位置進行變動所須要的成本是多少？」。

五、讓註釋講故事

代碼時一個故事。在用戶與程序的交互中，從開始到結束，代碼時所發生故事的說明。程序從某一點開始（可能帶有一點輸入），沿着一系列「選擇本身的冒險故事」步驟到達終點，並結束（極可能帶一些輸出結果）

採用的註釋風格能夠是在每某一些行代碼以前就添加一段註釋，用於解釋代碼的功能。若是代碼時一個故事，那麼註釋就是故事的解釋與旁白。

若是敘事型註釋作的好，讀者就能夠經過閱讀註釋瞭解故事，從而解析代碼（例如，當嘗試解決問題或維護代碼時），而後就能夠從零開始快速瞭解所需維護的代碼，這樣就能夠專一於代碼自己所表示的意義。

敘事型註釋還能夠幫助解釋代碼的意圖。它能夠回答這樣的問題：「這段代碼的編寫者須要完成的目的是什麼？」，偶爾，還能夠幫助回答問題：「爲何以這種方式完成工做」？這些問題是你閱讀代碼時很天然就會問的問題爲這些問題提供答案有助於瞭解這些內容。

所以，註釋用於解釋代碼中不顯而易見或複雜部分的原理。若是使用了有點複雜的算法，請考慮將指向解釋模型文章的連接以及其餘使用實例加入註釋。

六、奧卡姆剃刀原則

通俗來說，編寫可讀性代碼最重要的原則就是奧卡姆剃刀原則：最簡單的解決方案一般是最好的。在他的「Python之禪」的博文頁面中（http://www.python.org/dev/peps/pep-0020/），集合了一些編程格言（例如在Python的控制檯中輸入"import this"就能夠看到這篇博文），Tim peters 也包括相似下面格言：「若是你沒法想別人描述你的方案，那確定不是一個好方案」。

上述原則在代碼如何運行與代碼外觀的層次上都生效。當提到代碼運行時，簡單的系統更加容易維護，實現的簡單化意味着更少引入複雜的Bug，那些維護你代碼的人（包括你本身），更容易憑直覺來理解代碼所表示的含義，並在不採坑的狀況下爲程序增長代碼。

至於代碼的外觀，請記住，儘量是的閱讀代碼就好像是在瞭解代碼所作的工做，而不是爲了解析詞彙。詞彙是手段，而故事纔是最終目的。寫一條‘不要使用三元運算符‘’很容易，然而僅遵照這些規則（雖然有價值）並非代碼明細的充分條件。應該重點關注以儘量簡潔的方式編寫和組織代碼。

標準

Python社區大部分遵照所謂的 PEP 8（http://www.python.org/dev/peps/pep-0008）指導原則，PEP 8由Guido van Rossum(Python之父)編寫並被大多數主流Python項目所採用，其中包括Python的標準庫。

PEP 8的廣泛性是其強大的緣由之一。該標準被大多數社區項目所採用，所以你能夠預計你遇到的大多數Python代碼都遵照該標準。當以這種方式編寫代碼時，代碼會更容易閱讀，也更容易編寫。

一、簡潔的規則

• PEP 8的大多數指導原則都很簡單明瞭，部分重點以下
• 使用4個空格縮進，而不是製表符（Tab鍵）
• 變量應該使用下劃線鏈接，而不是駝峯式命名規則（使用my_var 而不是myVal）。類名稱以字母開頭就是駝峯式命名風格（例如：MyClass）
• 若是一個變量的用處是：「僅內部使用」，那麼在變量名稱以前加上下劃線。
• 在運算符先後加上單空格（例如，x + y，不是x+y），也包括賦值運算符（z = 3,不是z=3）。只有在關鍵字參數的狀況下該規則不適用，在這種狀況下，空格能夠省略。
• 在列表和字典省略沒必要要的空白（例如：[1,2,3,4]而不是[ 1,2,3,4 ]）。

二、文檔字符串

請記住在Python中，若是在一個函數或類中的第一個語句是字符串，該字符串會自動賦值給一個特殊的__doc__變量，該變量在條用Help（和一些其餘的類），時會使用。

PEP 8規定文檔字符串的是必須的

‘’‘Do  X , Y, and Z, then return the result. ’‘’

若是文檔字符串是一行，那麼須要在類或函數體以前加空行。若是文檔是多行，則將結束的雙引號單獨的放一行。

三、空行

空行用於邏輯分塊。

PEP 8規定「最高級」的類和函數定義之間有兩個空行。

class A(object):
    pass


class B(object):
    pass 

 

除了最高級以外，PEP 8還規定類和函數的定義以一個空行分隔。

class A(object):
    def foo(self):
        pass

    def bar(self):
        pass

 

在函數或其餘的代碼塊中使用單空行分隔邏輯段是合理的。請考慮在邏輯段以前使用註釋解釋代碼塊的做用。

四、導入

Python容許絕對路徑導入和相對路徑導入。在Python2中，解釋器會嘗試相對導入，若是找不到路徑，而後在嘗試絕對導入。

在Python3中，使用特殊語法來標記相對導入——以（.）開頭——‘正常’的導入方式只會嘗試相對路徑。Python3的語法在Python2.6之後的版本可使用，另外，可使用from_future_import absolute_import關閉隱式的相對導入。

 若是可能，儘可能使用絕對路徑導入。若是必須使用相對路徑，請使用顯示的導入風格。若是你是Python2.六、Python2.7編碼，請考慮選擇Python3的顯示風格。

當導入模塊時，每一個模塊應該單獨佔一行。

import os
import sys

 

然而若是從一個模塊導入多個名稱，能夠將這些名稱分組到一行中。

from datetime import data, datetime, timedelta

 

此外，雖然PEP 8並無強制要求，但能夠考慮以包的形式將導入分組。對於每一組，按照字母表順序排序。

另外，在導入時，請不要忘了使用as關鍵字給導入的內容起別名。

from foo.bar import really_long_name as name

 

這使得你能夠簡化被頻繁使用的長名或不規範命名的名稱。

五、變量

如前所述，變量名稱使用下劃線鏈接，而不要使用駝峯式代碼風格，此外，起一個具備描述性的名稱一樣重要。

一般狀況下，使用很是短的變量名稱並不合適，雖然某些狀況下這樣作也能接受。如：(for k , v in a）。

應避免函數的命名與Python語言中經常使用名稱重複，就算是解釋器容許也不能用。不管在任何狀況下，都不要命名某個對象爲sum或print。相似的，應避免用list或dict之類的名稱。

若是必需要命名一個與Python關鍵字同名的的變量，慣例是在變量名以後加下劃線；相比修更名稱的編寫來講，這樣更加可行。例如你想使用class，應該是class_。

六、註釋

註釋的編寫應該使用英語的完整語句，註釋塊應該放在相關代碼以前。首字母大寫，拼寫正確。

同時要保證註釋更新。若是代碼變動，註釋也要變。

模塊可能包含一個註釋頭，一般有版本控制系統生成，其中包括文件版本的信息。這使得查看文件是否被修改變得 容易，尤爲是將模塊分發給別人使用時。

七、行長度

PEP8 要求行長度不超過79個字符，文檔字符串不超過72個字符。

當行過長時，使用圓括號封裝是最佳方式，也可使用‘\’字符。

大多時候，一年之後閱讀你代碼的是你本身，你的記憶力並不像一開始寫代碼這麼好，良好的編碼風格，會增長你代碼的可讀性。