規範的不只是個性

2022-03-29 09:59:10 字數 3138 閱讀 4320

(part1)

原諒我的思緒再一次天馬行空了,看完了部落格裡面的幾個鏈結後最先投射到腦海中的不是google,不是strict coding standards,而是2023年的奧運會的足球決賽。這場決賽過後,當時我所以為的毫無懸念的冠軍--「巴西隊」意外地輸掉了這場比賽,當然,也許「意外」這個詞只是對我而言的,相對於老牌的球迷們而言,群星璀璨的巴西隊已經三度屈居亞軍了。也是從那個時候起,十幾歲的我的心裡有了這樣的乙個朦朧的意識,那就是強強聯手並不一定等於最優。

今天看了這三篇關於程式設計規範的文章,當年的思緒又公升騰起來,其實思想這種東西吧就必須經過反芻才能純化出完全的營養。現在回味文章中的想法其實也是在暗示**界的個性選手們,或者說是喜歡張揚個人風格的精英們**規範所規範的不只是個性,更是軟體的誕生和成長的歷程,從思想的角度來講,它規範的是程式設計師們的大局觀和集體意識,或者說是一種社會性的修為和素養。

接下來要說的就是我個人對一些關於**規範觀點的看法:

這個觀點滿是鼠目寸光的浮躁心理和無理取鬧的暴民心態。這樣說是因為我認為程式設計師書寫**的過程就像是翻譯家翻譯著作一樣,只不過程式設計師的工作不是one human language to another human language,而是human language to machine language。而且兩者有乙個非常重要的區別就是翻譯家可以乙個人十年磨一劍,留下如椽巨筆,但是當下的社會卻不太允許乙個程式設計師十年磨一劍,創造出乙個完全由他自己寫就的程式,於是對於程式設計師而言,他的「翻譯」的工作就多了「合作」這個幾乎是不可缺少的環節。試想一下,如果每乙個程式設計師都有自己的獨到的遣詞用句的個性和謀篇布局的想法,那麼程式應該就像是許多個人合夥完成的文章,除了蹩腳和晦澀應該不剩什麼了吧,就像我很難想象余秋雨和莫言按照自己的個性一人一句寫成的文章一樣。規範不僅不是阻礙開發,浪費時間的邪物,反而是促成效率成就未來的好東西。就像是某些演算法中的區域性最優不一定能導致全域性最優一樣,我們關心在意的是乙個整體,所有看似平庸的區域性也許就是達到全域性最優的關鍵,而**規範就是這個道理,看似限制了個性選手們的技能發揮,其實是「碼農」之愛「**」,必為其計之深遠。

(觀點二):我是個藝術家,手藝人,我有自己的規範和原則

這個觀點中的個人自我主義很嚴重。藝術家和手藝人可以有自成一家的個性,程式設計師也可以有不拘一格的風格,但是就像前面所說的那樣,如果必須要合作呢?我們可能很難接受乙個人長著畢卡索畫風的腦袋,披著吳冠中畫風的長袍的「藝術」人物來。程式的成長亦如是,古語有言:「規矩方圓」。沒有嚴格的規範,很難有完美的作品。藝術家們也是在繼承和沿襲的基礎上推陳出新的,而他們所繼承的和沿襲的就是他們行業界的規範和原則,同理,程式設計師們的**也是要相互傳承,甚至是要相互合作的,於是在這種基礎上對於規範和原則的堅守就顯得更為關鍵了。

(觀點三):規範不能強求一律,應該允許很多例外

規範確實不能強求一律,規範確實也可以允許例外。法律這種規範已經夠嚴格了吧,但是還是有基於道德之上的寬宥。可是很多例外這種事情就不能忍了,很多例外那麼規範豈不是就被束之高閣而置若罔聞了嗎?如果真的有很多的例外,那麼例外就成了「規範」,那麼程式設計師們的程式設計狀態不就又回到了前面兩個觀點所描繪的「個性張揚」,「龍飛鳳舞」的原始狀態了嗎?因為規範而逐漸演化而來的進步的意義不就重新回到原點了嗎?借用《構建之法》裡的乙個詞來講,這種現象就叫做出現了退化吧。於是言而總之,例外應該盡最大的所能去避免。

