स्थानीय चर में पहले शब्द के लिए लोअरकेस का उपयोग करने का क्या कारण है (उदाहरण के लिए, कर्मचारी, प्रथम नाम)

Question

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

विशिष्ट कारण जो मुझे इस "गैर-मानक" आवरण सम्मेलन का पालन नहीं करना चाहिए, क्योंकि पूर्ण उचित मामला गुणों और शून्य विधियों के लिए आरक्षित होना चाहिए। स्थानीय चर और विधियाँ जो एक मान लौटाते हैं, जैसे लोअरकेस में पहला शब्द होना चाहिए int employeeCount = getEmployeeCount()।

हालाँकि, मुझे समझ नहीं आता कि क्यों।

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

जब से एक्सेल 97 मैक्रोज़ ऑफ़ द ऑफिस आईडीई के साथ प्रोग्रामिंग के मेरे शुरुआती दिनों में, मुझे यह बताने के लिए एक आवरण सम्मेलन की आवश्यकता नहीं है कि क्या कोई स्थानीय चर या संपत्ति है या नहीं। ऐसा इसलिए है क्योंकि मैंने हमेशा बहुत सहज नामकरण सम्मेलन का उपयोग किया है। उदाहरण के लिए, GetNuggetCount()स्पष्ट रूप से एक विधि का सुझाव देती है जो कहीं जाती है सभी नगों की गिनती होती है। SetNuggetCount(x)सुझाव है कि आप सोने की डली की गिनती के लिए एक नया मूल्य प्रदान कर रहे हैं। NuggetCountसभी अपने आप में एक संपत्ति या स्थानीय चर का सुझाव देते हैं जो केवल एक मूल्य धारण करता है। उस आखिरी तक, किसी को यह कहने के लिए लुभाया जा सकता है, "आह हा! यह सवाल है। संपत्ति या परिवर्तनशील? यह कौन है?" उस के लिए, मैं के साथ जवाब देंगे, "यह वास्तव में बात करता है?"

तो यहाँ tl? Dr ;: क्या उद्देश्य, तार्किक, गैर-मनमाना कारण हैं जो आपके चर या रिटर्न विधि में पहले शब्द के लिए लोअरकेस का उपयोग करते हैं?

संपादित करें: मेनमा के लिए

इस कोड को अपने उत्तर में पहले कोड नमूने से बदलें और देखें कि आपका तर्क कितना सही है:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Comments

अगर वे ऊपरी मामले में होते तो कोई और होता जो पूछते कि वे लोअर-केस में क्यों नहीं हैं ...

— m3th0dman

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

— Sassafras_wot

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

— एंड्रेस एफ।

मैंने हमेशा यह मान लिया है कि डेवलपर्स कैमलकेस पर बस गए क्योंकि यह kewl लग रहा था। वहाँ CamelCase के लिए कोई 'उद्देश्य' कारण नहीं है अपने आप PascalCase ऊपर। मुझे व्यक्तिगत रूप से PascalCase (आपके उदाहरण की तरह) पढ़ने में बहुत आसान लगता है, और इसे जावास्क्रिप्ट के अलावा अधिकांश जगहों पर उपयोग किया जाता है, जहां मैं कैमकलेस के साथ रहता हूं, इसलिए मुझे पार्टी निमंत्रण पर याद नहीं है।

— ग्रैंडमास्टरबी

स्टैण्डर्ड कोडिंग स्टाइल होने के फ़ायदों पर शोध करना वास्तव में यह मायने नहीं रखता कि मानक क्या है, बस इसका पालन किया जाता है।

— मि। मिन्दर

Answer 1

उस नामकरण सम्मेलन का उपयोग अक्सर तब किया जाता है जब लोग एक चर को अपने प्रकार के समान नाम देने में सक्षम होना चाहते हैं। उदाहरण के लिए:

Employee employee;

कुछ भाषाएं भी उस पूंजीकरण को लागू करती हैं। की तरह कष्टप्रद चर नाम का उपयोग किए यह रोकता है MyEmployee, CurrentEmployee, EmployeeVar, आदि तुम हमेशा बता सकती है कि कुछ एक प्रकार या एक चर रहा है, बस पूंजीकरण से। इस तरह की स्थितियों में भ्रम को रोकता है:

employee.function(); // instance method
Employee.function(); // static method

