🍴 🐌 👩🏼‍🤝‍👩🏻 कोड कब सराहनीय है? ↖️ 💩 🍕

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

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

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

डेवलपर्स के उत्तर, साथ ही लेखों के शब्दांकन, कोड की पठनीयता और संरचना, तार्किक निर्माणों की लालित्य, आधुनिक प्रोग्रामिंग भाषाओं की सभी विशेषताओं का उपयोग और डिजाइन की एक निश्चित शैली से संबंधित है।

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

90 का उदाहरण

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

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

यह उदाहरण अभी भी कोड के रूप में संदर्भित नहीं करता है, बल्कि एल्गोरिथ्म के लिए, इसलिए हम इस पर अधिक विस्तार से ध्यान नहीं देंगे।

लिनक्स सब कुछ का प्रमुख है!

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

उदाहरण के लिए, लिनक्स कर्नेल से memory.c फाइल पर विचार करें, जो कि स्मृति प्रबंधन सबसिस्टम से संबंधित है।

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

static void tlb_remove_table_one(void *table) {     /*      * This isn't an RCU grace period and hence the page-tables cannot be      * assumed to be actually RCU-freed.      *      * It is however sufficient for software page-table walkers that rely on      * IRQ disabling. See the comment near struct mmu_table_batch.      */     smp_call_function(tlb_remove_table_smp_sync, NULL, 1);     __tlb_remove_table(table); }

2. कोड में बहुत अधिक टिप्पणियां नहीं हैं, लेकिन जो आमतौर पर उपयोगी हैं। वे, एक नियम के रूप में, एक ऐसी क्रिया का वर्णन करते हैं जो कोड से पहले से ही स्पष्ट है (एक बेकार टिप्पणी का क्लासिक उदाहरण cnt ++; // वेतन वृद्धि काउंटर)), लेकिन इस कार्रवाई का संदर्भ यह है कि यहां ऐसा क्यों किया जा रहा है, क्यों किया जा रहा है, क्यों? यहां, यह किन मान्यताओं के साथ उपयोग किया जाता है, कोड में अन्य किन स्थानों से जुड़ा हुआ है। उदाहरण के लिए:

 /** * tlb_gather_mmu - initialize an mmu_gather structure for page-table tear-down * @tlb: the mmu_gather structure to initialize * @mm: the mm_struct of the target address space * @start: start of the region that will be removed from the page-table * @end: end of the region that will be removed from the page-table * * Called to initialize an (on-stack) mmu_gather structure for page-table * tear-down from @mm. The @start and @end are set to 0 and -1 * respectively when @mm is without users and we're going to destroy * the full address space (exit/execve). */ void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,            unsigned long start, unsigned long end)

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

 /* * demand-loading started 01.12.91 - seems it is high on the list of * things wanted, and it should be easy to implement. - Linus */ /* * Ok, demand-loading was easy, shared pages a little bit tricker. Shared * pages started 02.12.91, seems to work. - Linus. * * Tested sharing by executing about 30 /bin/sh: under the old kernel it * would have taken more than the 6M I have free, but it worked well as * far as I could see. * * Also corrected some "invalidate()"s - I wasn't doing enough of them. */

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

BUG_ON मैक्रो आमतौर पर रजिस्टरों की सामग्री और स्टैक को प्रिंट करने का कारण बनता है और या तो पूरे सिस्टम या प्रक्रिया को रोकता है जिसके संदर्भ में संबंधित कॉल हुई। शर्त सही होने पर WARN_ON मैक्रो बस कर्नेल लॉग को संदेश जारी करता है। मैक्रोज़ WARN_ON_ONCE और कई अन्य भी हैं, जिनमें से कार्यक्षमता नाम से स्पष्ट है।

 void unmap_page_range(struct mmu_gather *tlb, ….     unsigned long next;    BUG_ON(addr >= end);    tlb_start_vma(tlb, vma); int apply_to_page_range(struct mm_struct *mm, unsigned long addr, …    unsigned long end = addr + size;    int err;    if (WARN_ON(addr >= end))        return -EINVAL;

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

4. कर्नेल के सभी मुख्य घटक उपयोगकर्ताओं को एक साधारण इंटरफ़ेस, वर्चुअल फ़ाइल सिस्टम / प्रोक / के माध्यम से उनकी स्थिति के बारे में जानकारी प्रदान करते हैं।

उदाहरण के लिए, स्मृति स्थिति की जानकारी / proc / meminfo फ़ाइल में उपलब्ध है

 user@parallels-vm:/home/user$ cat /proc/meminfo MemTotal:    2041480 kB MemFree:      65508 kB MemAvailable:   187600 kB Buffers:      14040 kB Cached:      246260 kB SwapCached:    19688 kB Active:     1348656 kB Inactive:     477244 kB Active(anon):  1201124 kB Inactive(anon):  387600 kB Active(file):   147532 kB Inactive(file):  89644 kB ….

उपरोक्त जानकारी को स्मृति प्रबंधन सबसिस्टम की कई स्रोत फ़ाइलों में एकत्रित और संसाधित किया जाता है। तो, पहला मेमोटल फ़ील्ड sysinfo संरचना के कुल क्षेत्र का मान है, जो कि page_alloc.c फ़ाइल के si_meminfo फ़ंक्शन से भरा है।

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

लगभग किसी भी प्रणाली का विकास आपके कोड और डेटा की आंतरिक स्थिति के बारे में जानकारी एकत्र करने और प्रदान करने के लिए एक प्रणाली से शुरू होना चाहिए। यह विकास और परीक्षण प्रक्रिया में बहुत मदद करेगा, और, बाद में, ऑपरेशन में।

जैसा कि लिनस ने कहा , “बुरे प्रोग्रामर कोड के बारे में चिंता करते हैं। अच्छे प्रोग्रामर डेटा संरचनाओं और उनके रिश्तों के बारे में चिंता करते हैं। "

5. सभी कोड को कमिट करने से पहले कई डेवलपर्स द्वारा पढ़ा और चर्चा की जाती है। स्रोत कोड परिवर्तन का इतिहास दर्ज और उपलब्ध है। किसी भी रेखा में परिवर्तन होने पर उसकी स्थिति का पता लगाया जा सकता है - क्या बदला, किसके द्वारा, कब, क्यों, किन मुद्दों पर डेवलपर्स द्वारा चर्चा की गई। उदाहरण के लिए, कोड स्मृति में, https://github.com/torvalds/linux/commit/1b2de5d039c883c9d44ae5b2b6eca4ff9bd82dac#diff -983ac52fa16631c1dfa28fc593ddef में परिवर्तन किया गया है। कोड का एक छोटा अनुकूलन किया गया है (मेमोरी लिखने की सुरक्षा को सक्षम करने के लिए एक कॉल तब नहीं होती है यदि मेमोरी पहले से ही संरक्षित है)।

इस कोड के आसपास के संदर्भ को समझने के लिए कोड के साथ काम करने वाले एक डेवलपर के लिए यह हमेशा महत्वपूर्ण होता है कि कोड को किस धारणाओं के साथ बनाया गया, क्या और कब बदला, यह समझने के लिए कि वह किन बदलावों से प्रभावित हो सकता है।

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

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

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

एक कर्नेल डेवलपर के रूप में, सर्वोत्तम प्रथाओं का उपयोग करें और कोड पूरा पढ़ें!

ZY वैसे, आपके पास व्यक्तिगत रूप से एक आदर्श कोड का क्या मापदंड है? अपने विचार कमेंट में शेयर करें।

कोड कब सराहनीय है?

90 का उदाहरण

लिनक्स सब कुछ का प्रमुख है!

More articles: