सी # में फ़ील्ड और विधियों के सामने "यह" कीवर्ड के बारे में वर्तमान सर्वोत्तम अभ्यास क्या है?

Question

जब तक एक चर और क्षेत्र के बीच एक ही नाम के साथ अंतर करने की आवश्यकता नहीं होती है, मैं कभी this.भी C # में किसी क्षेत्र या किसी सदस्य के सामने नहीं डालता । मैं इसे उन m_उपसर्गों से अलग नहीं देखता , जो C ++ में आम हुआ करते थे, और सोचें कि क्या आपको वास्तव में यह निर्दिष्ट करने की आवश्यकता है कि यह एक सदस्य है, आपकी कक्षा बहुत बड़ी है।

हालांकि, मेरे कार्यालय में कई लोग हैं जो दृढ़ता से असहमत हैं।

वर्तमान सर्वोत्तम प्रथाओं के बारे में क्या माना जाता है this.?

संपादित करें: स्पष्ट करने के लिए, मैं कभी उपयोग नहीं करता m_और केवल तभी उपयोग करता हूं this.जब बिल्कुल आवश्यक हो।

Comments

क्या m_मतलब है?

— FrustratedWithFormsDesigner

@ दिया गया कि चर वर्ग का सदस्य है।

— माइकल टॉड

क्षमा करें, मैंने यह धारणा बना ली कि कोई भी संभवतः यह नहीं सोच सकता कि मैं हंगेरियन नोटेशन का उपयोग करूं। मैं यह कहना चाह रहा था कि मुझे लगता this.है कि लगभग उतना ही बुरा है जितना कि m_।

— एंडी लोरी

यार, अभी स्थापित करें और स्टाइलकॉप चलाएं! यह भी निश्चित रूप से एक SO प्रश्न का एक प्रकार है।

— जॉब

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

— क्रिस

Answer 1

फ्रेमवर्क डिज़ाइन दिशानिर्देशों के अनुसार , सार्वजनिक या संरक्षित क्षेत्रों का संदर्भ देते समय:

फ़ील्ड नामों के लिए उपसर्ग का उपयोग न करें।

उदाहरण के लिए, m_एक उपसर्ग है।

इसलिए, किसी क्षेत्र का सार्वजनिक प्रदर्शन खुद को thisMSDN पर बताए गए कीवर्ड के उपयोग के लिए उधार देता है

समान नामों से छिपे हुए सदस्यों को योग्य बनाने के लिए, उदाहरण के लिए: कॉपी करें

public Employee(string name, string alias) 
{
   this.name = name;
   this.alias = alias;
}

निजी क्षेत्रों का जिक्र करते समय, आप चाहें तो उपयोग कर सकते m_हैं। लेकिन, सार्वजनिक क्षेत्रों के लिए मैं सर्वोत्तम प्रथाओं का पालन करने की सलाह देता हूं।

व्यक्तिगत रूप से, मुझे अपने चर नामों में अंडरस्कोर पसंद नहीं है। मैं भी लगातार बने रहने की कोशिश करता हूं। इसलिए, this.name = name;सार्वजनिक / निजी दोनों स्थितियों में काम करने के लिए अंगूठे का एक अच्छा नियम है।

Comments

+1: यह वही है जिसका मैं अपने उत्तर में उल्लेख कर रहा था, लेकिन आपका उत्तर बहुत अधिक वर्णनात्मक है।

— जोएल एथर्टन

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

— मेयो

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

— क्रिस एस

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

— पी। ब्रायन। मैके

Answer 2

हमारी टीम पर, हमने जूनियर डेवलपर्स को बड़ी कक्षाओं में this.या Me.ऑब्जेक्ट क्वालिफायर का उपयोग करने के मानक को अपनाया है ताकि वे इसे देखकर और अधिक आसानी से किसी चर के सटीक / तत्काल दायरे को अलग कर सकें।

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

Comments

जूनियर कोडर्स के बारे में शानदार बात।

— पैट्रिक ह्यूजेस

क्या आपकी कक्षाएं छोटी नहीं होनी चाहिए? या यह एक विरासत का मुद्दा है?

— तजार्ट

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

— जोएल एथरटन

आपके जूनियर्स को @JoelEtherton की समस्या क्यों है? पायथन जूनियर्स के सामने एक विपरीत समस्या है जहां वे स्वयं को जोड़ना भूल जाते हैं। निजी चर का उपयोग करने के लिए। क्या जूनियर्स सिर्फ भूल जाते हैं और अधिवेशन को गड़बड़ कर देते हैं?

— तजार्ट

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

— जोएल एथरटन

Answer 3

StyleCop this.So के उपयोग को लागू करेगा , यदि आप मानते हैं कि सबसे अच्छा अभ्यास (जो मैं करता हूं) के रूप में, तो this.सबसे अच्छा अभ्यास है।

आपके द्वारा अपनाई जाने वाली शैली आपके और आपके स्वयं के कोडिंग मानकों पर निर्भर है, "सर्वश्रेष्ठ" वह है जो आप इसे परिभाषित करते हैं। बस संगत हो। असंगत रूप से इसका उपयोग करने से भ्रम पैदा होता है।

