सी में सबसे आम नामकरण सम्मेलनों क्या हैं?


125

आमतौर पर C में नामकरण परंपराओं का क्या उपयोग होता है? मुझे पता है कि कम से कम दो हैं:

  1. GNU / linux / K & R में लोअर_केस_functions के साथ
  2. ? नाम? अपरकेस फंक्शन के साथ

मैं यहाँ केवल C की बात कर रहा हूँ। हमारी अधिकांश परियोजनाएँ छोटे एम्बेडेड सिस्टम हैं जिनमें हम C का उपयोग करते हैं।

यहाँ मैं अपनी अगली परियोजना के लिए उपयोग करने की योजना बना रहा हूँ:


C नामकरण संधि

Struct              TitleCase
Struct Members      lower_case or lowerCase

Enum                ETitleCase
Enum Members        ALL_CAPS or lowerCase

Public functions    pfx_TitleCase (pfx = two or three letter module prefix)
Private functions   TitleCase
Trivial variables   i,x,n,f etc...
Local variables     lower_case or lowerCase
Global variables    g_lowerCase or g_lower_case (searchable by g_ prefix)

7
मैं वैश्विक चर पर 'g_' उपसर्ग को बाध्य नहीं करूंगा; मैं सार्थक नाम लागू करूंगा (इसलिए client_locale और वैश्विक चर नाम के रूप में cl_lc नहीं)। क्लासिक सी ऊंट-केस का उपयोग नहीं करता है; मैंने सी में ऊंट-केस में कोड लिखा है, और यह अजीब लगता है (इसलिए मैं इसे किसी भी तरह से नहीं करता हूं)। उस ने कहा, यह गलत नहीं है - और संगति अधिक महत्वपूर्ण है जिससे सम्मेलन का उपयोग किया जाता है। टाइपराइफ से बचें जो संरचना बिंदुओं को घेरता है; इस प्रकार C मानक पर विचार करें - 'FILE *' वर्तनी है, FILE_PTR नहीं।
जोनाथन लेफ्लर

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

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

3
@ क्रिस लुत्ज़, मैं सहमत हूँ, पूरे दिल से। जहां कहीं भी संभव हो, सबसे कम दायरे में रखा जाना चाहिए। ध्यान दें कि वास्तव में तीन स्कोप हैं जिनकी हम चर्चा कर रहे हैं: एक फ़ंक्शन के लिए स्थानीय, एक मॉड्यूल के लिए स्थानीय (वेरिएबल के लिए कोई बाहरी लिंक नहीं) और बाहरी लिंकेज के साथ ग्लोबल्स। एम्बेडेड सिस्टम में "ग्लोबल से एक मॉड्यूल" वेरिएबल होना आम है। इसलिए, बाहरी लिंकेज के साथ ग्लोबल्स की पहचान करने के लिए ध्यान रखा जाना चाहिए ताकि उन्हें न्यूनतम और मॉड्यूल इंटरैक्शन को समझा जा सके। यह वह जगह है जहाँ "g_" उपसर्ग सहायक है।
जेएफवी

46
मुझे // के साथ वैश्विक चर उपसर्ग करना पसंद है।
plafer

जवाबों:


127

यहां सबसे महत्वपूर्ण चीज स्थिरता है। मैंने कहा, मैं GTK + कोडिंग कन्वेंशन का पालन करता हूं, जिसे संक्षेप में निम्नानुसार किया जा सकता है:

  1. कैप्स में सभी मैक्रोज़ और स्थिरांक: MAX_BUFFER_SIZE, TRACKING_ID_PREFIX
  2. कैमलकेस में संरचना नाम और टाइप्डिफ: GtkWidget, TrackingOrder
  3. कार्य जो संरचना पर काम करते हैं: क्लासिक सी शैली: gtk_widget_show(), tracking_order_process()
  4. संकेत: कुछ भी नहीं फैंसी यहाँ: GtkWidget *foo, TrackingOrder *bar
  5. वैश्विक चर: केवल वैश्विक चर का उपयोग न करें। वे दुष्ट हैं।
  6. जो कार्य हैं, लेकिन उन्हें सीधे नहीं बुलाया जाना चाहिए, या अस्पष्ट उपयोग, या जो भी हो: शुरुआत में एक या अधिक अंडरस्कोर: _refrobnicate_data_tables(), _destroy_cache()

