這篇文章主要介紹“python中GitHub使用準則有哪些”，在日常操作中，相信很多人在python中GitHub使用準則有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”python中GitHub使用準則有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

創(chuàng)新互聯成立十載來，這條路我們正越走越好，積累了技術與客戶資源，形成了良好的口碑。為客戶提供成都網站制作、成都網站設計、網站策劃、網頁設計、國際域名空間、網絡營銷、VI設計、網站改版、漏洞修補等服務。網站是否美觀、功能強大、用戶體驗好、性價比高、打開快等等，這些對于網站建設都非常重要，創(chuàng)新互聯通過對建站技術性的掌握、對創(chuàng)意設計的研究為客戶提供一站式互聯網解決方案，攜手廣大客戶，共同發(fā)展進步。

第一條：打字越少越好

如果我們鍵入的東西越少，那么就有越多的時間去思考代碼邏輯等問題。如下所示，「Good」表示遵循該規(guī)則的示例，Bad 表示沒遵循該規(guī)則的示例。

第二條：變量/函數混合命名風格

我們需要混合命名方法與變量，這樣才能體現命名的多樣性。

第三條：不要寫注釋

反正代碼都看得懂，為什么要寫注釋?或者說，反正沒人看我的代碼，為什么要寫注釋?

第四條：使用母語寫注釋

如果你違反了第三條規(guī)則，那么至少寫注釋需要用你的母語或者其它語言。如果你的母語是英語，那么你也算違反了這條規(guī)則。既然編程語言絕大多數都是用英文，那么為什么不用其它語言注釋一下?

第五條：盡可能混合不同的格式

同樣，為了代碼的多樣性，我們需要盡可能混合不同的格式，例如單引號或雙引號。如果它們的語義相同，那就應該混用。

第六條：盡可能把代碼寫成一行

如果一系列參數與方法都是一起實現的，那么代碼也要寫在一起。

第七條：發(fā)現錯誤要保持靜默

當你發(fā)現某些錯誤時，其他人不需要了解它，因此不需要打印出日志或 Traceback。

第八條：廣泛使用全局變量

使用全局變量，是面向「全球化」不可或缺的部分。

第九條：構建備用變量

以防萬一，我們需要創(chuàng)建一些備用變量，在需要時隨時調用它們。

第十條：Type 使用需謹慎

一般不要指定變量類型或者經常做類型檢查，無類型才是最好的類型。

第十一條：準備「Plan B」

你需要準備一些運行不到的代碼(unreachable code)，它們可以作為你的「Plan B」。

第十二條：嵌套的三角法則

如果代碼有一些嵌套結構，或者說縮進空行的結構，三角法則是最漂亮的。

第十三條：混合縮進

我們需要避免采用縮進，因為縮進會使復雜代碼在編輯器中占用更多的空間。如果一定要采用縮進，那么就使用混合縮進策略。當然，這種策略在 Python  中是行不通的，因為它靠縮進來確定代碼結構。

第十四條：不要鎖住依賴項

每一次要安裝新庫時，更新已有的依賴項。為什么要維持之前的版本呢，我們需要時刻保持最新的第三方代碼庫。

第十五條：長函數比短函數好

不要將程序整體邏輯分割為一些代碼塊，要是 IDE  突然不行了，它找不到必要的文件或函數怎么辦。因此把代碼寫在一個主體函數中，并且不再維護額外的函數導入或代碼文件，那么這樣的方法是最穩(wěn)定的。

單個文件一萬行代碼是沒問題的，單個函數一千行代碼也是沒問題的。

第十六條：代碼不需要做特定測試

這些測試通常是重復且無意義的工作。

第十七條：盡量避免重復代碼

按你的想法寫代碼，尤其是在小團隊中，畢竟這是「自由」準則。

第十八條：構建新項目不需要 README 文檔

在項目前期，我們可以暫時保持這種狀態(tài)。

第十九條：保存不必要的代碼

在寫代碼的過程中，經常會產生很多測試代碼。這些代碼也是非常重要的資料，因此不能刪除掉，最多只能注釋掉。

到此，關于“python中GitHub使用準則有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯網站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
分享文章：python中GitHub使用準則有哪些
地址分享：http://weahome.cn/article/gpdhcg.html