कयामत 3 स्रोत कोड की असाधारण सुंदरता

आज आप कयामत 3 के स्रोत कोड के बारे में एक कहानी की प्रतीक्षा कर रहे हैं और यह कितना सुंदर है।
हाँ, सुंदर । मुझे समझाने की।

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

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

डायएड को विकसित करने के अंतिम 6 हफ्तों में , मैंने कोड की 13k लाइनें जोड़ी हैं। मुख्य मेनू MainMenu.cc का केवल एक स्रोत 25 501 लाइनों को फुलाया है। एक बार, सुंदर कोड #ifdef के सभी प्रकारों की वास्तविक गड़बड़ी में बदल गया, कार्य करने के लिए संकेत, बदसूरत SIMDs और कोडांतरक आवेषण - और मैंने खुद के लिए एक नया शब्द खोजा "कोड एन्ट्रॉपी"। इस सब पर एक दुखी नज़र के साथ, मैं अन्य परियोजनाओं की तलाश में इंटरनेट पर एक यात्रा पर गया, जो मुझे यह समझने में मदद करेगा कि अन्य डेवलपर्स खूबसूरती से कोड की सैकड़ों हजारों लाइनों का प्रबंधन कैसे कर रहे हैं। लेकिन जब मैंने बड़े खेल इंजनों की एक जोड़ी के लिए कोड को देखा, तो मैं निराश हो गया; मेरा "भयानक" स्रोत कोड बाकी की तुलना में भी साफ था!

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

मैंने डूम 3 स्रोत कोड का अध्ययन करने और फैबियन के लेखों को पढ़ने में कई दिन बिताए, जिसके बाद मैंने ट्वीट किया:

मैंने कुछ समय डूम 3 स्रोत का अध्ययन करने में बिताया। यह शायद मैंने कभी देखा है सबसे सहज और प्यारी कोड है।

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

***
आपको कुछ विचार प्राप्त करने के लिए: डायड में कोड की 193k लाइनें शामिल हैं, सभी C ++ में। डूम 3 - 601k, क्वेक III - 229k और क्वेक II - 136k। ये बड़े प्रोजेक्ट हैं।

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

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

IdTech 4 के लिए, कोड मानक सार्वजनिक रूप से ( .doc ) उपलब्ध हैं और मैं उन्हें सभ्य पढ़ने के रूप में सुझा सकता हूं। मैं इनमें से अधिकांश मानकों पर जाऊंगा और यह समझाने की कोशिश करूंगा कि वे कयामत 3 कोड को इतना सुंदर कैसे बनाते हैं।

यूनिवर्सल पार्सिंग और पार्सिंग

कयामत में मैंने जो सबसे स्मार्ट चीजें देखीं, उनमें से एक है पूरे कार्यक्रम में उनके लेक्सिकल एनालाइजर और पार्सर का इस्तेमाल। सभी संसाधन फ़ाइलें एक सिंटैक्स वाली ascii फाइलें हैं: स्क्रिप्ट, एनीमेशन फाइलें, कॉन्फ़िगरेशन, आदि। सभी समान। यह आपको एक ही कोड के साथ सभी फाइलों को पढ़ने और प्रोसेस करने की अनुमति देता है। पार्सर विशेष रूप से विश्वसनीय है, और C ++ के मुख्य सबसेट का समर्थन करता है। एकल पार्सर और लेक्सिकल विश्लेषक के पालन से इंजन के अन्य घटकों को डेटा को क्रमबद्ध करने में चिंता न करने में मदद मिलती है, क्योंकि एप्लिकेशन के इस हिस्से के लिए जिम्मेदार कोड पहले ही लिखा जा चुका है। इसके लिए धन्यवाद, बाकी कोड बहुत स्पष्ट हो जाता है।

कांस्टिट और सख्त पैरामीटर (कठोर पैरामीटर)

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



बस इस सुविधा को परिभाषित करने से मुझे खुशी होती है!

केवल कुछ चीजें जो तुरंत मेरी आंख को पकड़ती हैं, वे पहले से ही बहुत कुछ स्पष्ट करती हैं:

