PVS-Studio: हम ReactOS ऑपरेटिंग सिस्टम के कोड का विश्लेषण करते हैं

ReactOS कोड की जांच करने के बाद, मैं एक ही बार में अपनी तीन इच्छाओं को पूरा करने में सक्षम था। सबसे पहले, मैं लंबे समय से एक साधारण परियोजना के बारे में एक लेख लिखना चाहता था। क्रोमियम जैसी परियोजनाओं के लिए कोड की जाँच करना दिलचस्प नहीं है। यह बहुत उच्च गुणवत्ता वाला है, और सामान्य परियोजनाओं में उपलब्ध संसाधन इस गुणवत्ता को बनाए रखने पर खर्च नहीं किए जाते हैं। दूसरे, एक अच्छा उदाहरण सामने आया है, जिस पर आप दिखा सकते हैं कि किसी बड़ी परियोजना में स्थैतिक विश्लेषण कैसे आवश्यक है, खासकर यदि यह एक विषम वितरित टीम द्वारा विकसित किया गया हो। तीसरा, मुझे पुष्टि मिली कि पीवीएस-स्टूडियो बेहतर और अधिक उपयोगी हो रहा है।

पीवीएस-स्टूडियो बेहतर और बेहतर हो रहा है

मैं पीवीएस-स्टूडियो टूल के लाभों के बारे में अंतिम क्षण से शुरू करूंगा। रिएक्टोस अप्रत्यक्ष रूप से पुष्टि करता है कि पीवीएस-स्टूडियो सही दिशा में विकसित हो रहा है। यहाँ एक भारीपन के साथ रिएक्टोस की जाँच करने के बारे में खबर है जैसे कि आवरण - "आवरण में स्थैतिक विश्लेषण" [ 1 ]। निश्चित रूप से, मैं जानता हूं और समझता हूं कि हम आवरण की संभावनाओं से बहुत दूर हैं। लेकिन, फिर भी, जहां कवरिट के लिए धन्यवाद "कई नई त्रुटियां पाई गईं", पीवीएस-स्टूडियो उनकी पूरी गाड़ी और छोटी गाड़ी पाता है। इस मामले में, कहीं भी कोई कोड नहीं भेजा जाना चाहिए। आप प्रोजेक्ट को बस ले सकते हैं और जांच सकते हैं। इसलिए हम सही रास्ते पर हैं।

रिएक्टोस क्या है?

रिएक्टोस विंडोज एक्सपी / 2003 की वास्तुकला पर आधारित एक आधुनिक, मुफ्त और खुला ऑपरेटिंग सिस्टम है। सिस्टम को स्क्रैच से लिखा गया था और इसका उद्देश्य माइक्रोसॉफ्ट के विंडोज-एनटी आर्किटेक्चर को हार्डवेयर से एप्लीकेशन स्तर तक दोहराना था। C, C ++ और कोडांतरक में स्रोत कोड की मात्रा लगभग 220 मेगाबाइट है।

विभिन्न लिंक:

• रिएक्टोस परियोजना की आधिकारिक साइट ।
• रिएक्टोस के विकास में कैसे भाग लें ।
• विकिपीडिया। ReactOS ।
• कंप्यूटर लेख। ReactOS: पकड़ कर आगे निकल जाना ।
• Lurkmore। ReactOS ।

रिएक्टोस में कीड़े

अब आइए ReactOS कोड में आई त्रुटियों की गाड़ी के बारे में बात करते हैं। बेशक, उन सभी को लेख में शामिल नहीं किया जाएगा। यहां मैंने एक पाठ फ़ाइल पोस्ट की जो त्रुटियों का विश्लेषण करने के दौरान मैंने देखा। फ़ाइल में फ़ाइल नाम और रेखा संख्या के साथ नैदानिक ​​संदेश हैं। मैंने शॉर्ट कोड में त्रुटियों को भी उजागर किया और कुछ टिप्पणियां दीं। इसलिए, जो लोग ReactOS के लिए संपादन करना चाहते हैं, वे इस फाइल के बजाय एक लेख द्वारा निर्देशित बेहतर हैं।