13
अंक छह में मैं staticमॉड्यूल उपसर्ग का उपयोग और छोड़ना पसंद करता हूं , इसलिए यदि gtk_widget_show()फ़ाइल स्कोप के साथ कोई फ़ंक्शन होता है तो यह केवल widget_show()स्थिर भंडारण वर्ग के साथ जोड़ा जाएगा।
अगस्त कार्लस्ट्रोम

27
बिंदु 6 के बारे में अतिरिक्त ध्यान दें: सी मानक में नाम रखने के बारे में कुछ नियम हैं जो _कार्यान्वयन और भविष्य के उपयोग के लिए शुरू होते हैं। नाम के साथ शुरुआत करने के लिए कुछ अपवाद हैं, _लेकिन मेरी राय में यह याद रखने की परेशानी के लायक नहीं है। एक सुरक्षित नियम यह है कि _अपने कोड के साथ शुरू होने वाले नामों का उपयोग कभी न करें । प्रासंगिक सी FAQ प्रविष्टि: c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=decl#namespace
jw013

5
# 2 अधिक विशेष रूप से ऊपरी ऊंट का मामला या पास्कल का मामला है । ऊँट केस या निचला ऊँट केस पहले अक्षर पर कम केस का उपयोग करता है।
क्लिंट पाच

9
स्थानीय बहु-शब्द चर के बारे में क्या? my_var या myVar?
डीन गुरविट्ज़

4
Global variables: just don't use global variables. They are evil.- जब तक आप एम्बेडेड प्रोजेक्ट पर काम नहीं कर रहे हैं और आपके पास 1024 बाइट्स रैम और 8 मेगाहर्ट्ज सीपीयू है।
कामिल

30

"स्ट्रक्चर पॉइंटर्स" ऐसी इकाइयाँ नहीं हैं जिन्हें कवर करने के लिए नामकरण सम्मेलन क्लॉज की आवश्यकता होती है। वे सिर्फ हैं struct WhatEver *। इस तथ्य को छिपाना नहीं है कि एक चतुर और "स्पष्ट" टाइपिडिफ के साथ एक सूचक शामिल है। यह बिना किसी उद्देश्य के कार्य करता है, टाइप करने के लिए लंबा है, और घोषणा और पहुंच के बीच संतुलन को नष्ट कर देता है।


29
+1 "पॉइंटर्स न छुपाएं" सामान के लिए - भले ही यह जवाब बाकी के अधिकांश प्रश्न (अभी तक) को संबोधित नहीं करता है।
जोनाथन लेफ़लर

1
@ ठीक है, मैं सहमत हूँ। हालांकि, कभी-कभी एक पॉइंटर को बाहरी रूप से संदर्भित करने का इरादा नहीं होता है और यह उपभोक्ता को एक वास्तविक पॉइंटर की तुलना में अधिक संभालता है जो वे उपयोग कर रहे हैं। Thats क्या मैं के लिए TitleCasePtr छोड़ दिया है। typedef संरचना {फ़ील्ड} MyStruct, * MyStructPtr;
जेएफवी

मैं TitleCasePtr को हटा रहा हूं, यह वास्तविक प्रश्न से विचलित कर रहा है।
जेफ वीवी

1
-1 से मेरे पास एक पॉइंटर प्रकार की घोषणा अव्यवस्था को कम करती है, विशेष रूप से फ़ंक्शन हस्ताक्षरों में और घोषणा और पहुंच के बीच "असंतुलन" केवल कार्यान्वयन फ़ाइल में दिखाई देता है - क्लाइंट सीधे (नहीं) क्षेत्र के सदस्यों तक पहुंच प्राप्त करता है।
अगस्त कार्लस्ट्रोम

1
@AugustKarlstrom ललित। मुझे समझ में नहीं आता कि कार्यान्वयन फ़ाइल के बारे में इतना "केवल" क्या है, क्या वह कोड नहीं है? मैंने केवल "बाहरी" नामों के बारे में प्रश्न की व्याख्या नहीं की। सभी कोड किसी न किसी स्तर पर "कार्यान्वयन" है।
खोलना