• idPlane को एक अपरिवर्तनीय तर्क के रूप में कार्य में लाया जाता है। मैं इस फ़ंक्शन को idPlane परिवर्तनों की जांच किए बिना कॉल करने के बाद सुरक्षित रूप से उसी विमान का उपयोग कर सकता हूं।
• मुझे पता है कि एप्सिलॉन को फ़ंक्शन के अंदर नहीं बदला जाएगा (इस तथ्य के बावजूद कि इसे किसी अन्य चर के लिए समस्याओं के बिना कॉपी किया जा सकता है और इसे शुरू करने के लिए इस्तेमाल किया जा सकता है - यह विधि अनुत्पादक होगी)
• आगे, पीछे, frontOnPlaneEdges और backOnPlaceEdges OUTPUT चर हैं। उन्हें दर्ज किया जाएगा।
• पैरामीटर सूची के बाद अंतिम कॉन्स्ट संशोधक मेरा पसंदीदा है। यह इंगित करता है कि idSurface :: स्प्लिट () सतह को स्वयं बदलने में सक्षम नहीं होगा। यह C ++ में मेरी पसंदीदा विशेषताओं में से एक है जो मुझे अन्य भाषाओं में बहुत याद आती है। वह मुझे ऐसा कुछ करने देती है:
  शून्य च (const idSurface & s) {
  s.Split (....);
  }
  
  यदि स्प्लिट को स्प्लिट (...) कॉन्स्ट के रूप में परिभाषित नहीं किया जाएगा; यह कोड संकलित नहीं होगा। अब मुझे हमेशा पता चलेगा कि किसी भी कॉल टू f () सतह को नहीं बदलेगी, भले ही f () किसी अन्य फ़ंक्शन द्वारा सतह को पास किया गया हो या किसी भी सरफेस :: विधि () विधियों को कॉल करता हो। कॉन्स्ट मुझे इस सुविधा के बारे में बहुत कुछ बताता है और समग्र प्रणाली वास्तुकला के बारे में संकेत भी देता है। इस फ़ंक्शन की घोषणा के एक पढ़ने से यह स्पष्ट हो जाता है कि सतहों को विमानों द्वारा गतिशील रूप से अलग किया जा सकता है। मूल सतह को बदलने के बजाय, नई सतहों को हमारे सामने लौटाया जाएगा - सामने और पीछे, और संभवतः, साइड फ्रंटऑनप्लेडेज और बैकऑनप्लेनएजेस।

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

न्यूनतम टिप्पणियां

यह पैराग्राफ, बेशक, अभी भी कोड लेखन शैली के मुद्दों के साथ अधिक चिंतित है, लेकिन फिर भी, कयामत में इतनी अद्भुत बात है कि अत्यधिक टिप्पणी की कमी है। मेरे व्यवहार में, मुझे बहुत अधिक कोड का सामना करना पड़ा है जो निम्न के समान है:

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

// सतह को आगे और पीछे की सतहों में विभाजित करता है, सतह ही अपरिवर्तित रहती है
// frontOnPlaneEdges और backOnPlaneEdges वैकल्पिक रूप से उन अनुक्रमणिकाओं को संग्रहीत करते हैं जो विभाजन विमान के किनारों पर स्थित हैं।
// रिटर्न SIDE_?

पहली पंक्ति पूरी तरह से बेमानी है। हम एक फ़ंक्शन की परिभाषा से पहले से ही यह सब जानते हैं। दूसरी और तीसरी पंक्ति कुछ नई जानकारी ले जाती है। हम दूसरी पंक्ति को हटा सकते हैं, लेकिन यह संभावित अस्पष्टता का कारण बन सकता है।

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

इंडेंट

डूम स्क्रीन के मुक्त ऊर्ध्वाधर स्थान को बर्बाद करने के लिए इच्छुक नहीं है।
यहाँ t_stencilShadow :: R_ChopWinding () से एक उदाहरण दिया गया है:



मैं समस्याओं के बिना पूरे एल्गोरिथ्म को पढ़ सकता हूं, क्योंकि यह मेरी स्क्रीन के 1/4 पर फिट बैठता है, अन्य 3/4 को छोड़कर यह समझने के लिए कि यह कोड अपने परिवेश से कैसे संबंधित हो सकता है। मैंने अपने जीवन में इसे बहुत देखा है:



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

दूसरी विधि पहले में 11 लाइनों के संबंध में 18 लाइनें लेती है। समान कार्यक्षमता वाले कोड की कई पंक्तियों के लगभग दो बार। इसके अलावा, कोड का अगला टुकड़ा स्पष्ट रूप से मेरी स्क्रीन पर फिट नहीं होगा। और इसमें क्या है?



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

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



