🔋 🖲️ 🥔 2020 में "क्लीन कोड" क्या है? 🦃 👩🏼‍🔧 🏩

^{"क्लीन कोड" और एक साफ बिल्ली}

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

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

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

अप्रैल में, अंकल बॉब हमारे तीन सम्मेलनों में बोलने के लिए सेंट पीटर्सबर्ग जाएंगे और वे सिर्फ तीन अलग-अलग दिशाओं में ( .NET विकास के बारे में, परीक्षण के बारे में और जावास्क्रिप्ट के बारे में ) हैं। इसलिए, हमने इन सम्मेलनों के कई वक्ताओं से पूछा कि 2020 में उद्योग विशेषज्ञों की राय की तुलना करने के लिए उनके लिए कौन सा स्वच्छ कोड है।

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

UPD: , . , . - . . 13 , .

DotNext

जॉन एक ढेर अतिप्रवाह किंवदंती है, गहराई में C # के लेखक और ग्रह के सबसे प्रसिद्ध दाताओं में से एक है। उन्होंने हमें यह परिभाषा दी:

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

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

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

एंड्री अकिंशिन

DotNext आगंतुकों को आंद्रेई को पेश करने की आवश्यकता नहीं है, लेकिन बाकी के लिए हम आपको बताएंगे कि वह आईडीई राइडर , बेंचमार्कडॉटनेट लाइब्रेरी , ज्वलंत रिपोर्टों और पुस्तक "प्रो .NET बेंचमार्क" पर अपने काम के लिए जाना जाता है ।

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

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

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

डायलन बीट्टी

हेब्रैकटेटेली ने विरासत कोड के साथ काम के बारे में अपनी विचारशील और ज्वलंत रिपोर्ट पर डायलन को याद कर सकते हैं: हेब्रा के लिए हमने अपना डिकोडिंग किया था । और जब हमने स्वच्छ कोड के बारे में डायलन की ओर रुख किया, तो उसने एक ऐसा विस्तृत और विचारशील पाठ लिखा, जो इसे कम से कम एक अलग पोस्ट में प्रकाशित करता है:

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

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

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

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

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

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

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

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

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

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

heisenbug

यह "परीक्षकों के लिए न केवल परीक्षण परीक्षण" है: यह परीक्षण और विकास के चौराहे पर है। इसलिए, इसके कई वक्ता एक ही बार में इन दोनों दुनिया की बारीकियों को समझते हैं।

इवान क्रुतोव और अन्ना चेर्नशेवा

इवान और अन्ना विभिन्न कंपनियों में काम करते हैं, लेकिन कुछ उन्हें एकजुट करता है: दोनों सेलेनियम के बारे में बहुत कुछ जानते हैं। हमने एक ही समय में उनके साथ बात की, इसलिए हमें एक संयुक्त परिभाषा मिली:

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

अन्ना: "यह मुझे लगता है: यह एक कोड है जिसे आप जल्दी से समझ सकते हैं, बग को ठीक कर सकते हैं, आसानी से इसका विस्तार कर सकते हैं, इसे पूरक कर सकते हैं।"

इवान: "आप यह भी कह सकते हैं कि यह एक" कोड है जिसके लिए आप शर्मिंदा नहीं हैं। " आम तौर पर वे कहते हैं कि यदि आप उस कोड को देखते हैं जो आपने छह महीने पहले लिखा था और घबराए नहीं हैं, तो आप विकास नहीं कर रहे हैं। यह पता चलता है कि हर साल आपका कोड क्लीनर बन जाना चाहिए। ”

सेबस्टियन डैशनर

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

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

एंड्री लुश्निकोव

एंड्री एक ब्राउज़र ऑटोमेशन टूल Playwright पर काम कर रहा है, जिसके बारे में हमने हाल ही में लिखा था । उनकी परिभाषा सबसे संक्षिप्त है:

“स्वच्छ कोड गूंगा है, बहुत समझ में आता है। और बेहतर डम्बर। ”

एलेक्जेंड्रा स्वेटिकोवा

अलेक्जेंड्रा Odnoklassniki में एक सूचना सुरक्षा विशेषज्ञ है, जिसने "जावा डेवलपर के रूप में आईटी में शुरुआत की, लेकिन गलत तरीके से बदल दिया।" इसकी परिभाषा यह निकली:

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