बेहतर अभी तक, पीवीएस-स्टूडियो का उपयोग करके परियोजना को स्वयं डाउनलोड और परीक्षण करें। आखिरकार, मैं परियोजना से परिचित नहीं हूं और केवल उन त्रुटियों को लिखा है जिन्हें मैं समझता हूं। कई कोड अंशों के लिए, मुझे नहीं पता कि उनमें त्रुटियां हैं या नहीं। इसलिए मेरा विश्लेषण काफी सतही है। हम सत्यापन के लिए कुंजी का चयन करते हैं।

ReactOS में पाई जा सकने वाली त्रुटियाँ विविध हैं। बस एक चिड़ियाघर है। एक एकल चरित्र से टाइपो हैं।

BOOL WINAPI GetMenuItemInfoA(...) { ... mii->cch = mii->cch; ... } 

वास्तव में, इसे इस तरह लिखा जाना चाहिए: "mii-> cch = miiW-> cch;"। 'W' अक्षर खो दिया। परिणामस्वरूप, प्रोग्राम अब GetMenuItemInfoA फ़ंक्शन पर भरोसा नहीं कर सकते हैं।

और यहाँ एक चरित्र में एक और टाइपो है। इस बार, दो नामों की तुलना सही ढंग से काम नहीं करती है।

 static void _Stl_loc_combine_names(_Locale_impl* L, const char* name1, const char* name2, locale::category c) { if ((c & locale::all) == 0 || strcmp(name1, name1) == 0) ... } 

&& और ऑपरेटर के बीच भ्रम होता है। एक बहुत ही सामान्य गलती। मैं लगभग हर परियोजना में मिलता हूं, जहां वे बिट्स या फ़ाइल विशेषताओं के साथ काम करते हैं।

 static LRESULT APIENTRY ACEditSubclassProc() { ... if ((This->options && ACO_AUTOSUGGEST) && ((HWND)wParam != This->hwndListBox)) ... } 

सही कोड "(यह-> विकल्प और ACO_AUTOSUGGEST)" जैसा दिखना चाहिए। नीचे दिए गए उदाहरण में संबंधित त्रुटि है, जिसके कारण पूरी स्थिति हमेशा झूठी होती है।

 void adns__querysend_tcp(adns_query qu, struct timeval now) { ... if (!(errno == EAGAIN || EWOULDBLOCK || errno == EINTR || errno == ENOSPC || errno == ENOBUFS || errno == ENOMEM)) { ... } 

यदि आप बारीकी से देखते हैं, तो आप एक कपटी टुकड़े को नोटिस कर सकते हैं: "|| EWOULDBLOCK ||"

वैसे, रिएक्टोस में बहुत सारी स्थितियां थीं जो हमेशा सच या गलत होती हैं। कुछ भयभीत नहीं हैं, क्योंकि, उदाहरण के लिए, वे मुखर () मैक्रो में स्थित हैं। लेकिन मेरी राय में, महत्वपूर्ण हैं।

 INT WSAAPI connect(IN SOCKET s, IN CONST struct sockaddr *name, IN INT namelen) { ... /* Check if error code was due to the host not being found */ if ((Status == SOCKET_ERROR) && (ErrorCode == WSAEHOSTUNREACH) && (ErrorCode == WSAENETUNREACH)) { ... } 

सहमत हूँ कि "कनेक्ट" जैसे कार्यों के कार्यान्वयन को यथासंभव पूरी तरह से परीक्षण किया जाना चाहिए। और यहाँ हमारी एक शर्त है जो हमेशा झूठी होती है। जल्दी से एक जगह खोलना इतना आसान नहीं है, इसलिए मैं त्रुटि के सार को उजागर करूंगा:

 (ErrorCode == 10065) && (ErrorCode == 10051) 

वैसे, सॉकेट से संबंधित हिस्सा आम तौर पर कच्चा दिखता है। शायद यह इस तथ्य के कारण है कि लिनक्स की दुनिया में SOCKET को आमतौर पर एक संकेत प्रकार के रूप में घोषित किया जाता है। और विंडोज पर, यह अहस्ताक्षरित है:

 typedef UINT_PTR SOCKET; 

परिणामस्वरूप, हमारे पास तुलनात्मक संचालन में विभिन्न त्रुटियां हैं:

 void adns_finish(adns_state ads) { ... if (ads->tcpsocket >= 0) adns_socket_close(ads->tcpsocket); ... } 

अभिव्यक्ति "विज्ञापन-> tcpsocket> = 0" का कोई मतलब नहीं है, क्योंकि यह हमेशा सच होता है।

बस विचित्र अंश हैं। सबसे अधिक संभावना है, ये कोड के अधूरे और भूल गए अनुभाग हैं।

 if (ERROR_SUCCESS == hres) { Names[count] = HeapAlloc(GetProcessHeap(), 0, strlenW(szValue) + 1); if (Names[count]) strcmpW(Names[count], szValue); } 

यदि परिणाम किसी भी तरह से उपयोग नहीं किया जाता है तो "strcmpW" क्यों कहें?

संचालन की प्राथमिकता से संबंधित त्रुटियां हैं।

 VOID NTAPI AtapiDmaInit(...) { ... ULONG treg = 0x54 + (dev < 3) ? (dev << 1) : 7; ... } 

मैं यह स्पष्ट करने के लिए कि यह वास्तव में कैसे काम करता है, चारों ओर कोष्ठक लगाएंगे:

 ULONG treg = (0x54 + (dev < 3)) ? (dev << 1) : 7; 

निम्नलिखित त्रुटि किसी भी बड़ी परियोजना में होनी चाहिए। रिएक्टोस में एक युगल हैं। यह एक अतिरिक्त अर्धविराम है - ';'।

 BOOLEAN CTEScheduleEvent(PCTE_DELAYED_EVENT Event, PVOID Context) { ... if (!Event->Queued); { Event->Queued = TRUE; Event->Context = Context; ExQueueWorkItem(&Event->WorkItem, CriticalWorkQueue); } ... } 

मुझे सरणी तत्वों को आरंभीकृत करने में त्रुटियाँ भी पसंद हैं। मुझे पता नहीं क्यों वे छू रहे हैं। शायद मुझे बेसिक भाषा में सरणियों के साथ अपना पहला प्रयोग याद है।

 HPALETTE CardWindow::CreateCardPalette() { ... //include button text colours cols[0] = RGB(0, 0, 0); cols[1] = RGB(255, 255, 255); //include the base background colour cols[1] = crBackgnd; //include the standard button colours... cols[3] = CardButton::GetHighlight(crBackgnd); cols[4] = CardButton::GetShadow(crBackgnd); ... } 

आप कोड के विभिन्न दिलचस्प वर्गों को सूचीबद्ध करना जारी रख सकते हैं। दुर्भाग्य से, फिर लेख बहुत लंबा हो जाएगा और आपको रोकना होगा। मुझे आपको याद दिलाना है कि आप इस फ़ाइल में ReactOS में पाई गई अन्य त्रुटियों को देख सकते हैं। मिठाई के लिए, मैं सिर्फ इस कोड को दे दूंगा:

 #define SWAP(a,b,c) c = a;\ a = b;\ a = c 

उपयोग उदाहरण:

 BOOL FASTCALL IntEngGradientFillTriangle(...) { ... SWAP(v2,v3,t); ... } 

यह एक उत्कृष्ट कृति है।

स्थैतिक कोड विश्लेषण

मुझे लगता है कि रिएक्टोस एक परियोजना का एक बहुत अच्छा उदाहरण है जहां नियमित रूप से स्थिर कोड विश्लेषण आवश्यक है। और यह डेवलपर योग्यता का मामला नहीं है। यह परियोजना बड़ी है और इसमें कई उप-प्रणालियाँ शामिल हैं। इसका मतलब है कि बड़ी संख्या में लोग हमेशा ऐसी परियोजना पर काम करते हैं। और एक बड़ी टीम में, कोई हमेशा बदतर कार्यक्रम करता है, कोई बेहतर होता है। कोई एक स्टाइल का इस्तेमाल करता है, तो कोई किसी और का। लेकिन कोई भी गलतियों से सुरक्षित नहीं है। यहाँ देखो।

एक व्यक्ति ने इस तरह ReactOS में लिखा और लिखा:

 if ((res = setsockopt(....) == -1)) 

कोड वह नहीं करता जो आप चाहते हैं। सही विकल्प: यदि ((Res = setsockopt (....)) == -1)। यदि आप शुरुआत में एक निरंतर लिखने के अभ्यास से चिपके रहते हैं, तो संयोग से आप कभी भी गलत विवरण नहीं दे पाएंगे। हमारे यहाँ एक अलग प्रकार की त्रुटि है। लेकिन यदि आप उपरोक्त नियम के अनुसार कोड लिखते हैं, तो आप प्रश्न में अभिव्यक्ति में गलती नहीं कर पाएंगे: "अगर (-1 == res = setsockopt (....))"।

बस इस अभ्यास को जानने से दूसरे व्यक्ति को वैकल्पिक तरीके से त्रुटि करने से नहीं रोका जा सकता है।

 static DWORD CALLBACK RegistrationProc(LPVOID Parameter) { ... if (0 == LoadStringW(hDllInstance, IDS_UNKNOWN_ERROR, UnknownError, sizeof(UnknownError) / sizeof(UnknownError[0] - 20))) ... } 

यहाँ, निरंतर 0 को पहली बार में खूबसूरती से लिखा गया है। यह केवल कोष्ठक बंद हो जाता है जहाँ इसकी आवश्यकता नहीं होती है। साधारण टाइपो।

मैं ये सब उदाहरण क्यों हूँ? और यह तथ्य कि हममें से कोई भी प्रोग्रामर परिपूर्ण नहीं है। और न तो कोडिंग मानक, न ही प्रोग्रामिंग तकनीक, और न ही आत्म-नियंत्रण कोड में त्रुटियों की अनुपस्थिति की गारंटी देता है।

बड़ी परियोजनाओं में, गतिशील और स्थैतिक विश्लेषण जैसी सहायक तकनीकों की आवश्यकता होती है। मैं जोर देता हूं:

मेरा मानना ​​है कि रिएक्टोस और अन्य बड़ी परियोजनाओं के विकास चक्र में स्थिर कोड विश्लेषण एक अनिवार्य तत्व होना चाहिए।

मैं अपने बयान की व्याख्या करूंगा। ऐसी प्रणालियों में, यूनिट परीक्षणों या प्रतिगमन परीक्षणों के साथ परीक्षण करते समय 100% कोड कवरेज के करीब पहुंचना असंभव है। मैं थोड़ा स्पष्ट करूँगा यह संभव है, लेकिन ऐसे परीक्षणों को बनाने और बनाए रखने की लागत अस्वीकार्य रूप से उच्च हो जाती है।

कारण यह है कि कोड शाखाओं को निष्पादित करने के संभावित सिस्टम राज्यों और संभावित तरीकों की संख्या बहुत बड़ी है। कुछ शाखाओं को शायद ही कभी नियंत्रण प्राप्त होता है, लेकिन यह अनावश्यक नहीं होता है। यह वह जगह है जहां यह स्थिर विश्लेषण के लाभ को देखने के लिए निकला है। यह सभी कोड की जांच करता है, चाहे वह कार्यक्रम के दौरान कितनी बार भी नियंत्रण प्राप्त करे।

चेक कोड का एक उदाहरण जो शायद ही कभी नियंत्रण प्राप्त करता है:

 static HRESULT STDMETHODCALLTYPE CBindStatusCallback_OnProgress(...) { ... if (This->szMimeType[0] != _T('\0')) _tprintf(_T("Length: %I64u [%s]\n"), This->Size, This->szMimeType); else _tprintf(_T("Length: %ull\n"), This->Size); ... } 

सबसे अधिक संभावना है, कोड मूल रूप से गलत तरीके से लिखा गया था। तब किसी ने देखा कि संदेश सही तरीके से नहीं बना था और "% I64u" लिखकर सुधार किया। लेकिन उसने पड़ोस में कोड पर ध्यान नहीं दिया। और अभी भी गलत प्रारूप "% ull" है। जाहिरा तौर पर शाखा को शायद ही कभी कहा जाता है। स्थैतिक विश्लेषण इसे याद नहीं करेगा। दरअसल, वह मिस नहीं करता, क्योंकि मैं इस उदाहरण को प्रदर्शित कर सकता हूं।

एक और अच्छा उदाहरण मेमोरी क्लीनअप त्रुटियों की बड़ी संख्या है जो मैंने रिएक्टोस को देखा। उनमें से कई क्यों हैं, मैं समझता हूं। कोई भी परीक्षण नहीं कर रहा है कि स्मृति पूर्ण है या नहीं। सबसे पहले, यह महसूस करना कठिन है कि आप इन सरल स्थानों में गलतियाँ कर सकते हैं। और दूसरी बात, यह जांचना इतना आसान नहीं है कि कुछ अस्थायी बफर ने फ़ंक्शन के अंदर साफ किया है या नहीं। यहाँ, स्थैतिक विश्लेषण फिर से बराबर है। मैं केवल कुछ उदाहरण दूंगा। वास्तव में, मैंने निरंतर मान के साथ सरणियों को भरने में कम से कम 13 त्रुटियों को गिना।

 #define MEMSET_BZERO(p,l) memset((p), 0, (l)) char *SHA384_End(SHA384_CTX* context, char buffer[]) { ... MEMSET_BZERO(context, sizeof(context)); ... } 

हम सरणी के केवल पहले बाइट्स को स्पष्ट करते हैं, क्योंकि sizeof (संदर्भ) पॉइंटर के आकार को लौटाता है, न कि संरचना को।

 #define RtlFillMemory(Destination, Length, Fill) \ memset(Destination, Fill, Length) #define IOPM_FULL_SIZE 8196 HalpRestoreIopm(VOID) { ... RtlFillMemory(HalpSavedIoMap, 0xFF, IOPM_FULL_SIZE); ... } 

RtlFillMemory मैक्रो का उपयोग करते समय तर्क मिश्रित होते हैं। कॉल इस तरह होना चाहिए:

 RtlFillMemory(HalpSavedIoMap, IOPM_FULL_SIZE, 0xFF); 

टैब और स्पेस फिर से

मैं अग्रिम में पूछना चाहता हूं कि टिप्पणियों में इस विषय पर एक नई गर्म चर्चा शुरू न करें। मैं सिर्फ अपनी राय व्यक्त करूंगा। आप उससे सहमत हो सकते हैं या नहीं। लेकिन यह चर्चा के लायक नहीं है।

दो अपूरणीय शिविर हैं। कुछ कोड में सारणीकरण का उपयोग करते हैं, क्योंकि इससे आप अपने लिए कोड के प्रदर्शन को समायोजित कर सकते हैं [ 2 ]। दूसरों का कहना है कि यह अभी भी काम नहीं करता है और टैब का उपयोग करने का कोई उचित कारण नहीं है। सारणीकरण से केवल स्वरूपण को नुकसान और फैलाव होता है। मैं उनमें से हूं [ 3 ]।

आप जितना चाहें कह सकते हैं कि टैब का सही उपयोग किया जाना चाहिए और फिर सबकुछ ठीक हो जाएगा। दुर्भाग्य से, यह उन लोगों द्वारा कहा जाता है जो एक परियोजना पर अलगाव में काम करते हैं और बाहरी दुनिया का सामना नहीं करते हैं। किसी भी खुले या बस बड़े प्रोजेक्ट में, सामान्य कोड डिज़ाइन प्राप्त करना संभव नहीं है यदि आपको किसी भी रूप में टैब का उपयोग करने की अनुमति है।

मैं अमूर्त तर्क से नहीं निपटूंगा। इस बार मैं सिर्फ अपने विरोधियों को एक अच्छा उदाहरण दूंगा। अब, ReactOS कोड एक ऐसा उदाहरण होगा।

ReactOS कोडिंग मानक [ 4 ] में, एक अच्छा नियम सैद्धांतिक दृष्टिकोण से लिखा गया है:
TABs के उपयोग के बारे में सामान्य नोट: स्वरूपण के लिए TAB का उपयोग न करें; केवल इंडेंटिंग के लिए TAB का उपयोग करें और स्वरूपण के लिए केवल रिक्त स्थान का उपयोग करें।

 उदाहरण: 
 NTSTATUS
 SomeApi (IN प्रकार Param1,
 [रिक्त स्थान] टाइप परम 2 में]
 {
 [ताब] उलोंग मायवर;
 [TAB] MyVar = 0;
 [TAB] यदि ((MyVar == 3) &&
 [TAB] [sp] (Param1 == TRUE))
 [TAB] {
 [TAB] [TAB] CallSomeFunc ();
 ... 

टैब प्रशंसक खुश हैं। हालाँकि, मैं ReactOS स्रोत कोड खोलता हूं और कई स्थानों पर दूषित स्वरूपण देखता हूं। क्यों?





उत्तर स्पष्ट है। क्योंकि यह याद रखना मुश्किल है कि टीएबी को कहां दबाया जाए, और कुछ जगहों को कहां रखा जाए, अगर यह एकमात्र परियोजना नहीं है जिसके साथ आप काम करते हैं। इसलिए लोग लगातार गलतियाँ करते हैं। और यदि ऐसा है, तो सिद्धांतकारों के लिए कुछ भी नहीं है, लेकिन आपको चिकित्सक बनना होगा। सामान्य रूप से टैब के उपयोग को लेना और प्रतिबंधित करना आवश्यक है। और फिर सभी के लिए सब कुछ समान होगा, और अपराधी, जो सारणीकरण का उपयोग करना शुरू कर देता है, उसे ढूंढना और उसे सुझाव देना आसान है।

यह कोड के डिजाइन में एक कदम पीछे नहीं है! यह एक कदम आगे है! यह जागरूकता का अगला स्तर है। कस्टम इंडेंटेशन की सैद्धांतिक सुंदरता अभ्यास के साथ संगत नहीं है। सबसे पहले, एक बड़ी टीम में कोड की सहज प्रस्तुति और विकास में आसानी सुनिश्चित करना महत्वपूर्ण है। Google इसे समझता है। और उनका मानक प्रारूपण [ 5 ] के लिए केवल रिक्त स्थान का उपयोग करता है। टैब के उपयोग की वकालत करने वालों के लिए, मैं एक बार फिर से यह सोचने की सलाह देता हूं कि क्रोमियम विकसित करने वाले उच्च श्रेणी के पेशेवरों की वितरित टीम ने ठीक अंतराल को क्यों चुना।

और एक बार और। कस्टम इंडेंटेशन की सैद्धांतिक सुंदरता अभ्यास के साथ संगत नहीं है। इससे कोई फर्क नहीं पड़ता कि कोई सिद्धांत कितना सुंदर लगता है अगर वह काम नहीं करता है। और यह वास्तव में ReactOS के साथ मामला है।

मेरा सुझाव है कि रिएक्टोस विकास टीम अपने मानक को संशोधित करती है और टैब का उपयोग करना बंद कर देती है। किसी भी टैब को एक त्रुटि के रूप में माना जाना चाहिए और कोड से हटा दिया जाना चाहिए।

वैसे, यह अभ्यास आपको रिएक्टोस कोड में इस तरह के मतभेदों को खोजने की अनुमति देगा:

 BOOLEAN KdInitSystem(IN ULONG BootPhase, IN PLOADER_PARAMETER_BLOCK LoaderBlock) { ... /* Check if this is a comma, a space or a tab */ if ((*DebugOptionEnd == ',') || (*DebugOptionEnd == ' ') || (*DebugOptionEnd == ' ')) ... } 

अंतिम तुलना एक टैब वर्ण के साथ एक तुलना है, और अंतरिक्ष के साथ नहीं, जैसा कि यह लग सकता है। सामान्य कोड इस तरह दिखना चाहिए: "(* DebugOptionEnd == '\ t')"।

टैब के लिए ध्यान दें। मुझे फिर से यह बताने की आवश्यकता नहीं है कि टैब का सही उपयोग कैसे करें। और यह मेरा कोड नहीं है। देखिए, एक बहुत विशिष्ट रिएक्टोस परियोजना है। इसमें खराब स्वरूपित कोड है। इस बारे में सोचें कि नए प्रोग्रामर के लिए प्रोजेक्ट कोड को खोलने के लिए क्या संभव होगा और संपादक सेटिंग्स में सेट किए जाने वाले टैब चरित्र के किस आकार का अनुमान लगा सकते हैं। "आपको तुरंत सही लिखना पड़ा" की भावना में विचार का कोई व्यावहारिक मूल्य नहीं है।

ग्रंथ सूची

1. ReactOS N79 न्यूज़ रिलीज़। आवरण में स्थैतिक विश्लेषण। http://www.viva64.com/go.php?url=722
2. यह कोड में टैब के बजाय रिक्त स्थान को टाई करने का समय है। http://www.viva64.com/go.php?url=725
3. यह कोड में टैब का उपयोग करने के लिए टाई करने का समय है। http://www.viva64.com/go.php?url=726
4. ReactOS। कोडिंग स्टाइल। http://www.viva64.com/go.php?url=724
5. Google C ++ स्टाइल गाइड। http://www.viva64.com/go.php?url=679