इसके अलावा, अंग्रेजी में, संज्ञाएं आमतौर पर पूंजीकृत नहीं होती हैं, इसलिए आप वास्तव में दावा नहीं कर सकते कि आपका पूंजीकरण "उचित" है।

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

Comments

ध्यान दें कि समस्या अभी भी ओपी द्वारा उपयोग की जाने वाली भाषा में मौजूद है, क्योंकि गुणों को पूंजीकृत किया गया है (निश्चित रूप से, गुणों को उपसर्ग किया जा सकता है this., जो भ्रम से बचा जाता है; स्थानीय चर में ऐसा उपसर्ग नहीं हो सकता है)।

— आर्सेनी मूरज़ेंको

@oscilatingcretin इसे PascalCase कहा जाता है।

— मि। मिन्दर

Employee Employeeकाम करता है, लेकिन मैं तर्क दूंगा कि यह मानव पाठक की तुलना में अधिक भ्रमित है Employee employee। उत्तरार्द्ध दो अलग-अलग चीजों की तरह दिखता है। पहली जरूरत दोहराव की तरह दिखती है।

— जेमी एफ

@oscilatingcretin बिल्कुल: "मानता है कि पाठक अंतर्निहित रूपरेखा को समझता है ..." मुझे जावास्क्रिप्ट, जावा, सी #, सी ++, और अन्य पढ़ना पसंद है और मेरे सिर में कोड का अनुवाद करना है। मुझे यह सोचने की ज़रूरत नहीं है कि "ओह, इस भाषा के संकलक एक्स से निपट सकते हैं ।" जबकि मैं सिर्फ कोड का अर्थ निकालने की कोशिश कर रहा हूं।

— जेमी एफ

ध्यान दें कि employee.function()एक स्थैतिक विधि भी हो सकती है, यदि भाषा किसी ऑब्जेक्ट से स्थिर तरीकों को कॉल करने की अनुमति देती है (जैसे जावा करता है)। संकलक एक चेतावनी देता है, लेकिन ऐसा करने की अनुमति है।

— ऊओ

Answer 2

कोई नहीं है यह वही है जो ज्यादातर लोग करते हैं, इसलिए यह मानक बन गया है क्योंकि हर कोई यही करता है। बहुत सारे साहित्य इस सम्मेलन का अनुसरण करते हैं इसलिए लोगों ने इस आदत को उठाया।

यह सम्मलेन संहिता की संगति के रूप में महत्वपूर्ण नहीं है। जब तक सब कुछ एक सुसंगत तरीके से नामित किया जाता है ताकि मैं यह बता सकूं कि उन्हें देखने से क्या चीजें हैं, यह वास्तव में कोई फर्क नहीं पड़ता कि पहला पत्र पूंजीकृत है या नहीं।

मुझे लगता है कि यह आपके तरीके से लिखे गए कोड में आने के लिए परेशान होगा और कहेगा कि मुझे यह पसंद नहीं है। लेकिन यह स्टाइल की बात है।

अब यदि आप कार्यस्थल में ऐसा कर रहे हैं, तो टीम की शैली में कोड करना बेहतर होगा ताकि कोड हर जगह संगत रहे। अपने कोड होने के बजाय हर किसी से अलग है।

http://thecodelesscode.com/case/94

Comments

काश ज्यादातर प्रोग्रामर आप जैसे होते। कई लोग स्पष्ट रूप से भावुक और / या हठधर्मिता का पालन करने के बारे में है जो मैंने उल्लेख किया है।

— ऑसिलेटिंगक्रेटिन

@ शची यह मायने रखता है कि आप प्रोजेक्ट पर काम करने वाले अगले प्रोग्रामर हैं या नहीं।

— N4TKD

@oscilatingcretin एक बार आपके द्वारा कोड पर काम करने के बाद आप भावुक और / या हठधर्मी हो सकते हैं var m_someVariableID = GetVariableValueId()। खासकर अगर आपको इसे ऑटोकंप्लीशन समर्थन के बिना करना है ।

— टैक्रॉय

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

— ब्रायन

@ श्लेष अच्छा अद्यतन, मैं सहमत नहीं हूँ यह केवल शैली की बात है, लेकिन सम्मेलन और सम्मेलन अच्छे कारणों के लिए सम्मेलन बन जाते हैं और उनका पालन किया जाना चाहिए। यह एक धर्म नहीं है और कुछ समय आपको सम्मेलन से बहुत दूर होना चाहिए, लेकिन आपके पास एक अच्छा कारण होना चाहिए।