मेरा तर्क यह है कि this.इस तथ्य का उपयोग करते हुए कि आप उदाहरण के गुणों को संदर्भित कर रहे हैं, इसलिए, उदाहरण के लिए, यह इस तथ्य को उजागर करने में मदद करता है कि आप उन्हें (यदि आपके पास है this.x = ...), जो कि आप के बारे में जानना चाहते हैं। यह इस तथ्य को भी उजागर करता है कि किसी भी समय आप this.अपनी पद्धति को कभी भी स्थिर नहीं देख सकते हैं। कुछ सम्मेलन का उपयोग करना m_भी ऐसा करेगा, लेकिन यह एक मैनुअल प्रयास है, यदि आप m_कक्षा में बाहर से मूल्य में उत्तीर्ण करने के लिए स्थैतिक, या रिफलेक्टर बनाते हैं, तो आपको नाम बदलने के लिए याद रखना होगा, यदि आप उपयोग कर रहे थे thisतब संकलक आपको परिवर्तन करने के लिए बाध्य करेगा।

बस का उपयोग कर रखो thisअगर आप का उपयोग आसान, यदि आप इसे गलत अपने कोड संकलन नहीं करेगा क्योंकि है m_यह एक मैनुअल प्रयास है और आप इस टूल का लाभ नहीं कर रहे हैं।

Comments

और Resharper "यह" हटाने का सुझाव देगा। आपकी माइलेज भिन्न हो सकती है।

— कार्रा जू।

एह? Resharper ने मुझे कभी सुझाव नहीं दिया। शायद यह है क्योंकि मैं StyleCop प्लगइन है?

— जेसी सी। स्लीकर

सही, StyleCop स्थापित होने से R # में वह विकल्प बंद हो जाएगा।

— स्टीव

Answer 4

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

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

Comments

या टाइप करें this.और intellisense आपकी मदद करें।

— स्टीव

@ हेतवे हाई: आप इस बिंदु को याद कर रहे हैं, वह कह रहा है कि वह सभी अलग-अलग प्रकार के सदस्यों को एक साथ समूह में ले जाता है, क्योंकि सूची को वर्णानुक्रम में क्रमबद्ध किया गया है, सभी m_ एक साथ दिखाई देते हैं, सभी s_ एक साथ मिलते हैं आदि

— gbjbaanb

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

— स्टीव

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

@ साइट: टंकण m_मुझे सभी सदस्य चर की एक सूची देगा। टाइपिंग this.मुझे सदस्य चर और सदस्य कार्यों की एक सूची देगा।

— शॉन

Answer 5

thisस्पष्ट है। यह एक ऑप्टिकल चिन्ह है जिसे आप मिस नहीं कर सकते।

मैं लगभग हमेशा अंतर्निहित कोड पर स्पष्ट कोड पसंद करता हूं। इसलिए मैं thisअक्सर उपयोग करता हूं । मैं इसे एक सर्वोत्तम अभ्यास मानता हूं।

Answer 6

मैं हमेशा "इस" का उपयोग करता हूं। तर्क दो सरल तथ्यों पर आधारित है:

• कोड लिखना लिखने की तुलना में पढ़ना कोड अधिक कठिन है।
• आप कोड लिखने की तुलना में अधिक बार कोड पढ़ते हैं।

"यह" का उपयोग किसी को भी पढ़ने के लिए काफी स्पष्ट कर देता है (अर्थात न केवल लेखक, लेकिन कार्यान्वयन के विवरण के बाद 6 महीने के समय में लेखक को शामिल कर सकता है) के बारे में पूरी तरह से भूल गए हैं) हाँ, यह एक वर्ग का सदस्य है जिसे हम ' यहाँ बात कर रहे हैं। "m_" और जैसा है वह केवल एक कन्वेंशन है, और किसी भी अन्य कन्वेंशन की तरह इसका दुरुपयोग (या बिल्कुल नहीं किया जा सकता है) - "m _" / etc को संकलित समय या रन-टाइम पर लागू करने के लिए कुछ भी नहीं है। "यह" अधिक मजबूत है: आप स्थानीय चर पर "m_" डाल सकते हैं और संकलक शिकायत नहीं करेंगे; आप "यह" के साथ ऐसा नहीं कर सकते।

अगर कुछ भी मैं इसे खेदजनक मानता हूं कि "इस" का उपयोग भाषा के चश्मे में अनिवार्य नहीं किया गया था।

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

Answer 7

thisकीवर्ड 2 चर मौजूद है भेद करने के लिए विशेष रूप से प्रयोग किया जाता है, खासकर जब आप कर एक निर्माता या की विधि ही नाम के साथ एक चर के साथ है, लेकिन एक ही प्रकार के हो सकते हैं।

उदाहरण:

public class Example {

    string reason;
    string cause;

    Example (string reason, string cause) {
        this.reason = reason;
        this.cause = cause;
    }

