कोड पठनीयता

कोड का उपयोग इंटरफेस बनाने के लिए किया जाता है। लेकिन कोड ही एक इंटरफ़ेस है।

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

उसी समय, निश्चित रूप से, सभी को एक कोड से निपटना पड़ा जो इन नियमों का अनुपालन करता है, लेकिन किसी कारण से किसी प्रकार की गड़बड़ है।

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

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

इस प्रकार, निर्देशों का एक सेट एक विकल्प नहीं है। इसलिए, हमें कोड पठनीयता की एक व्यापक तस्वीर तैयार करनी होगी।

पठनीयता की आवश्यकता क्यों है

व्यवहार में, अच्छी पठनीयता का आमतौर पर मतलब है कि कोड को पढ़ना अच्छा है। हालाँकि, ऐसी परिभाषा पर कोई दूर तक नहीं जा सकता है: सबसे पहले, यह व्यक्तिपरक है, और दूसरी बात, यह हमें एक साधारण पाठ पढ़ने के लिए बाध्य करता है।

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

पाठ पठनीयता और कोड पठनीयता एक ही बात नहीं है।

Alconost में अनुवादित

कोड का उपयोग इंटरफेस बनाने के लिए किया जाता है। लेकिन कोड ही एक इंटरफ़ेस है।

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

यदि कोड कम त्रुटियों का उत्पादन करता है, तो क्या इसे अधिक पठनीय माना जा सकता है? कम त्रुटियां, बेहतर, लेकिन क्या तंत्र है? जब आप कोड पढ़ते हैं तो मैं आपके द्वारा अनुभव की जाने वाली अस्पष्ट सुखद संवेदनाओं को कैसे बता सकता हूं? इसके अलावा, कोई फर्क नहीं पड़ता कि कोड पढ़ते समय भौंहें कितनी फड़कती हैं, इससे त्रुटियां नहीं होंगी।

यदि कोड को संपादित करना आसान है, तो क्या यह पठनीय है? लेकिन यह, शायद, विचार की सही दिशा है। आवश्यकताएँ बदल जाती हैं, फ़ंक्शंस जुड़ जाते हैं, त्रुटियां उत्पन्न होती हैं - और कुछ बिंदु पर किसी को आपके कोड को संपादित करना पड़ता है। और नई समस्याओं का कारण नहीं होने के लिए, डेवलपर को यह समझने की आवश्यकता है कि वास्तव में वह क्या संपादन कर रहा है और कोड के व्यवहार में परिवर्तन कैसे होंगे। इसलिए, हमें एक नया हेयुरिस्टिक नियम मिला: पठनीय कोड को संपादित करना आसान होना चाहिए।

किस कोड को संपादित करना आसान है?

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

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

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

कोड का उपयोग इंटरफेस बनाने के लिए किया जाता है। लेकिन कोड ही, IDE के साथ संयुक्त, एक इंटरफ़ेस है। एक इंटरफ़ेस जो उपयोगकर्ताओं के एक बहुत छोटे समूह के लिए डिज़ाइन किया गया है - हमारे सहयोगी। इसके अलावा, हम उन्हें "उपयोगकर्ता" कहेंगे - ताकि उपयोगकर्ता इंटरफ़ेस डिज़ाइन करने के स्थान पर बना रहे।

इसे ध्यान में रखते हुए, उपयोगकर्ता पथ के इन उदाहरणों पर विचार करें:

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

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

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

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

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

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

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




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

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

कोड चलाने के बिना करने के लिए दो शर्तें पूरी करनी चाहिए:

1. उपयोगकर्ता समझता है कि कोड क्या करने की कोशिश कर रहा है।
   
2. उपयोगकर्ता यह सुनिश्चित करता है कि कोड वही करता है जो उसका दावा करता है।
   

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

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




लघु मेनू में, श्रेणीबद्ध नेविगेशन बहुत तेज है। दाईं ओर "लंबे" मेनू में - केवल 11 लाइनें। विधि कोड में हम कितनी बार इस संख्या में फिट होते हैं? स्क्रीनशॉट - भानुमती

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

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

element.visible = true/false 

कोड के बाकी हिस्सों से अलगाव में समझना आसान है, लेकिन इसके लिए दो अलग-अलग टोकन को ध्यान में रखना चाहिए। अगर उपयोग करना है

 element.visibility = .visible/.hidden 

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


ऊपर दिए गए उदाहरण में "ऑफ़लाइन मोड" लाइन इंगित करती है कि आवेदन ऑफ़लाइन है। नीचे दिए गए उदाहरण में स्विच का एक ही अर्थ है, लेकिन इसे समझने के लिए, आपको संदर्भ को देखने की आवश्यकता है। स्क्रीनशॉट - भानुमती

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

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

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

संक्षेप में: पठनीय कोड का उपयोग करना आसान होना चाहिए। और - एक साइड इफेक्ट के रूप में - यह सुंदर दिख सकता है।

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

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

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

 (loaded, playing) 

संकलक अमान्य मानों के इनपुट की अनुमति देगा

 (loaded: false, playing: true) 

और अगर आप एन्यूमरेशन का इस्तेमाल करते हैं

 (.buffering/.loaded/.playing) 

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




अमान्य संयोजन अग्रिम में अक्षम हैं; उपयोगकर्ताओं को यह सोचने की ज़रूरत नहीं है कि कौन से कॉन्फ़िगरेशन असंगत हैं। स्क्रीनशॉट - Apple

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

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

संक्षेप में: पठनीय कोड का उपयोग करना आसान होना चाहिए। और - एक साइड इफेक्ट के रूप में - यह सुंदर दिख सकता है।

टिप्पणी

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

अनुवादक के बारे में

लेख का अनुवाद अल्कोनोस्ट ने किया था।

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

हम विज्ञापन और प्रशिक्षण वीडियो भी बनाते हैं - उन साइटों के लिए जो Google Play और ऐप स्टोर के लिए बिक्री, छवि, विज्ञापन, प्रशिक्षण, टीज़र, एक्सप्लोरर, ट्रेलर बनाती हैं।

→ और पढ़ें