— N4TKD

Answer 3

1. मानक क्यों मौजूद है?

आखिरकार, क्या यह बेहतर नहीं होगा कि सभी को व्यक्तिगत पसंद के अनुसार कोड लिखने दें, और इस बारे में बात करना बंद कर दें कि कौन सा मानक बेहतर है?

तथ्य यह है कि जब आपको एक शैली की आदत होती है, तो कोड को पढ़ना अधिक कठिन होता है जो एक अलग शैली का उपयोग करता है। आपका मस्तिष्क अधिवेशन को समझने के लिए अधिक समय व्यतीत करता है (यदि कोई हो), यह समझने के बजाय कि कोड क्या करता है।

कोड के उन दो टुकड़ों के बीच अधिक पठनीय क्या है?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

या:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

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

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

एक सख्त, समान मानक होने से, यह कोड को पढ़ना आसान बनाता है।

2. उनका मानक मेरे द्वारा अभी आविष्कार किए जाने से बेहतर क्यों है ?

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

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

• [FK for Application: CreatedByApplicationId],
• [IX for SessionIPAddress: SessionId] या
• [PK for RoleOfPassword: RoleId, PasswordId]।

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

• जब मैं एक डीबीए को काम पर रखूंगा, तो वह अपना काम शुरू करने के बजाय नए सम्मेलन को सीखने के लिए मजबूर हो जाएगा,

• मैं इंटरनेट पर कोड के टुकड़े साझा नहीं कर सकता हूं: अजीब तरह से दिखने वाले नाम उन लोगों को बाधित करेंगे जो मेरा कोड पढ़ेंगे,

• यदि मैं इसे अपने आप में उपयोग करने के लिए बाहर से कोड लेता हूं, तो मुझे इसे समान बनाने के लिए नामों को संशोधित करने के लिए मजबूर किया जाएगा,

• यदि एक दिन मैं कुछ प्रसिद्ध मानकों का उपयोग करने का निर्णय लेता हूं, तो मुझे हर सौ नामों में से प्रत्येक को जाने और संशोधित करने के लिए मजबूर किया जाएगा।

3. तो, पूंजीकरण के बारे में क्या?

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

यदि आप C # पर विचार करते हैं, तो यह तर्क पर्याप्त रूप से संगत है।

यदि आप जावा पर विचार करते हैं, तो विधियां छोटे अक्षरों से शुरू होती हैं, जो तर्क का पालन नहीं करती हैं।

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

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

Comments

कोड के बारे में कम पठनीय होने के कारण, क्योंकि यह थोड़ा अलग मानक का पालन करता है, मुझे कभी भी यह समस्या नहीं हुई। जब तक किसी के चर का नाम hookyDookyDooनहीं लिया जाता है, तब तक कोई नामकरण या आवरण सम्मेलन पठनीयता से अलग नहीं होता है। इसके अलावा, ध्यान रखें कि मैं यह नहीं कह रहा हूं कि मेरा सम्मेलन "बेहतर" है क्योंकि यह वास्तव में देव तालिका के लिए कुछ खास नहीं लाता है। अन्त में, मुझे आपकी बात समझ में नहीं आती [गुणों का एक बड़ा दायरा है ... इस दिशा में जाता है] । आवरण सम्मेलन के साथ गुंजाइश का क्या करना है? किस दिशा में जाओ?

— ऑसिलेटिंगक्रेटिन

@oscilatingcretin, सवाल यह नहीं है कि क्या आपको कभी भी यह समस्या हुई है, यह है कि क्या आपके सहकर्मियों के पास है। जाहिर है उनके पास है, या वे शिकायत नहीं करेंगे।

— कार्ल बेवेलफेल्ट

पुन: आपका संपादन: आपका पहला कोड उदाहरण केवल खराब तरीके से निर्मित, आपदा-प्रवण कोड प्रदर्शित करता है। मेरा ओपी खराब निर्माण, आपदा-प्रवण कोड के बारे में नहीं है। यह आपके दूसरे उदाहरण के समान सटीक कोड के बारे में है, लेकिन विभिन्न आवरण सम्मेलन। मैंने आपका दूसरा कोड उदाहरण संपादित किया और अपने आवरण सम्मेलन के साथ अपने ओपी में पोस्ट किया। कृपया अपने पहले कोड उदाहरण से बदलें।