    //<Setter> if you want to explicitly write your onw
    public void setReason(stirng reason) {
        this.reason = reason;
    }
}

यह (उदाहरण के लिए this.reason = reason) मूल रूप से कक्षा में पैरामीटर से चर तक मान प्रदान करता है। thisमूल रूप reasonसे पैरामीटर ब्लॉक से क्लास लेता है ।

Answer 8

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

लेकिन मैं व्यक्तिगत रूप से m_उपसर्ग शैली से पूरी तरह से नफरत करता हूं , हंगेरियन के कारण ऐसा नहीं है, लेकिन क्योंकि अंडरस्कोर टाइप करने के लिए एक दर्द है;) इसलिए मैं इसे एक विकल्प नहीं मानता। मैं मानता हूँ कि यह मजबूत बिंदु है जब यह अंतर्मुखता की बात आती है, हालांकि आप फिर से यह तर्क दे सकते हैं कि यदि आप किसी सदस्य चर के पहले कुछ अक्षर याद नहीं कर सकते हैं, तो आपकी कक्षा बड़ी है।

Answer 9

मैं वर्ग के सदस्यों के लिए एक एकल अंडरस्कोर उपसर्ग को प्राथमिकता देता हूं। _someVar;

क्यों? आप पहली बार में जानते हैं कि यह एक सदस्य है, स्टैक चर नहीं है। बस एक त्वरित नज़र के दौरान सुविधा। और यह "यह" कीवर्ड की तुलना में कम अव्यवस्था लेता है।

Answer 10

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

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

public Person(string firstName)
{
    this.firstName = firstName;
}

मेरे गुण इसलिए इस तरह दिखते हैं (हां, मैं हमेशा संपत्ति के साथ क्षेत्र रखता हूं, और कहीं मेरी फ़ाइल के शीर्ष पर असंबंधित नहीं है:)

private string firstName;
public string FirstName
{
    get { return this.firstName; }
}

यह अच्छी तरह से पढ़ता है: यह पहला नाम लौटाएं ।

Answer 11

संपादित करें: मेरा उत्तर स्पष्ट रूप से एक उत्तर नहीं है। तो यहाँ एक संपादन है। Microsoft कोडिंग दिशानिर्देश राज्य:

2.6 नामकरण

सदस्य चर ( , m , s_, आदि) के लिए एक उपसर्ग का उपयोग न करें । यदि आप स्थानीय और सदस्य चर के बीच अंतर करना चाहते हैं तो आपको "इसका उपयोग करना चाहिए।" C # और "मी" में। VB.NET में।

पर पाया जा सकता है: http://blogs.msdn.com/b/brada/archive/2005/01/26/36138.xx

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

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

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

यह उन लोगों में से एक के रूप में मुझ पर प्रहार करता है "यह क्या है" यह सही बनाम "सम्मेलनों" यह क्या करता है "नामकरण सम्मेलनों। स्पष्टता से ऊपर की ओर पसंदीदा होना चाहिए। यह एक सबक है जिसे अक्सर गतिशील भाषाओं द्वारा दोहराया जाता है। हम सभी फुलाना की जरूरत नहीं है!

Comments

-1। प्रश्न का उत्तर देने के बजाय, आप बस अपनी राय दे रहे हैं जो सर्वोत्तम प्रथाओं को प्रतिबिंबित नहीं करता है।

— Arseni Mourzenko

तो इस के अनुसार stylecop उपयोग के अनुसार। सबसे अच्छा अभ्यास है @MainMa। मैं पूरी तरह से असहमत हूँ। मैं उस नोट का उत्तर संपादित करूंगा।

— ताजरत

@ मेनमा क्या अब बेहतर है? कई अन्य उत्तर केवल एक राय देते हैं, लेकिन नीच नहीं हैं। सर्वोत्तम अभ्यास क्या हैं और वे कहाँ पाए जाते हैं?

— टेजर्ट

Answer 12

इस। अक्सर अवांछित शोर हो सकता है।

यहाँ मेरा समाधान है:

• parameter_names_
• local_variables
• ANY_CONSTANT
• _private_members
• NonPrivateProperties
• _NonPStreetProperty // बैकर
• निजी संपत्ति
• _pStreetProperty // बैकर

Comments

यह आम .Net शैली के विपरीत है। ऊंट और पास्कल के माध्यम से सभी तरह से आवरण। आपका तरीका काफी असंगत है। यह स्थिरांक स्थिरांक के लिए एक काफी पुरानी शैली का नियम है, और इसका उपयोग सामान्य नेट समुदाय में नहीं किया जाता है।

— तजार्ट

मुझे आशा है कि आप प्रत्येक फ़ाइल के शीर्ष पर एक टिप्पणी डालते हैं जो उस योजना को

— समझाती है

मुझे समझ नहीं आता कि आप इसे कैसे जोड़ते हैं। शोर मचाएंगे, लेकिन वह सब जिबरिश नहीं करता

— ट्रैविस वेस्टन