17

खैर पहले C में सार्वजनिक / निजी / आभासी कार्य नहीं हैं। वह C ++ है और इसके अलग-अलग सम्मेलन हैं। सी में आमतौर पर आपके पास है:

  • ALL_CAPS में लगातार
  • संरचनाओं या फ़ंक्शन नामों में शब्दों को चित्रित करने के लिए अंडरस्कोर, शायद ही कभी आप सी में ऊंट मामले को देखते हैं;
  • संरचना, टाइपराइफ, यूनियनों, सदस्यों (यूनियनों और स्ट्रक्चर्स) और एनम का मान आमतौर पर कम मामले (मेरे अनुभव में) के बजाय C ++ / Java / C # / आदि पहले पत्र को पूंजी बनाने का सम्मेलन है, लेकिन लगता है कि यह संभव है सी भी।

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


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

3
आप निजी के रूप में स्थैतिक कार्यों को मान सकते हैं; प्रश्न आभासी का उल्लेख नहीं करता है। लेकिन +1 के लिए 'शायद ही कभी सी में ऊंट-केस देखें'।
जोनाथन लेफ़लर

2
मुझे लगता है कि जेफ का अर्थ external linkage"सार्वजनिक कार्यों" और internal linkage"निजी कार्यों" के लिए था।
दोपहर

1
मैंने स्थिरांक को ak के साथ-साथ kBufferSize से शुरू करते हुए देखा है। यकीन नहीं होता कि कहां से आता है।
जेफवी

2
ALL_CAPSअक्सर एनम मूल्यों के लिए भी उपयोग किया जाता है।
कैफे

14

आप जानते हैं, मैं इसे सरल रखना पसंद करता हूं, लेकिन स्पष्ट है ... तो यहां मैं सी में क्या उपयोग करता हूं:

  • तुच्छ चर :, i,n,cआदि ... (केवल एक अक्षर। यदि एक अक्षर स्पष्ट नहीं है, तो इसे एक स्थानीय चर बनाएं)
  • स्थानीय चर :lowerCamelCase
  • वैश्विक चर :g_lowerCamelCase
  • कांस्टेबल वेरिएबल्स :ALL_CAPS
  • सूचक चर : p_उपसर्ग में जोड़ें । वैश्विक चर के gp_varलिए, यह स्थानीय चर के लिए p_var, कास्ट चर के लिए होगा p_VAR। यदि दूर के बिंदुओं का उपयोग किया जाता है तो fp_इसके बजाय का उपयोग करें p_
  • संरचनाएं : ModuleCamelCase(मॉड्यूल = पूर्ण मॉड्यूल नाम, या 2-3 पत्र संक्षिप्त नाम, लेकिन फिर भी CamelCase।)
  • संरचना सदस्य चर :lowerCamelCase
  • एनम :ModuleCamelCase
  • Enum मान :ALL_CAPS
  • सार्वजनिक कार्य :ModuleCamelCase
  • निजी कार्य :CamelCase
  • मैक्रोज़ :CamelCase

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

पूर्ण struct उदाहरण :

typdef struct TheName TheName;
struct TheName{
    int var;
    TheName *p_link;
};

मुझे qt फ्रेमवर्क के बारे में कुछ भी पता नहीं है, लेकिन आप जो भी शैली प्रारूप में चाहते हैं, उसमें अपना कोड लिख सकते हैं। जहां तक ​​मैं जानता हूं, उससे कुछ भी नहीं रखा जा रहा है।
सीनरमी

10

एक ही समय में C #, जावा, C, C ++ और उद्देश्य C में कोडिंग , मैंने अपने जीवन को सरल बनाने के लिए एक बहुत ही सरल और स्पष्ट नामकरण सम्मेलन को अपनाया है।

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

