• <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

            
	

            

            
	
					


            
	
	
            如題，大致看了下網(wǎng)上能找到的一些規(guī)范，覺得大體有這么三個方面吧，一個是排版方面的，一個是命名方面的，一個是書寫邏輯方面的。
             
            排版方面的大概有，如何縮進(jìn)，如何使用空格、換行，等等。命名方面的包括變量、函數(shù)、類、文件的取名等等。書寫邏輯方面的就比較多了，可能包括：
            是否全面使用異常、出錯處理資源清理如何組織、如何利用編譯提示防止常見錯誤……
             
            一時間列不全。網(wǎng)上常見的文檔我會參考的。除此之外，想從大家這里征求下，以上幾個大方面之外，還有沒有比較重要的方面？大家日常工作中有沒有遇到一些特別希望別人也使用和自己一樣的方式做的事？以及，哪些規(guī)定比較容易被推動？哪些規(guī)定不容易被推動？如果有一個規(guī)則強(qiáng)加在你頭上，你會有怎樣的心理？等等……
             
            如果您有想法，請回復(fù)下，我們討論討論^_^
             
            ----------
             
            順便再問個問題，Windows 上的開發(fā)，大家喜歡動態(tài)鏈接 CRT（/MD、/MDd） 還是靜態(tài)鏈接 CRT（/MT、/MTd）？為什么？個人傾向于哪種？在公司里又是怎樣做的？
            
	
            posted on 2011-07-12 22:22 溪流 閱讀(2106) 評論(17)  編輯 收藏 引用  所屬分類: C++ 
            

            







            
	    
    


            
評論:

            
	

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

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

            

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

            

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

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

            Windows上開發(fā)的程序個人傾向靜態(tài)鏈接，一是用的都是最新的VS（目前用VS2010），為了讓程序在沒有裝CRT機(jī)器上運(yùn)行；二是個人開發(fā)的程序不大，靜態(tài)鏈接體積也大不了多少。
            公司開發(fā)一般都是動態(tài)鏈接。  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 09:32 | 空明流轉(zhuǎn)
            
				
            @airtrack
            VS2010哪來的static runtime。。。  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 09:33 | 空明流轉(zhuǎn)
            
				
            @airtrack
            好吧， 我錯了，看走眼了。
              回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 09:38 | 空明流轉(zhuǎn)
            
				
            @fx
            google那種規(guī)范，完全就是垃圾，之所以被奉為圭臬，還不是因為來頭大。  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 13:37 | 溪流
            
				
            @kongque

            也不是說完全“原創(chuàng)”，這些東西很多可能與網(wǎng)上流傳的大公司規(guī)范都有重疊，但我們希望挑一些適合我們自己的，而不是完全照搬。  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 13:38 | 溪流
            
				
            @kongque

            @空明流轉(zhuǎn)

            我也不是很喜歡google的規(guī)范，有些地方過于保守，有些地方也根本不認(rèn)同  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 13:39 | 溪流
            
				
            @fx

            謝謝提供參考，這份規(guī)范覺得還挺中肯。

            到最后我們自己團(tuán)隊里要通過才行，我沒有手下，只是起草這個事情。  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 13:40 | 溪流
            
				
            @airtrack

            雖然匈法一直飽受爭議，但是非匈以后，命名真的清爽了嗎？尤其是對于C++來說。這點(diǎn)我還是猶豫不決，也請樓下的多給點(diǎn)自己的觀點(diǎn)。  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 16:33 | 空明流轉(zhuǎn)
            
				
            匈牙利命名法暴露了變量的物理細(xì)節(jié)。
            這根本就是扯淡。
            對于靜態(tài)語言，物理根本就是編譯期能保證的，何須變量？  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 16:38 | 空明流轉(zhuǎn)
            
				
            至于member flag char，在標(biāo)準(zhǔn)庫的設(shè)計風(fēng)格里，是為了區(qū)分開interface， member variable和local variable的區(qū)別。

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

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

            

              回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-13 22:02 | airtrack
            
				
            匈牙利命名法的一個及其明顯的弊端，比如：
            開始定義了一個 int nSize;使用了一段時間后，被后面維護(hù)代碼的人因為某種需求改成了DWORD（或者其它類型），那是不是這個變量也要跟著改成dwSize才能符合匈牙利命名法，但是如果這個變量被很多地方使用，改起來豈不是很麻煩。雖然可以通過VA來rename，但是在團(tuán)隊開發(fā)中，團(tuán)隊成員不一定會去把變量名同步修改。
            當(dāng)然這只是個例子。
            另一方面我非常贊同空明流轉(zhuǎn)兄，我覺得變量類型編譯時期就確定了，沒有必要這么去在變量名里面暴露類型。而對于動態(tài)語言的話，那類型更加不確定，隨著運(yùn)行的過程，變量可以是任意類型，所以我覺得變量是要表達(dá)你所要代表的意思而不是類型。像上面那個例子的變量名為size就行，表達(dá)出它的作用就行，當(dāng)然可能還會具體些，命名為xxx_size。
            在C++模板中，模板中的代碼類型更加不確定了，自然不能把類型寫到變量名中。  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# re: 如果要擬定一份代碼規(guī)范，哪些內(nèi)容應(yīng)該列入？
				2011-07-14 23:45 | VGA采集卡
            
				
            命名需要規(guī)范，找一個大家都能接受的就可以了，追究那么多細(xì)節(jié)耽誤工夫  回復(fù)  更多評論
              
            
			
            
			
			
		
            
	
		
            
			
            
			# 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ù)  更多評論
              
            
			
            
			
			
		
            
	








            






            

				

            






    
    







            
	   
	



四虎影视久久久免费|
97精品伊人久久久大香线蕉|
热久久这里只有精品|
亚洲AV无码久久精品成人|
伊人久久大香线蕉AV一区二区|
2021最新久久久视精品爱|
欧美午夜A∨大片久久|
久久精品aⅴ无码中文字字幕不卡|
国产亚州精品女人久久久久久
|
一本久久免费视频|
久久免费观看视频|
久久久这里只有精品加勒比|
亚洲国产成人久久综合碰|
久久精品国产男包|
久久夜色精品国产噜噜亚洲AV|
成人久久免费网站|
日韩精品无码久久久久久|
99re这里只有精品热久久|
青青青青久久精品国产
|
久久久精品人妻一区二区三区蜜桃|
色偷偷91久久综合噜噜噜噜|
久久精品中文字幕大胸|
色婷婷综合久久久久中文|
精品久久一区二区|
四虎国产精品成人免费久久|
亚洲国产精品无码久久久秋霞2|
国产精品9999久久久久|
www亚洲欲色成人久久精品|
久久久久久午夜精品|
AV无码久久久久不卡蜜桃|
欧美午夜A∨大片久久
|
99久久777色|
国产精品永久久久久久久久久|
无码国内精品久久综合88|
好属妞这里只有精品久久|
欧美久久综合九色综合|
99精品久久精品|
久久精品国产久精国产果冻传媒
|
精品一区二区久久久久久久网站|
久久久精品人妻无码专区不卡|
日韩人妻无码精品久久久不卡|