— ऑसिलेटिंगक्रिटिन

@oscilatingcretin: पहला कोड उदाहरण खराब निर्मित कोड को प्रदर्शित नहीं करता है, लेकिन एक टीम द्वारा लिखा गया कोड है जहां हर डेवलपर ने अपनी शैली का पालन किया है। यह बहुत सारे कोडबेस के साथ होता है, पर्याप्त समय दिया जाता है (उदाहरण के लिए पांच साल)। नोट: क्या आपने याद किया है: "तथ्य यह है कि कोड अभी भी इस तरह से बहुत अधिक पठनीय है, और तब भी होगा जब वे किसी भी अलग मानक का उपयोग कर रहे थे।" ?

— आर्सेनी मूरज़ेंको

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

— बेवन

Answer 4

तकनीकी रूप से, यह कोई फर्क नहीं पड़ता (या कम से कम, अधिकांश भाषाओं में यह नहीं है)।

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

इसलिए नहीं कि वे सबसे अच्छे हैं, बल्कि इसलिए कि वे वही हैं जो हर कोई उपयोग करता है; यदि आप मानक के साथ चिपके रहते हैं, तो आपका कोड अधिकांश अन्य कोड के अनुरूप होगा, जिसे आप अंततः उपयोग कर रहे हैं - लाइब्रेरी, टीममेट्स कोड, भाषा बिल्ट-इन। लगातार नामकरण एक शक्तिशाली उत्पादकता हथियार है, क्योंकि इसका मतलब है कि जब आप किसी चीज के नाम का अनुमान लगाते हैं, तो आप आमतौर पर सही अनुमान लगाएंगे। क्या यह file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? नामकरण सम्मेलन आपको बताएगा।

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

सिर्फ एक उदाहरण: C # में, प्रकार और चर अलग-अलग नामस्थानों में रहते हैं; संकलक अंतर जानने के लिए पर्याप्त स्मार्ट है। C में, हालांकि, दोनों प्रकार के नाम एक नाम स्थान साझा करते हैं, इसलिए आपके पास एक ही नाम और एक ही नाम का एक चर नहीं हो सकता है। इस वजह से, सी को एक नामकरण सम्मेलन की आवश्यकता है जो चर से प्रकार को अलग करता है, जबकि सी # नहीं करता है।

Comments

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

— ऑसिलेटिंगक्रेटिन

@oscilatingcretin जब हर कोई एक ही सम्मेलन का उपयोग करता है, तो यह चल रही जटिलता को नहीं जोड़ता है, तो यह कन्वेंशन प्रश्न में भाषा के लिए आपके मानसिक मॉडल का हिस्सा बन जाता है और उस भाषा के उपयोग को आसान बनाता है। यह प्रदर्शन और मापने योग्य है।

— मि। मिन्दर

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

— ट्यूलेंस कोर्डोवा

Answer 5

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

आधुनिक इंटेलीसेन्स के साथ, यह कम और कम मायने रखता है, लेकिन यह अभी भी मुझे कुछ जगहें देता है क्योंकि मुझे यह जानने के लिए कोड पढ़ना है कि मुझे परिभाषा खोजने के लिए कहां देखना चाहिए।

और इसका एक छोटा सा हिस्सा मेरी खराब शैली से वर्षों पहले छोड़ा जा सकता है, जब तरीकों को एक स्क्रीन पर फिट होने की संभावना नहीं थी।

Comments

मैंने जिन परियोजनाओं पर काम किया है, उनकी शैली गाइड में कुछ इस तरह निर्दिष्ट है।

— अक्सिमिंडर

Answer 6

यह आपके विशिष्ट सम्मेलन के बजाय सम्मेलनों के प्रश्न की तरह लगता है।

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

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

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

Comments