(觀點四):我擅長制定編碼規範,你們聽我的就好了

這種心態和觀點二是雷同的,都是有比較強的個人主義色彩。就像是博文的鏈結中說的那樣:「在**審查中最常犯的錯誤——幾乎每個新手都會犯的錯誤——是,審查者根據自己的程式設計習慣來評判別人的**」。太自我很容易犯錯,一人一世界的心態容易導致人與人之間的壁壘,同樣就像鏈結中的文章所說的那樣:「按照自己的意願去書寫**的程式設計師就像動物世界裡的狗撒尿一樣,創造了程式設計師之間的壁壘」。就像是一開始的我所聯想的奧運會的足球比賽那樣,每個人都有自己的個性球技,都想在這個過程中展示出來從而達到個人最優,但是結果呢? 真的達到了結果的最優嗎?顯然沒有。於是,合作的過程中不需要每個人都是創造家,更不需要每個人都是領頭羊,更需要的是踏踏實實,和follow乙個共同認可的規範。

綜上所述,規範從形式上來看是規範個性,但是從意義上來看卻是規範了軟體的未來。

(part2)

**複審**

程式的正確性

程式執行時的命令列引數的傳入有問題,數字沒有正確傳入,修改後就可以跑了

程式**的規範性

程式中的識別符號的命名和縮排等都很不錯哦,讀起來的感覺很好。

**的模組化程度

程式中函式的功能分配比較好,函式內部沒有冗餘,這一點做的比我好,我有冗餘。

程式的注釋情況

程式一開始的函式中有很好的注釋,但是後來的注釋比較少,好吧,其實我也有這個問題。

程式對於異常的處理

程式並沒有對所有的**執**況給出處理,尤其是對於異常的輸出情況沒有給出很好的處理導致程式會出現崩潰。

程式對於非法引數的處理

非法引數的輸入也沒有得到很好的處理,同樣可能導致程式的崩潰,但是細細反思,我的好像也沒有。。。

錯誤情況的捕捉

雖然c++中提供了try和catch 的異常處理機制,但是程式並沒有很好地體現出這一點優勢。

全域性變數的可替換情況

程式中定義了乙個輸出檔案的全域性變數,這個變數其實是可以在程式中換成臨時變數。

**可被庫函式代替情況

程式中的**都必要的,暫時沒有發現可以被標準的庫函式替代的**片段。

首先不得不說的是我的partner的**結構很好的,非常容易讀懂,要說的幾點具體細節如下:

可以被替代的全域性變數:

程式中一開始傳錯了命令列引數,這個是修改正確之後的**:

程式中的value類的設計在如何區別不同型別的數值上不夠方便,可以用乙個變數的不同的值來表示:

除此之外就沒有什麼要說的啦,很讚~

引擎不只是效果,程式不只是策劃。

最近工作中,又陸續發現了unreal的一些 隱藏的 東西。例如test track整合。例如uds 指令碼融入visual studio中。例如sync 合併工具。加上之前的swarm和perforce4整合。有時候在想,我們能在效果上超越它,能在一些具體的環節上超越它,但如果真正要完成乙個商業引擎...

重要的不只是技術

原創 王健 一 多年以前,我有個學生在一家做 工作流引擎 的軟體小公司裡工作。他遇到了一些麻煩。什麼是 工作流引擎 簡單地說,是一種可以自動執行流程的工作元件 使用者設定好基本的引數,該元件就能按照預先設定的工作步驟和業務的流程往下走。聽起來很酷,看上去很美。學生的麻煩是 公司的產品做得歪瓜劣棗的,...

本地回環位址不只是127 0 0 1

本地回環位址 loop back address 不屬於任何乙個有類別位址類。它代表裝置的本地虛擬介面,所以預設被看作是永遠不會宕掉的介面。主要作用有兩個 一是測試本機的網路配置,能ping通 127.0.0.1 說明本機的網絡卡和ip協議安裝都沒有問題 另乙個作用是某些server client的...