• <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  評(píng)論-947  文章-0  trackbacks-0

            如題,大致看了下網(wǎng)上能找到的一些規(guī)范,覺(jué)得大體有這么三個(gè)方面吧,一個(gè)是排版方面的,一個(gè)是命名方面的,一個(gè)是書(shū)寫(xiě)邏輯方面的。

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

            一時(shí)間列不全。網(wǎng)上常見(jiàn)的文檔我會(huì)參考的。除此之外,想從大家這里征求下,以上幾個(gè)大方面之外,還有沒(méi)有比較重要的方面?大家日常工作中有沒(méi)有遇到一些特別希望別人也使用和自己一樣的方式做的事?以及,哪些規(guī)定比較容易被推動(dòng)?哪些規(guī)定不容易被推動(dòng)?如果有一個(gè)規(guī)則強(qiáng)加在你頭上,你會(huì)有怎樣的心理?等等……

            如果您有想法,請(qǐng)回復(fù)下,我們討論討論^_^

            ----------

            順便再問(wèn)個(gè)問(wèn)題,Windows 上的開(kāi)發(fā),大家喜歡動(dòng)態(tài)鏈接 CRT(/MD、/MDd) 還是靜態(tài)鏈接 CRT(/MT、/MTd)?為什么?個(gè)人傾向于哪種?在公司里又是怎樣做的?

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

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

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

            至于手下是不是聽(tīng)你訂的規(guī)范,有兩點(diǎn),1. 規(guī)范本身必須合理。2. 來(lái)頭要大,名氣要大,權(quán)威。

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

            特別希望其他人提交到庫(kù)里面的代碼沒(méi)有注釋掉的代碼,最討厭看到注釋掉的代碼。函數(shù)不要太長(zhǎng),類(lèi)不要太大,一切都是為了單一職責(zé)。
            被強(qiáng)加的規(guī)則,好的接受,不喜歡的也得接受,因?yàn)樽约翰皇抢洗蟆?br>
            Windows上開(kāi)發(fā)的程序個(gè)人傾向靜態(tài)鏈接,一是用的都是最新的VS(目前用VS2010),為了讓程序在沒(méi)有裝CRT機(jī)器上運(yùn)行;二是個(gè)人開(kāi)發(fā)的程序不大,靜態(tài)鏈接體積也大不了多少。
            公司開(kāi)發(fā)一般都是動(dòng)態(tài)鏈接。  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 09:32 | 空明流轉(zhuǎn)
            @airtrack
            VS2010哪來(lái)的static runtime。。。  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 09:33 | 空明流轉(zhuǎn)
            @airtrack
            好吧, 我錯(cuò)了,看走眼了。
              回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 09:38 | 空明流轉(zhuǎn)
            @fx
            google那種規(guī)范,完全就是垃圾,之所以被奉為圭臬,還不是因?yàn)閬?lái)頭大。  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 13:37 | 溪流
            @kongque
            也不是說(shuō)完全“原創(chuàng)”,這些東西很多可能與網(wǎng)上流傳的大公司規(guī)范都有重疊,但我們希望挑一些適合我們自己的,而不是完全照搬。  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 13:38 | 溪流
            @kongque
            @空明流轉(zhuǎn)
            我也不是很喜歡google的規(guī)范,有些地方過(guò)于保守,有些地方也根本不認(rèn)同  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 13:39 | 溪流
            @fx
            謝謝提供參考,這份規(guī)范覺(jué)得還挺中肯。
            到最后我們自己團(tuán)隊(duì)里要通過(guò)才行,我沒(méi)有手下,只是起草這個(gè)事情。  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 13:40 | 溪流
            @airtrack
            雖然匈法一直飽受爭(zhēng)議,但是非匈以后,命名真的清爽了嗎?尤其是對(duì)于C++來(lái)說(shuō)。這點(diǎn)我還是猶豫不決,也請(qǐng)樓下的多給點(diǎn)自己的觀點(diǎn)。  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 16:33 | 空明流轉(zhuǎn)
            匈牙利命名法暴露了變量的物理細(xì)節(jié)。
            這根本就是扯淡。
            對(duì)于靜態(tài)語(yǔ)言,物理根本就是編譯期能保證的,何須變量?  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 16:38 | 空明流轉(zhuǎn)
            至于member flag char,在標(biāo)準(zhǔn)庫(kù)的設(shè)計(jì)風(fēng)格里,是為了區(qū)分開(kāi)interface, member variable和local variable的區(qū)別。

            因?yàn)樵谧兞窟M(jìn)行最直觀化的命名時(shí),能區(qū)分出來(lái)的只有它的實(shí)際含義/用途,但是對(duì)于它工作的上下文(例如作用域)并沒(méi)有任何體現(xiàn)。比方說(shuō),你成員變量和獲得該成員變量的接口,都可以叫size。

            這個(gè)問(wèn)題在標(biāo)準(zhǔn)庫(kù)中尤為明顯。有一些例如接口首字母大寫(xiě),變量用camel這樣的辦法還好一點(diǎn)。  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 17:39 | fx
            一個(gè)參與者眾多的軟件項(xiàng)目,要成功是很困難的。并不是盲從webkit, 我個(gè)人寫(xiě)程序也不是webkit style, 只是團(tuán)隊(duì)合作不能沒(méi)有個(gè)準(zhǔn)繩,所謂team work, 就是要犧牲一部分個(gè)性,來(lái)?yè)Q取整體代碼的協(xié)調(diào)性。。

              回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-13 22:02 | airtrack
            匈牙利命名法的一個(gè)及其明顯的弊端,比如:
            開(kāi)始定義了一個(gè) int nSize;使用了一段時(shí)間后,被后面維護(hù)代碼的人因?yàn)槟撤N需求改成了DWORD(或者其它類(lèi)型),那是不是這個(gè)變量也要跟著改成dwSize才能符合匈牙利命名法,但是如果這個(gè)變量被很多地方使用,改起來(lái)豈不是很麻煩。雖然可以通過(guò)VA來(lái)rename,但是在團(tuán)隊(duì)開(kāi)發(fā)中,團(tuán)隊(duì)成員不一定會(huì)去把變量名同步修改。
            當(dāng)然這只是個(gè)例子。
            另一方面我非常贊同空明流轉(zhuǎn)兄,我覺(jué)得變量類(lèi)型編譯時(shí)期就確定了,沒(méi)有必要這么去在變量名里面暴露類(lèi)型。而對(duì)于動(dòng)態(tài)語(yǔ)言的話,那類(lèi)型更加不確定,隨著運(yùn)行的過(guò)程,變量可以是任意類(lèi)型,所以我覺(jué)得變量是要表達(dá)你所要代表的意思而不是類(lèi)型。像上面那個(gè)例子的變量名為size就行,表達(dá)出它的作用就行,當(dāng)然可能還會(huì)具體些,命名為xxx_size。
            在C++模板中,模板中的代碼類(lèi)型更加不確定了,自然不能把類(lèi)型寫(xiě)到變量名中。  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-07-14 23:45 | VGA采集卡
            命名需要規(guī)范,找一個(gè)大家都能接受的就可以了,追究那么多細(xì)節(jié)耽誤工夫  回復(fù)  更多評(píng)論
              
            # re: 如果要擬定一份代碼規(guī)范,哪些內(nèi)容應(yīng)該列入? 2011-08-26 11:51 | belstaff uk
            grow up, will slowly understand the ways of the world, learn the streets and   回復(fù)  更多評(píng)論
              
            国产成人精品免费久久久久| 久久国产成人午夜AV影院| 久久久久久九九99精品| 99久久精品午夜一区二区| 精品熟女少妇aⅴ免费久久| 精品久久久久成人码免费动漫 | 久久精品国产精品青草app| 久久国产精品免费一区二区三区| 欧洲国产伦久久久久久久| 99久久精品费精品国产一区二区| 无夜精品久久久久久| 国产精品一区二区久久| 亚洲综合精品香蕉久久网| 激情五月综合综合久久69| 无码超乳爆乳中文字幕久久 | 久久精品中文无码资源站| 99久久精品免费看国产免费| 人妻精品久久无码区| 久久99九九国产免费看小说| 品成人欧美大片久久国产欧美| 日韩精品久久无码人妻中文字幕| 色综合久久中文字幕综合网| 色噜噜狠狠先锋影音久久| 久久99精品久久久久久久不卡| 国产aⅴ激情无码久久| 一个色综合久久| 一级a性色生活片久久无少妇一级婬片免费放| 国产成年无码久久久久毛片| 亚洲伊人久久精品影院| 亚洲欧美日韩久久精品| 久久天天躁狠狠躁夜夜不卡| 久久97精品久久久久久久不卡| 久久久久99精品成人片直播| 亚洲av日韩精品久久久久久a| 国产成人综合久久精品红| 国产免费久久精品99re丫y| 99精品久久久久久久婷婷| 2021国产成人精品久久| 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲 | 曰曰摸天天摸人人看久久久| 久久精品成人免费看|