"यदि मुझे एक पूंजीकृत चर दिखाई देता है, तो एक शिक्षित अनुमान यह निर्धारित करेगा कि मुझे इसका उपयोग करने के लिए इसे तुरंत करने की आवश्यकता होगी।" मुझे समझ नहीं आता। एक पूंजीकृत चर को देखकर आपको क्या लगेगा कि इसे इस्तेमाल करने से पहले आपको इसे तुरंत करने की आवश्यकता है? क्योंकि यह एक वर्ग नाम की तरह दिखता है? तो आप MyClass MyClass = nullऔर के बीच का अंतर नहीं जानते हैं class MyClass { }?

— ऑसिलेटिंगक्रेटिन

हां, मुझे अंतर दिखाई देता है। सम्मेलन अस्पष्टता को रोकने के लिए मौजूद है। var car = new Car();मेरी अंतिम पंक्ति के अनुसार - यह स्पष्ट क्यों नहीं है?

— एड्रियन श्नाइडर

@oscilatingcretin निश्चित रूप से एक अंतर है। लेकिन मानव मस्तिष्क दृश्य संकेतों से लाभान्वित होता है जो एक कंप्यूटर पार्सर की आवश्यकता नहीं है। ऐसा लगता है जैसे आप सम्मेलनों / मानकों की आवश्यकता पर सवाल उठा रहे हैं ... जो कि एक मान्य है, अगर आपने मूल रूप से जो पूछा है, उससे अलग सवाल।

— एंड्रेस एफ।

Answer 7

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

अन्य प्रोग्रामर अभी आपके कोड को खींच रहे हैं और सोच रहे हैं कि यह एक संपत्ति है और यह वास्तव में एक स्थानीय चर है, आपके काम को कठिन बना रहा है।

Comments

क्या आपने मेरा प्रश्न पूरा पढ़ा? अंत में एक नज़र NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"

— डालिए

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

— N4TKD

@oscilatingcretin मुझे लगता है कि आप जो निराशा पूछ रहे हैं, उससे थोड़े अलग सवालों के जवाब देने वाले लोगों के साथ आप देख रहे हैं कि कबूल करने का भ्रम पैदा हो सकता है।

— मि। मिन्दर

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

— मि। मिन्दर

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

— मि। मिन्दर

Answer 8

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

संरक्षित या आउट या कुछ जैसी चीजों से निपटने पर लाइनों को थोड़ा धुंधलापन मिलता है।

Answer 9

भाषा (अपने औपचारिक पहलू और पारंपरिक के साथ) आपके विचारों को व्यवस्थित करने के लिए महत्वपूर्ण है, इसमें आपके सोचने के तरीकों पर शक्ति है। तो यह सिर्फ एक शैली से दूसरी शैली में संक्रमण करने के लिए एक दर्द है।

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

Answer 10

मेरे लिए यह उम्मीद पर खरी उतरती है।

जब मैं सबसे अधिक कोड पढ़ता हूं, तो मुझे उम्मीद है कि lowerCaseस्थानीय चर या फ़ंक्शन (C # में जो केवल एक चर होगा) के साथ शुरू होता है । अगर मुझे कोई स्थानीय चर दिखाई देता है ProperCase, तो मैं संभवतः ठोकर खाऊंगा और थोड़ी देर के लिए भ्रमित हो जाऊंगा, यह सोचकर कि यह या तो एक वर्ग का नाम है या संपत्ति या कुछ और। इससे मुझे कोड को फिर से पढ़ना पड़ेगा, और मुझे गुस्सा आएगा।

संभावना है कि आपके मामले में क्या हो रहा है।

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

Answer 11

टाइपिंग में आसानी के लिए लोअर केस का इस्तेमाल किया जाना चाहिए (स्पीड / नो शिफ्ट की)। ऊपरी मामले का उपयोग एक नाम के भीतर शब्दों को अलग करके पठनीयता में मदद करने के लिए किया जाता है। एकल-शब्द स्थानीय चर नामों के साथ कोड (जो सामान्य होना चाहिए) तेज और टाइप करने में आसान हैं। अंडरस्कोर का उपयोग करने की तुलना में नाम में प्रत्येक नए शब्द के लिए ऊपरी मामले का उपयोग भी तेज (और कम जगह) है जो एक और चरित्र को जोड़ता है - इसे ऊंट-केस के रूप में भी जाना जाता है।

Comments

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

— एआईएन

Answer 12

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

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

Comments

ऐसा लगता है कि किए गए अंकों से अधिक कुछ नहीं दिया जा रहा है और पहले के 11 जवाबों में समझाया गया है

— gnat