वास्तव में, इसका मतलब है कि कोड संरचित, संक्षिप्त है, आम तौर पर उस भाषा के लिए स्वीकृत प्रथाओं का पालन करता है, जिसमें निहित निर्भरता या साइड इफेक्ट्स नहीं होते हैं और परीक्षण द्वारा कवर किया जाता है। "

Holyjs

एंड्री मेलिखोव

आंद्रेई देवशक्त प्रोजेक्ट के लिए कई जाने जाते हैं । यह आश्चर्य की बात नहीं है कि देवशक्त पॉडकास्ट में अपने विचारों को निरंतर रूप देने वाले एक व्यक्ति ने स्पष्ट रूप से अपनी स्थिति बताई:

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

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

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

एलेक्जेंड्रा कालिनिना

एलेक्जेंड्रा होल्जस कार्यक्रम समिति का सदस्य है, उसे प्रोग्रामिंग में व्यापक अनुभव है - और हालांकि वह हाइजेनबग के साथ नहीं है, वह टेस्टहैंड (इकाई, एकीकरण, ई 2 ई, बी 2 बी) को भी जानती है। यहाँ उसका पाठ है:

“स्वच्छ कोड अब एक सरल अवधारणा है, लेकिन इसे समझना मुश्किल है। ऐसा लगता है कि स्वच्छ नियम निम्नलिखित नियमों का पालन करके प्राप्त किया जा सकता है:

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

निकोलो रिबोडो

निकोलो, जबकि अभी भी एक छात्र, बाबेल कंपाइलर के प्रमुख डेवलपर्स में से एक बन गया (हमने पहले से ही उसके बारे में अलग से पूछा था )। उसका संस्करण यह निकला:

“एक साफ कोड एक कोड है जिसे आसानी से छोटे परमाणु घटकों में विभाजित किया जा सकता है।

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

प्रोग्रामिंग भाषा या प्रतिमान की परवाह किए बिना कोड को साफ किया जा सकता है: परमाणुओं को छोटे ऑब्जेक्ट्स, फ़ंक्शंस, या यहां तक कि कोड के छोटे टुकड़ों के रूप में लागू किया जा सकता है जो सिंथेटिक रूप से पृथक नहीं हैं। "

निष्कर्ष

अंत में, जब राय एकत्र की गई, तो हमने उन्हें खुद अंकल बॉब को दिखाया और पूछा कि क्या वह कुछ कहना चाहते हैं। जवाब निकला:

“मैं ऊपर टिप्पणीकारों का पूरा समर्थन करता हूं। मैं केवल एक ही बात जोड़ूंगा कि माइकल फेदर्स ने एक बार कहा था: "एक साफ कोड हमेशा ऐसा दिखता है जैसे यह एक व्यक्ति द्वारा लिखा गया था जो परवाह करता है।"

उनका निष्कर्ष बहुत अनुकूल लगता है। लेकिन स्वच्छ संहिता एक ऐसा बहस का विषय है कि जब आप में से कोई एक सिर हिलाता है, तो शायद कोई और आग लग जाए, ऐसा कुछ महसूस करना:

« : „ , ”. , , : . , !»
« „ ”? „” , — , , „” — !»
"शब्द" आप अपने धक्कों को भर सकते हैं, जबकि अन्य घबराहट के साथ दिखते हैं "ध्वनि अपमानजनक, जैसे कि केवल मूर्ख ऐसा करते हैं। लेकिन जब आप अपने शंकु को भरते हैं और उनके कारणों को समझते हैं, तो सभी बेहतरीन और अभिनव दिखाई देते हैं, और न केवल पुरानी पुस्तकों का पालन करें! "

UPD 12 मार्च: हालांकि अंकल बॉब हमारे लिए उड़ान नहीं भर सकते हैं, हमारे सेंट पीटर्सबर्ग सम्मेलन ( .NET डेवलपर्स , परीक्षक और जावास्क्रिप्ट डेवलपर्स के लिए ) स्वच्छ कोड के साथ विवाद की संभावना नहीं है । सम्मेलन स्थलों पर - हमेशा कार्यक्रमों के अप-टू-डेट संस्करण। बने रहें और हमारे न्यूज़लेटर्स की सदस्यता लें - सप्ताह में एक बार हम बदलावों के बारे में बात करेंगे।

2020 में "क्लीन कोड" क्या है?