मुझे आईडी कोड में एक भी उदाहरण नहीं मिला जहां वे कम से कम {} को याद करेंगे। यदि हम अतिरिक्त {} को छोड़ देते हैं, तो उस समय () ब्लॉक को पार्स करने में जितना चाहिए, उससे कई गुना अधिक समय लगेगा। इसके अलावा, कोई भी संशोधन वास्तविक पीड़ा में बदल जाता है - यह कल्पना करने के लिए पर्याप्त है कि यदि पथ (c> d) है तो मुझे एक और शर्त डालनी होगी।

टेम्पलेट्स का न्यूनतम उपयोग

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



C ++ 11 में, एक ही चीज़ बहुत आसान लगती है:



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

Std :: वेक्टर से मान हटाना भी भयानक है:



कल्पना कीजिए, प्रत्येक प्रोग्रामर को हर बार इस लाइन को सही ढंग से लिखना चाहिए!

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

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

आईडी इस समस्या को कैसे हल करता है? वे बस अपने कार्यों को सामान्य बनाने के लिए एक "आम भाजक" के लिए सब कुछ लाने की कोशिश नहीं करते हैं। उनके पास हैशटेबल और हैशंडेक्स कक्षाएं हैं, पहले के लिए मुख्य प्रकार की आवश्यकता होती है कॉन्स्ट चर् *, और दूसरी - जोड़ी इंट-> इंट। C ++ के मामले में, यह निर्णय बुरा माना जाता है - "होना चाहिए" एक एकल वर्ग हैशटेबल है, और इसमें KeyType = const char * और <int, int> के लिए दो अलग-अलग प्रसंस्करण लिखें। लेकिन आईडी ने जो किया वह भी सही था, और इसके अलावा, उनके कोड को कई गुना अधिक सुंदर बना दिया।

यह सुनिश्चित करना आसान है, बस हैश और जिस तरह से आईडी के साथ काम करने के लिए "अच्छी सी ++ प्रोग्रामिंग शैली" के बीच विपरीत का पता लगाएं।

कई लोगों के लिए, एक हैशटेबल के पैरामीटर के रूप में पारित की जा सकने वाली गणना का एक विशेष वर्ग बनाना एक अच्छा विचार होगा:



इसे एक विशिष्ट प्रकार के रूप में निर्दिष्ट किया जा सकता है:



अब आप ComputeHashForType को हैशटेबल के लिए HashComputer के रूप में पास कर सकते हैं:



इसी तरह, मैंने इसे घर पर किया। यह एक स्मार्ट निर्णय की तरह दिखता है, लेकिन ... कितना बदसूरत! यदि हम टेम्पलेट में बड़ी संख्या में मापदंडों से निपटते हैं तो क्या होगा? एक मेमोरी एलोकेटर के साथ? डिबगिंग के साथ? तब हमें कुछ ऐसा मिलता है:



एक फ़ंक्शन की क्रूर परिभाषा, है ना?



तो यह सब क्यों है? मैं उज्ज्वल सिंटैक्स हाइलाइट के बिना एक विधि का नाम शायद ही पा सकता हूं। यह संभावना है कि एक फ़ंक्शन की परिभाषा उसके शरीर की तुलना में अधिक स्थान लेगी। निश्चित रूप से पढ़ने के लिए कठिन है और बहुत सुंदर नहीं है।

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



और



और आपने उन्हें एक साथ इस्तेमाल किया और कुछ इस तरह किया:



शायद StringAllocator नाम का StringHashTable मेमोरी एलोकेटर वैश्विक मेमोरी के लिए अनुकूल नहीं है, जो आपको भ्रमित कर सकता है। आपको पूरे कोड को देखना होगा, यह पता लगाना होगा कि StringHashTable वास्तव में जटिल टेम्प्लेट में से एक टाइपराइफ है, टेम्पलेट के स्रोत कोड के माध्यम से जाएं, एक अन्य एलोकेटर ढूंढें, इसका विवरण ढूंढें ... एक बुरा सपना, बस एक बुरा सपना।

कयामत C ++ तर्क के सिद्धांतों के लिए काउंटर चलाता है: कोड जितना संभव हो उतना विशिष्ट लिखा जाता है, सामान्यीकरण का उपयोग केवल वहीं करता है जहां यह समझ में आता है। कयामत से हैशटेबल क्या होता है जब उसे हैश या कुछ और उत्पन्न करने की आवश्यकता होती है? इसे idStr :: GetHash () कहते हैं, क्योंकि केवल एक ही प्रकार की कुंजी इसे स्वीकार करती है, वह है कॉन्स्टर्ड *। यदि दूसरी कुंजी की आवश्यकता हो तो क्या होगा? यह मुझे लगता है कि वे कुंजी को टेम्पलेट देते हैं और बस key.getHash () को बल देते हैं, और कंपाइलर सुनिश्चित करता है कि कुंजी प्रकार में int getHash () विधि है।