फिर, सम्मेलन:

  • किसी भी नाम को एक पठनीय वाक्य होना चाहिए जो आपको समझाए। जैसे "यह मेरा सम्मेलन है"।
  • फिर, एक वाक्य से एक कन्वेंशन पाने के 4 तरीके:
    1. मैक्रोज़, एनम सदस्यों के लिए THIS_IS_MY_CONVENTION
    2. ThisIsMyConvention फ़ाइल नाम, वस्तु का नाम (वर्ग, struct, enum, संघ ...), समारोह का नाम, विधि नाम, typedef के लिए
    3. यह वैश्विक और स्थानीय चर,
      पैरामीटर, संरचना और संघ तत्व है
    4. यह विस्मयादिबोधक [वैकल्पिक] बहुत स्थानीय और अस्थायी चर (जैसे कि एक के लिए) (लूप इंडेक्स)

और बस।

यह देता है

class MyClass {
    enum TheEnumeration {
        FIRST_ELEMENT,
        SECOND_ELEMENT,
    }

    int class_variable;

    int MyMethod(int first_param, int second_parameter) {
        int local_variable;
        TheEnumeration local_enum;
        for(int myindex=0, myindex<class_variable, myindex++) {
             localEnum = FIRST_ELEMENT;
        }
    }
}

8

मैं ऊंट मामले और अंडरस्कोर पृथक्करण को मिलाने के खिलाफ सिफारिश करूंगा (जैसे कि आप संरचना सदस्यों के लिए प्रस्तावित)। यह भ्रामक है। आप सोचते होंगे, अरे मेरे पास get_lengthऐसा है तो मुझे शायद होना चाहिए make_subsetऔर तब आपको पता चलता है कि यह वास्तव में है makeSubset। कम से कम विस्मय के सिद्धांत का उपयोग करें, और सुसंगत रहें।

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


1
हां, किसी भी नामकरण सम्मेलन के बारे में मुख्य बात भविष्यवाणी और स्थिरता है। इसके अलावा, क्योंकि सी लाइब्रेरी स्पेसिंग के लिए _ के साथ सभी लोअरकेस का उपयोग कर रही है, इसलिए मैं यह प्रयोग करने की सलाह दूंगा कि बस आपको एक प्रोजेक्ट में 2 अलग-अलग नामकरण सम्मेलनों से निपटने की जरूरत नहीं है (यह मानते हुए कि आप लिबास बनाने के लिए चारों ओर एक आवरण नहीं लिखते हैं यह आपके नामकरण के अनुरूप है .. लेकिन स्थूल है)
अर्लज़

यह अंत में एक " टी" के साथ टाइपडिफ का भी उपयोग करता है , लेकिन मैं किसी को भी इसकी सिफारिश नहीं करता। वास्तव में, मानक पुस्तकालय और भी असंगत है: div_t (stdlib.h) एक संरचना है और इसलिए tm (time.h) है। इसके अलावा, tm संरचना के सदस्यों पर एक नज़र डालें, वे सभी tm के साथ उपसर्ग करते हैं जो व्यर्थ और बदसूरत (IMO) लगता है।
जेफवी

1
"मुझे नाम टाइप करने के लिए कैमलकेज़ उपयोगी लगता है ..." यदि आप इसे बंद कर देते हैं, तो यह वास्तव में पास्कलकेस है।
टैग

7

यहाँ (जाहिरा तौर पर) एक असामान्य है, जो मैंने उपयोगी पाया है: CamelCase में मॉड्यूल का नाम, फिर एक अंडरस्कोर, फिर CamelCase में फ़ंक्शन या फ़ाइल-स्कोप नाम। उदाहरण के लिए:

Bluetooth_Init()
CommsHub_Update()
Serial_TxBuffer[]

2
इतना असामान्य नहीं है, फिर भी बहुत उपयोगी है।
chux -

3

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

मेरे द्वारा जोड़े जाने वाले एकमात्र सुझाव के बारे में मुझे uint32_t और size_t की शैली के प्रकारों के अंत में _t पसंद है। यह मेरे लिए बहुत सी-ईश है, हालांकि कुछ शिकायत कर सकते हैं कि यह सिर्फ "उल्टा" हंगेरियन है।


3
खैर, यहाँ सम्मेलनों सभी जगह और असंगत हैं, यही वजह है कि मैं एक दस्तावेज तैयार कर रहा हूं। इसके अलावा, यह मैं क्यों पूछ रहा हूँ। यह देखने के लिए कि समुदाय की सहमति क्या है।
जेफवी नोव

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

