• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆-90  評論-947  文章-0  trackbacks-0

            如題,大致看了下網上能找到的一些規范,覺得大體有這么三個方面吧,一個是排版方面的,一個是命名方面的,一個是書寫邏輯方面的。

            排版方面的大概有,如何縮進,如何使用空格、換行,等等。命名方面的包括變量、函數、類、文件的取名等等。書寫邏輯方面的就比較多了,可能包括:
            是否全面使用異常、出錯處理資源清理如何組織、如何利用編譯提示防止常見錯誤……

            一時間列不全。網上常見的文檔我會參考的。除此之外,想從大家這里征求下,以上幾個大方面之外,還有沒有比較重要的方面?大家日常工作中有沒有遇到一些特別希望別人也使用和自己一樣的方式做的事?以及,哪些規定比較容易被推動?哪些規定不容易被推動?如果有一個規則強加在你頭上,你會有怎樣的心理?等等……

            如果您有想法,請回復下,我們討論討論^_^

            ----------

            順便再問個問題,Windows 上的開發,大家喜歡動態鏈接 CRT(/MD、/MDd) 還是靜態鏈接 CRT(/MT、/MTd)?為什么?個人傾向于哪種?在公司里又是怎樣做的?

            posted on 2011-07-12 22:22 溪流 閱讀(2105) 評論(17)  編輯 收藏 引用 所屬分類: C++

            評論:
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-12 23:08 | kongque
            我覺得自己重新擬定一份的必要性不是很大。可以參考一份現成的,比如microsoft的匈牙利命名規范或者google c++編碼規范。這個好處是,一可以省去重新擬定規范的功夫,二來這種規范知名度高,具有一定的權威性,容易被人接受。

            本人以前做過游戲開發,傾向于動態鏈接庫鏈接,公司也是那么作的。
              回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-12 23:24 | fx
            參考大公司的成功項目,比如webkit, 對編程要求嚴格至極,tab和空格都限定。http://blog.csdn.net/huangc1982/article/details/5597156

            至于手下是不是聽你訂的規范,有兩點,1. 規范本身必須合理。2. 來頭要大,名氣要大,權威。

            靜態和動態鏈接都是些個人喜好問題。個人而言,小項目靜態,大項目動態。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-12 23:31 | 陳梓瀚(vczh)
            .NET曾經出了本告訴你怎么設計framework的書,里面就有說到這個事情。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 00:01 | airtrack
            1、四格縮進,整體簡潔統一,函數不要太長,一般不超過30行。
            2、只要是非匈牙利命名法覺得都可以(最討厭匈牙利命名法,看了《觀止》之后發現卡特勒也很討厭它,我就更加堅定了),比較喜歡google的命名方式。
            3、邏輯簡潔,函數和類單一職責,RAII,個人比較傾向使用異常,異常能夠讓代碼更整潔的處理錯誤。當然公司的話,看項目是怎么定的了。

            特別希望其他人提交到庫里面的代碼沒有注釋掉的代碼,最討厭看到注釋掉的代碼。函數不要太長,類不要太大,一切都是為了單一職責。
            被強加的規則,好的接受,不喜歡的也得接受,因為自己不是老大。

            Windows上開發的程序個人傾向靜態鏈接,一是用的都是最新的VS(目前用VS2010),為了讓程序在沒有裝CRT機器上運行;二是個人開發的程序不大,靜態鏈接體積也大不了多少。
            公司開發一般都是動態鏈接。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 09:32 | 空明流轉
            @airtrack
            VS2010哪來的static runtime。。。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 09:33 | 空明流轉
            @airtrack
            好吧, 我錯了,看走眼了。
              回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 09:38 | 空明流轉
            @fx
            google那種規范,完全就是垃圾,之所以被奉為圭臬,還不是因為來頭大。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 13:37 | 溪流
            @kongque
            也不是說完全“原創”,這些東西很多可能與網上流傳的大公司規范都有重疊,但我們希望挑一些適合我們自己的,而不是完全照搬。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 13:38 | 溪流
            @kongque
            @空明流轉
            我也不是很喜歡google的規范,有些地方過于保守,有些地方也根本不認同  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 13:39 | 溪流
            @fx
            謝謝提供參考,這份規范覺得還挺中肯。
            到最后我們自己團隊里要通過才行,我沒有手下,只是起草這個事情。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 13:40 | 溪流
            @airtrack
            雖然匈法一直飽受爭議,但是非匈以后,命名真的清爽了嗎?尤其是對于C++來說。這點我還是猶豫不決,也請樓下的多給點自己的觀點。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 16:33 | 空明流轉
            匈牙利命名法暴露了變量的物理細節。
            這根本就是扯淡。
            對于靜態語言,物理根本就是編譯期能保證的,何須變量?  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 16:38 | 空明流轉
            至于member flag char,在標準庫的設計風格里,是為了區分開interface, member variable和local variable的區別。

            因為在變量進行最直觀化的命名時,能區分出來的只有它的實際含義/用途,但是對于它工作的上下文(例如作用域)并沒有任何體現。比方說,你成員變量和獲得該成員變量的接口,都可以叫size。

            這個問題在標準庫中尤為明顯。有一些例如接口首字母大寫,變量用camel這樣的辦法還好一點。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 17:39 | fx
            一個參與者眾多的軟件項目,要成功是很困難的。并不是盲從webkit, 我個人寫程序也不是webkit style, 只是團隊合作不能沒有個準繩,所謂team work, 就是要犧牲一部分個性,來換取整體代碼的協調性。。

              回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-13 22:02 | airtrack
            匈牙利命名法的一個及其明顯的弊端,比如:
            開始定義了一個 int nSize;使用了一段時間后,被后面維護代碼的人因為某種需求改成了DWORD(或者其它類型),那是不是這個變量也要跟著改成dwSize才能符合匈牙利命名法,但是如果這個變量被很多地方使用,改起來豈不是很麻煩。雖然可以通過VA來rename,但是在團隊開發中,團隊成員不一定會去把變量名同步修改。
            當然這只是個例子。
            另一方面我非常贊同空明流轉兄,我覺得變量類型編譯時期就確定了,沒有必要這么去在變量名里面暴露類型。而對于動態語言的話,那類型更加不確定,隨著運行的過程,變量可以是任意類型,所以我覺得變量是要表達你所要代表的意思而不是類型。像上面那個例子的變量名為size就行,表達出它的作用就行,當然可能還會具體些,命名為xxx_size。
            在C++模板中,模板中的代碼類型更加不確定了,自然不能把類型寫到變量名中。  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-07-14 23:45 | VGA采集卡
            命名需要規范,找一個大家都能接受的就可以了,追究那么多細節耽誤工夫  回復  更多評論
              
            # re: 如果要擬定一份代碼規范,哪些內容應該列入? 2011-08-26 11:51 | belstaff uk
            grow up, will slowly understand the ways of the world, learn the streets and   回復  更多評論
              
            中文字幕亚洲综合久久| 麻豆久久久9性大片| 无码人妻久久久一区二区三区 | 蜜臀av性久久久久蜜臀aⅴ麻豆 | 久久伊人影视| 久久人人爽人人爽人人AV东京热| 久久99精品久久久久久hb无码| 国产精品VIDEOSSEX久久发布| 亚洲日韩中文无码久久| 久久国产成人精品国产成人亚洲| av国内精品久久久久影院| 久久国产成人午夜aⅴ影院| 一本久久a久久精品亚洲| 久久综合九色综合精品| 精品国产乱码久久久久久1区2区| 国产高潮国产高潮久久久91| 久久久久99这里有精品10 | 中文字幕久久精品无码| 久久久久国产精品三级网| 国产成人精品久久亚洲高清不卡 | 欧美精品九九99久久在观看| 97精品国产97久久久久久免费| 亚洲国产精品无码久久久不卡 | 99久久香蕉国产线看观香| 久久久这里只有精品加勒比| 99久久免费国产精品热| 久久综合久久久| 久久久久久国产精品无码超碰| 久久久久亚洲AV无码麻豆| 区亚洲欧美一级久久精品亚洲精品成人网久久久久 | 久久久99精品一区二区| 91超碰碰碰碰久久久久久综合| 精品久久久久久国产潘金莲 | 亚洲精品无码久久千人斩| 日批日出水久久亚洲精品tv| 久久这里只精品99re66| 午夜精品久久久久成人| 色婷婷综合久久久久中文字幕 | 久久久久久亚洲Av无码精品专口 | 久久人人爽人人爽人人片av麻烦| 欧美午夜精品久久久久免费视|