सी से "विरासत" में अवशेष

मुझे ठीक से पता नहीं है कि 90 के दशक में कितने आईडी प्रोग्रामर अब कंपनी में काम करते हैं, लेकिन कम से कम जॉन कार्मैक को सी। में व्यापक प्रोग्रामिंग अनुभव है। क्वेक III से पहले सभी आईडी गेम सी में लिखे गए थे। मैं C ++ प्रोग्रामर से मिला हूं, जो इसे नहीं करते हैं। C में प्रोग्रामिंग का बहुत अनुभव था, इसलिए उनका कोड भी C ++ zirovanny था। पिछला उदाहरण सिर्फ कई में से एक था - यहां अन्य हैं जो मुझे अक्सर मिलते हैं:

• बहुत बार प्राप्त / सेट विधियों का उपयोग करना
• स्ट्रिंगस्ट्रीम का उपयोग करना
• अत्यधिक ऑपरेटर ओवरलोड।

आईडी सख्ती से इन सभी मामलों की निगरानी करता है।

अक्सर ऐसा होता है कि कोई व्यक्ति इस तरह से एक वर्ग बनाता है:



यह कोड की पंक्तियों और इसे पढ़ने के लिए बाद के समय की बर्बादी है। यह विकल्प आपके समय से अधिक खा जाएगा



लेकिन क्या होगा अगर आपको अक्सर कुछ संख्या n से var बढ़ाना पड़े?



की तुलना में



पहला उदाहरण लिखने और पढ़ने में बहुत आसान है।

आईडी स्ट्रिंगस्ट्रीम का उपयोग नहीं करता है। स्ट्रिंगस्ट्रीम में ऑपरेटर अधिभार के सबसे महत्वपूर्ण "कमीने" में से एक है, जिसका मैंने सामना किया है: <<।

उदाहरण के लिए



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



बहुत बेहतर!

<< SomeClass के लिए संचालक का वाक्यविन्यास हास्यास्पद आता है:



[नोट: जॉन कार्मैक ने एक बार देखा कि सांख्यिकीय कोड विश्लेषण कार्यक्रमों ने यह पता लगाने में मदद की कि उनके सामान्य बग प्रिंटफ () में मापदंडों के गलत मिलान के कारण हुए थे। मुझे आश्चर्य है कि अगर रेज में स्ट्रिंगस्ट्रीम पर स्विच किया जाए।इसके कारण? .. GCC और क्लैंग दोनों एक समान त्रुटि संदेश देते हैं, जब-जब ध्वज का उपयोग किया जाता है, तो आप इन त्रुटियों को खोजने के लिए महंगे विश्लेषणकर्ताओं का सहारा लिए बिना खुद को देख सकते हैं।]

एक अन्य सिद्धांत जो कयामत कोड है। बहुत सुंदर, यह ऑपरेटर अधिभार का एक न्यूनतम उपयोग है। C ++ में शुरू की गई यह बहुत लोकप्रिय और सुविधाजनक सुविधा आपको कुछ ऐसा करने की अनुमति देती है:



ओवरलोडिंग के बिना, ये ऑपरेशन कम स्पष्ट हो जाएंगे और लिखने और पढ़ने के लिए अधिक समय की आवश्यकता होगी। यहाँ कयामत हैऔर रुक जाता है। मैंने कोड देखा जो आगे जाता है। मैंने कोड देखा कि वैक्टर के स्केलर उत्पाद, या वेक्टर * वेक्टर ऑपरेटर जो वेक्टर गुणा करता है, को दर्शाने के लिए '%' ऑपरेटर को ओवरलोड करता है। इस तरह की कार्रवाई के लिए ऑपरेटर * शुरू करने का कोई मतलब नहीं है, जो केवल 3 डी में संभव होगा। आखिरकार, यदि आप कुछ_2d_vec * some_2d_vec करना चाहते हैं, तो आप क्या करने का आदेश देंगे? 4d या अधिक के बारे में क्या? इसीलिए आईडी से न्यूनतम हस्तक्षेप का सिद्धांत सही है - यह हमें कोई अस्पष्टता नहीं छोड़ता है।

