編碼風格不是編碼規範

2021-07-15 23:45:22 字數 1370 閱讀 3450

我並不認為程式設計師是乙個情緒特別豐富的群體。但有一些事情卻能很容易刺激程式設計師的神經,那就是**格式和布局。如果看到乙個函式的括弧在同一行上沒有閉合,我的眼睛會噴血。如果看到有人沒有恰好的在兩個函式間留一空行,我的小腿會抽筋。但重點在這裡——除非是在家裡開發自己的業餘愛好軟體,我的這些個人喜好其實是無關緊要的。同樣,作為乙個團隊中的一員,你的個人程式設計喜好也應該放到一邊。

編碼風格很容易會和編碼規範混為一談,因為這兩個詞經常會被人換著使用。我認為,編碼規範同時包括了編碼風格和其它規範,不僅僅指**格式。例如,像「返回成功/失敗的函式應該用乙個整數作為返回值」,這樣的規則不屬於編碼風格。在這篇文章中,編碼風格簡單的指乙個描述如何格式化**的說明。編碼風格中的規則通常會涉及到下面這些主題:

編碼風格都是為特定的程式語言制定的,可以把它們看作「我們共同的約定」。如果在你的公司裡,在你在時,在這些事情正在制定完成,你可以提出你的喜好,那你是幸運。但通常情況是,一種編碼風格在其生命期裡看著無數的程式設計師來了又走了。在我的眼裡,遵守編碼風格有下面三個主要好處:

今天由這個程式設計師實現的軟體,明天可能需要另外乙個程式設計師維護。如果所有**中大家使用同一種編碼風格,這另外乙個程式設計師快速的掃一眼陌生的**,就能根據大家約定的程式設計習慣,推斷出**的作用。如果編碼風格中指明常量應該全用大寫字母表示,那麼,當看到乙個全是大寫字母的變數時,你就能推斷出它是常量。同樣的,如果編碼風格中規定包的引入要有順序,那你立刻就能知道去**找這些包。這使得**很容易維護。

**集體所有制意味著全體程式設計師要負責所有**。集體所有制的作用很大,它能有效的增大巴士因子——乙個專案能承受多少個程式設計師被車撞了而不影響專案的正常進行。在整個**庫中堅持延用一種常用的編碼風格,所以程式設計師都能更容易的理解、維護。

相反,如果在乙個大型的軟體專案中,每個程式設計師都使用自己的編碼風格,最終會引起一場維護版圖的戰爭,就像動物世界裡我們的這些朋友:

氣味記號(也稱噴灑尿液或領土記號)是動物標記自己領土範圍的一種行為。通常是通過留下具有強烈氣味的物質來完成,很多時候是通過在領土中突出的物體上小便。-維基百科

個人編碼風格就像是狗撒尿,留下自己的勢力記號。他們在**中留下自己的符號,在程式設計師之間創造壁壘。

你不需要喜歡這種編碼風格。如果你不喜歡裡面的某條規定,那就罵幾句這個文件,只向文件發脾氣,就像人類遷怒於上帝。然後還是按照約定做事。這樣做更具有建設性,比無休無止的吵論這些不重要的事情好的多。

有了一套編碼風格並不一定會給你帶來好處——除非大家都遵守。有些時候,你並不一定需要手工去調整**。很多的程式程式設計器,例如eclipse,能配置幫你格式化**,使其符合編碼風格。即使你的編輯器沒有這種功能,很多其它工具也能夠自動按照某種風格格式化乙個檔案。在我們的團隊中,我們使用 indent 和 uncrustify 工具。我還聽說過一些其它好東西,比如resharper。那些不能被自動實施的規則,例如命名習慣,可以在**審查的過程中落實。

C 編碼風格與規範

命名應該含義明確,不要為了節省空間使用縮寫。int n bad 無明確含義的單字母名稱 string cstmrname bad 非約定俗成的縮寫 int width,height ok 含義明確 int numcolors ok num屬於約定俗成的縮寫 for int i 0 i 100 i o...

PSR 2 編碼風格規範

必須 使用 4 個空格符而不是 tab 鍵 進行縮排。每行的字元數 應該 軟性保持在 80 個之內,理論上 一定不可 多於 120 個,但 一定不可 有硬性限制。每個 namespace 命名空間宣告語句和 use 宣告語句塊後面,必須 插入乙個空白行。類的開始花括號 也 必須 寫在函式主體後自成一...

python風格編碼 Python編碼風格 概述

對於 python 而言,pep 8 已成為大多數專案遵循的風格指南 它給出了乙個高度可讀,視覺友好的編碼風格。每個 python 開發者應該閱讀一下 這裡是為你提取出來的最重要的要點 from pymongo import mongoclient import gridfs,datetime,ti...