कोड में रूसी पहचानकर्ता

यह प्रोग्राम कोड (मेरे मामले में, रूसी में) में मूल भाषा में नाम (कक्षाएं, चर, विधियों) का उपयोग करने के बारे में होगा।



अनुभव से पता चला है कि रूसी पहचानकर्ता आदर्श रूप से ऑब्जेक्ट मॉडल बनाने और ग्राहक के साथ चर्चा करने के लिए (घरेलू परियोजनाओं के लिए) अनुकूल हैं।







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



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



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



इस प्रकार, मैं इस निष्कर्ष पर पहुंचा कि डॉटनेट में रूसी पहचानकर्ताओं के उपयोग के साथ कोई तकनीकी समस्याएँ नहीं हैं।



बेशक, ऐसे समय होते हैं जब रूसी नामों का उपयोग करने का प्रश्न स्वयं ही गायब हो जाता है:

• यदि किसी कारण से उत्पाद के ग्राहक को आवश्यकता होती है कि सभी कोड अंग्रेजी में हैं;
• यदि कोई संदेह है कि परियोजना ओपनसोर्स में पोस्ट की जाएगी या विदेशी डेवलपर्स को हस्तांतरित की जाएगी;
• यदि विकास टीम में हर कोई रूसी नहीं बोलता है;
• यदि परियोजना विभिन्न भाषाओं और प्रौद्योगिकियों का एक चिड़ियाघर है (एमएस-डॉस के समय सहित);
• यदि रूसी पहचानकर्ता विरासत में मिला कोड को भ्रमित करते हैं।

यह स्पष्ट है कि अवसरों की उपलब्धता का अर्थ इसका उपयोग करने की आवश्यकता नहीं है।



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



अब एक उदाहरण:

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







VisualStudio में, एक वर्ग आरेख बनाएं:







इस तरह के एक वर्ग आरेख को ग्राहक को भी दिखाया जा सकता है और उसी समय उसके साथ शाब्दिक रूप से "एक भाषा में" - यानी समान शब्दों का उपयोग करके दिखाया जा सकता है। ग्राहक को यह महसूस भी हो सकता है कि वह आपके कोड में पारंगत है :)



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



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

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

वैसे, मुझे हाल ही में पता चला है कि 1C- प्रोग्रामर कोड का शाब्दिक अर्थ "रूसी में" लिखते हैं :)



निष्कर्ष में, निष्कर्ष:

• रूसी पहचानकर्ता घरेलू परियोजनाओं के ऑब्जेक्ट मॉडल का वर्णन करने के लिए महान हैं
• मुझे लगता है - समय के साथ, डेवलपर्स अब रूसी पहचानकर्ताओं का उपयोग करने से डरेंगे नहीं
• किसी चरम की जरूरत नहीं: रूसी में सभी कोड लिखना बेतुका है।

अद्यतन: बुर्जुआ, जिनके उपकरण हम विकास में उपयोग करते हैं, उनकी मूल भाषा में कोड देखें ...