क्षैतिज इंडेंटेशन

डूम स्रोत कोड से मैंने जो सबसे महत्वपूर्ण चीजें सीखीं, उनमें से एक साधारण शैली का बदलाव था। मुझे लगता है कि मेरी कक्षाएं कुछ इस तरह से उपयोग की जाती हैं: कयामत 3 के



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



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



मैं स्वयं कीबोर्ड पर पात्रों के अत्यधिक सेट के खिलाफ हूं। मुख्य बात यह है कि मुझे अपना काम जल्द से जल्द करना है - लेकिन इस स्थिति में, टाइपिंग के साथ थोड़ी हलचल तब होती है जब कक्षा को परिभाषित करते समय एक या दो से अधिक बार भुगतान करना पड़ता है यदि प्रोग्रामर को कक्षा की परिभाषा को देखना है। कयामत 3 कोडिंग मानकों ( .doc ) दस्तावेज़ में वर्णित कोडिंग शैली के कई और उदाहरण हैं, जो Doom 3 स्रोत कोड के सभी सौंदर्य के लिए ज़िम्मेदार है ।

विधि नाम

मेरी राय में, कयामत में तरीकों के नामकरण के नियमों में अभी भी कुछ कमी है। व्यक्तिगत रूप से, मैं अपने काम में इस तरह के नियम का उपयोग करना पसंद करता हूं: सभी विधि के नाम क्रियाओं से शुरू होने चाहिए, और अपवाद केवल ऐसे मामले हैं जब यह नहीं किया जा सकता है।

उदाहरण के लिए:



इससे बहुत बेहतर:

हां, वह अविश्वसनीय रूप से सुंदर है।

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

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

मैं सभी को कयामत 3 के स्रोत कोड को देखने की सलाह देना चाहूंगा, क्योंकि आप हर दिन ऐसा स्रोत कोड नहीं देखते हैं: यहां आपके पास वर्णों के बीच सिस्टम आर्किटेक्चर डिज़ाइन से लेकर टैब तक का पूरा सेट है।

शॉन मैक्ग्रा ( शॉन मैक्ग्रा राज्य द्वारा ) - गेम डेवलपर, जो टोरंटो में रहता है, प्लेस्टेशन 3 के लिए लोकप्रिय साइकेडेलिक खेल के निर्माता - पहेली दौड़ युग्म । हम आपको सलाह देते हैं कि आप उसके खेल पर नज़र डालें और ट्विटर पर उसका अनुसरण करें ।

नोट

लगभग। जॉन कार्मैक

धन्यवाद! कुछ टिप्पणियाँ:

मैं यह सोचना जारी रखता हूं कि एक निश्चित तरीके से, क्वेक 3 कोड अभी भी बेहतर है, क्योंकि यह मेरी सी-शैली के विकास का शिखर बन गया है - सी ++ में इंजन को प्रोग्राम करने के पहले प्रयास के विपरीत, लेकिन यह केवल पहले की छोटी लाइनों के कारण मेरा भ्रम हो सकता है , या इस तथ्य के लिए धन्यवाद कि मैंने इसे एक दर्जन वर्षों से नहीं देखा है। मुझे लगता है कि "अच्छा सी ++" पठनीयता के मामले में "अच्छा सी" से बेहतर है, जबकि बाकी भाषाएं समान हैं।

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

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

अब मैं एक भयानक कास्ट नाज़ी बन गया हूं, और मैं किसी भी प्रोग्रामर को रिपोर्ट करता हूं जो वैरिएबल या पैरामीटर को स्थिर नहीं बनाता है, अगर वे ऐसा कर सकते हैं।

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

[ www.altdevblogaday.com ]

लगभग। अनुवाद

मैं खुद डेढ़ साल पहले फैबियन के ब्लॉग पर आया था, और मैं इसे सुरक्षित रूप से सभी के लिए सुझा सकता हूं, जो रुचि रखते हैं - यदि विचारशील पढ़ने के लिए नहीं है, तो कम से कम प्रेरणा के लिए।
"क्लीन" कोड के बारे में - ट्विटर पर, मैंने कार्मैक से इतना समय पहले नहीं पूछा था कि वह किस विषय पर पढ़ने की सलाह देगा। उन्होंने पुस्तक "आर्ट ऑफ़ द रीडेबल कोड" ( अमेज़ॅन ) की दृढ़ता से सलाह दी।