7
मेरा मानना ​​है कि _t में टाइप होने वाले नाम POSIX मानक द्वारा आरक्षित हैं।
कैफे नोव

4
_T के साथ नाम परिष्करण आरक्षित हैं। देखें gnu.org/software/libc/manual/html_node/Reserved-Names.html , "नाम जो '_t' के साथ समाप्त होते हैं, वे अतिरिक्त प्रकार के नामों के लिए आरक्षित हैं।"
Augtienne

2

ऑटो नाम को आसान बनाने के लिए आपको शब्दों के क्रम के बारे में भी सोचना चाहिए ।

एक अच्छा अभ्यास: पुस्तकालय का नाम + मॉड्यूल का नाम + क्रिया + विषय

यदि कोई भाग प्रासंगिक नहीं है, तो उसे छोड़ दें, लेकिन कम से कम एक मॉड्यूल नाम और एक क्रिया हमेशा प्रस्तुत की जानी चाहिए।

उदाहरण:

  • समारोह का नाम: os_task_set_prio, list_get_size,avg_get
  • परिभाषित (यहाँ आमतौर पर कोई कार्रवाई नहीं ):OS_TASK_PRIO_MAX

0

कई हो सकते हैं, मुख्य रूप से आईडीई कुछ रुझान तय करते हैं और सी ++ कन्वेंशन भी जोर दे रहे हैं। आमतौर पर सी के लिए:

  • UNDERSCORED_UPPER_CASE (स्थूल परिभाषाएँ, स्थिरांक, एनम सदस्य)
  • अंडरस्क्राइब_लोवर_केस (चर, कार्य)
  • CamelCase (कस्टम प्रकार: संरचना, एनम, यूनियन)
  • अनकैप्डैमेलकैसे (opp जावा शैली)
  • UnderScored_CamelCase (वैरिएबल, नाम के प्रकार के तहत कार्य)

ग्लोबल्स के लिए हंगेरियन नोटेशन ठीक है लेकिन प्रकारों के लिए नहीं। और यहां तक ​​कि तुच्छ नामों के लिए, कृपया कम से कम दो वर्णों का उपयोग करें।


-1

मुझे लगता है कि वे शुरुआत के लिए मदद कर सकते हैं: सी में चर का नामकरण सम्मेलन

  1. आपको अल्फाबेटिक कैरेक्टर (az, AZ), डिजिट (0-9) और अंडर स्कोर (_) का उपयोग करना होगा। यह किसी विशेष वर्ण जैसे:%, $, #, @ आदि का उपयोग करने की अनुमति नहीं देता है। इसलिए, आप user_name को चर के रूप में उपयोग कर सकते हैं, लेकिन उपयोगकर्ता और नाम का उपयोग नहीं कर सकते ।
  2. शब्दों के बीच सफेद स्थान का उपयोग नहीं कर सकते। इसलिए, आप user_name या उपयोगकर्ता नाम या उपयोगकर्ता नाम को चर के रूप में उपयोग कर सकते हैं लेकिन उपयोगकर्ता नाम का उपयोग नहीं कर सकते
  3. अंक के साथ नामकरण शुरू नहीं कर सकते। तो, आप user1 या user2 को चर के रूप में उपयोग कर सकते हैं लेकिन 1user का उपयोग नहीं कर सकते ।
  4. यह संवेदनशील भाषा है। अपरकेस और लोअरकेस महत्वपूर्ण हैं। यदि आप उपयोगकर्ता नाम जैसे चर का उपयोग करते हैं तो आप USERNAME या उपयोगकर्ता नाम का उपयोग नहीं कर सकते पिता के उपयोग के लिए ।
  5. आप किसी भी कीवर्ड का उपयोग नहीं कर सकते (चार, इंट, यदि, के लिए, जबकि आदि) चर घोषणा के ।
  6. ANSI मानक एक चर नाम के लिए 31 वर्णों की लंबाई को पहचानता है

इस पोस्ट का स्पष्ट रूप से नामकरण सम्मेलनों पर चर्चा करना है , न कि प्रतिबंध । आपने जो चीजें सूचीबद्ध की हैं, वे आप भी नहीं कर सकते क्योंकि वे वाक्यविन्यास त्रुटियां हैं।
पीछा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.