एक सुंदर संहिता पर विचार

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

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

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

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

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

आपको सुंदर कोड लिखने की आवश्यकता है ... यदि संभव हो तो।

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

मेरा मानना ​​है कि एक सुंदर कोड चाहिए ...

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

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

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

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

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

मेरा मानना ​​है कि एक सुंदर कोड कर सकते हैं ...

ओह, यह आम तौर पर यहाँ मजेदार है। आदर्श के बारे में बात करना अच्छा है, दूसरों को सिखाना अच्छा है ... लेकिन हम सभी पापी हैं। जिसने एक विकल्प बनाने के बजाय एक कठिन अर्थ निर्धारित नहीं किया है - उसे पहले मुझ पर एक पत्थर फेंकने दो। "सुंदर कोड" के पापों के बारे में बात करते हैं।

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

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

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

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

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

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

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

संक्षिप्त सारांश

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

पुनश्च

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