HTML / CSS नामकरण परंपराओं (वाक्य रचना) के लिए व्यावहारिक विचार [बंद]

28

प्रश्न: वाक्य रचना classऔर idमूल्यों के लिए व्यावहारिक विचार क्या हैं ?

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

इस प्रश्न के कारण पूछने के लिए:

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

मैंने जिन कुछ सम्मेलनों का उपयोग करने पर विचार किया है:

UpperCamelCase, मुख्य रूप से सर्वर साइड कोडिंग से एक क्रॉस-ओवर आदत के रूप में
lowerCamelCaseजावास्क्रिप्ट नामकरण सम्मेलनों के साथ स्थिरता के लिए
css-style-classes, जो सीएसएस गुणों के नामकरण के अनुरूप है (लेकिन Ctrl + Shift + ArrowKey पाठ का चयन होने पर कष्टप्रद हो सकता है)
with_under_scores, जिसे मैंने व्यक्तिगत रूप से ज्यादा इस्तेमाल नहीं किया है
alllowercase, याद रखना आसान है, लेकिन लंबे नामों के लिए पढ़ना कठिन हो सकता है
UPPERCASEFTW, अपने साथी प्रोग्रामर को नाराज़ करने का एक शानदार तरीका (शायद पठनीयता के लिए विकल्प 4 के साथ संयुक्त)

और शायद मैंने कुछ महत्वपूर्ण विकल्प या संयोजन भी छोड़ दिए हैं। तो: सम्मेलनों के नामकरण के लिए क्या विचार हैं, और वे किस सम्मेलन का नेतृत्व करते हैं?

— जेरोन
स्रोत

CamelCaseEverythingInCode

— रियाथल

11

BUT_WHY_WOULD_YOU_DO_THAT_IS_THE_QUESTION? ;)

— जीरन

मैं आमतौर पर कक्षाओं और कैमलकेस को और सब कुछ कम करता हूं। कोई विशेष कारण नहीं है

— अंटर्ड बर्ड

"सीएसएस शैली-वर्ग, जो सीएसएस गुणों के नामकरण के अनुरूप है (लेकिन जब Ctrl + Shift + ArrowKey पाठ का चयन होता है तो यह कष्टप्रद हो सकता है)" - यदि आप उप-इष्टतम पाठ संपादक का उपयोग करते हैं तो केवल एक मुद्दा है ;-)

— एडवर्ड

@Rathal वह PascalCase (या UpperCamelCase), camelCase (या लोअरकेमसेलकैसे) इस तरह दिखता है।

— डैनी व्रोड

18

बाउंटी या नहीं, कुछ हद तक चुनाव हमेशा "वरीयता का मामला" होगा - आखिरकार, आपको कैसा लगेगा यदि W3C ने एक निश्चित सम्मेलन की सिफारिश की (या लगाया भी गया) जो आपको सही नहीं लगा?

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

(5.) justnoteasilyreadablebecauseyoudontknowwherewordsstartandend।

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTING।

(4.) historical_incompatibility_plus_see: मोज़िला देव प्रलेखन ।

(3.) एक बिट-ट्रिकियर-टू-एक्सप्लेन ... जैसा कि आप उल्लेख करते हैं, टेक्स्ट एडिटर्स में सेलेबिलिटी एक मुद्दा है (जैसा कि संपादक पर निर्भर करता है), लेकिन मेरे लिए यह भी तथ्य है कि यह मुझे याद दिलाता है सिंटैक्स विक्रेता-विशिष्ट कीवर्ड के लिए आरक्षित है , भले ही वे हाइफ़न के साथ-साथ उनके द्वारा अलग किए गए शब्दों के साथ शुरू हों।

तो यह क्रमशः आपके (1.) और (2.), अपरकंपेलसीस और लोअरकैमेलकैसे को छोड़ देता है। जावा कक्षाओं के मानसिक लिंक के बावजूद (जो कि अधिक स्पष्ट रूप से परिभाषित कन्वेंशन, अपरकैमेलकैसे द्वारा हैं), सीएसएस वर्ग के नाम मुझे लगते हैं, एक लोअरकेस अक्षर से शुरू होने से बेहतर होगा। शायद यह एक्सएचटीएमएल तत्व और विशेषता नामों के कारण है , लेकिन मुझे लगता है कि आप यह भी मामला बना सकते हैं कि सीएसएस कक्षाएं अपरकेमसेल का उपयोग करने से उन्हें अलग करने में मदद मिलेगी। यदि आपको एक और कारण की आवश्यकता है, तो लोअरकेमेलकैस वह है जो डब्ल्यू 3 सी का उपयोग अच्छे वर्ग के नाम के उदाहरणों में किया जाता है (हालांकि URL स्वयं, नाराज होकर, मुझसे असहमत है)।

मैं ऊपर दिए गए कारणों के लिए (4.), (5.) और (6.) के खिलाफ सलाह दूंगा, लेकिन मान लीजिए कि अन्य तीनों में से किसी के लिए भी तर्क दिया जा सकता है।

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

— अमोस एम। बढ़ई
स्रोत

धन्यवाद! आप उल्लेख करते हैं (अधिकांश अन्य उत्तरों की तरह) यह वरीयता का मामला है, लेकिन कुछ व्यावहारिक सलाह के साथ इसे पूरक भी करते हैं, और अधिक महत्वपूर्ण विचार (जैसे कि one_on_icompatability) पर कुछ अच्छे लिंक। भले ही मैं अभी भी @tdammers के उत्तर (नामकरण-साथ-डैश) में सुझाव के साथ जाने पर विचार करता हूं, यहां दिया गया उत्तर वह है जो वास्तव में मेरे द्वारा पूछे गए प्रश्न का उत्तर देता है। तो: इनाम + स्वीकार किए जाते हैं, साथ ही कई धन्यवाद :)

— Jeroen

कई धन्यवाद वापस - जब तक आप सुसंगत रहते हैं, मुझे लगता है कि उन तीनों में से कोई भी ठीक है। उनके बीच बहुत कुछ नहीं है, और यदि आप नेट पर साइटों को देखते हैं, तो मुझे यकीन है कि आप प्रत्येक के बहुत सारे उदाहरण पाएंगे;;

— आमोस एम। बढ़ई

+1 हालाँकि, मुझे यकीन है कि यह एक बुरी बात है। जब मैं नामकरण, स्वरूपण और सामान्य शैली सम्मेलनों पर समुदाय संचालित मानकों के प्रयासों के लिए हूं , तो एकरूपता की कमी परियोजना विरासत को एक बुरा सपना बना सकती है ( यह कहने के लिए नहीं कि इस तरह के बुरे सपने मानकों द्वारा समाप्त हो जाएंगे, वे शायद नहीं होंगे इसके बाद ) तथ्य यह है कि सीएसएस, कमज़ोर और घोषणात्मक, क्लाइंट और सर्वर साइड एप्लिकेशन लॉजिक के साथ सरल हुक के रूप में भी परस्पर क्रिया करता है, यह एकीकृत संरचना के लिए तरसता है (इसके द्वारा मुझे चिंता होती है, मेरा मतलब है कि मैं बहुत खुश हूं )

— Dan Lugg

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

— मैट ब्राउन

7

CSS क्लास के नाम में शब्दों को डैश ( class-name) के साथ अलग किया जाना चाहिए , क्योंकि CSS गुणों और छद्म वर्गों में शब्दों को अलग किया गया है और उनके सिंटैक्स को CSS स्पेक्स द्वारा परिभाषित किया गया है ।

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

— इमानुइल रुसेव
स्रोत

आह +1, मुझे यूआरएल के आईडी का उल्लेख पसंद है। हालाँकि यह मज़ेदार सा है, इस पर कुछ मज़ाक करने के लिए, मैं यह जाँचने गया कि यह विकिपीडिया कैसे करता है। उदाहरण के लिए विकिपीडिया सीएसएस लेख के ब्राउजर समर्थन खंड ने दिया <span id="Browser_support" class="mw-headline">Browser support</span>: O

— Jeroen

3

यह ज्यादातर वरीयता का मामला है; कोई स्थापित मानक नहीं है, मामले पर अकेले एक आधिकारिक स्रोत दें। जो भी आपको सबसे अधिक आरामदायक लगे, उसका उपयोग करें; बस संगत रहो।

व्यक्तिगत रूप से, मैं उपयोग करता हूं css-style-with-dashes, लेकिन मैं बहु-शब्द वर्ग नामों से बचने और कई वर्गों का उपयोग करने का प्रयास करता हूं जहां भी संभव हो (इसलिए button important defaultइसके बजाय button-important-default)। मेरे अनुभव से, यह उच्च-गुणवत्ता वाली वेब साइटों और चौखटे के बीच सबसे लोकप्रिय विकल्प भी लगता है।

डैश के साथ लोअरकेस भी अन्य विकल्पों की तुलना में टाइप करना आसान है (हार्ड-टू-रीड nowordseparatorswhatsoeverकन्वेंशन को छोड़कर ), कम से कम यूएस कीबोर्ड पर, क्योंकि इसे Shift कुंजी का उपयोग करने की आवश्यकता नहीं है।

आईडी के लिए, अतिरिक्त व्यावहारिक विचार है कि यदि आप तत्वों को उनकी आईडी से सीधे जावास्क्रिप्ट (जैसे document.forms[0].btn_ok) में संदर्भित करना चाहते हैं , तो डैश इतनी अच्छी तरह से काम नहीं करेगा - लेकिन, यदि आप jQuery का उपयोग कर रहे हैं, तो आप शायद जा रहे हैं किसी $()भी तरह से उनका उपयोग करें , तो आप बस हो सकता है $('#btn-ok'), जो इस बिंदु को ज्यादातर लूट बनाता है।

रिकॉर्ड के लिए, एक और सम्मेलन मैं नियमित रूप से पार चलो आईडी में हंगेरी मौसा तत्व प्रकार इंगित करने के लिए, विशेष रूप से प्रपत्र नियंत्रण के लिए उपयोग करता है - तो आप होगा #lblUsername, #tbUsername, #valUsernameउपयोगकर्ता नाम लेबल, इनपुट, और सत्यापनकर्ता के लिए।

— tdammers
स्रोत

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

— जेरोएन

2

मैं दृढ़ता से इस बात पर विश्वास करता हूं कि सबसे ज्यादा मायने रखती है।

इसे देखने के दो तरीके हैं:

alllowercaseया css-style-clauses(शायद बेहतर विकल्प) के लिए एक अच्छा तर्क दिया जा सकता है क्योंकि वे उस कोड के साथ सबसे अधिक संगत होंगे जो वे अंदर होंगे। यह कोड के लिए एक अधिक प्राकृतिक प्रवाह उधार देगा और कुछ भी झटके या जगह से बाहर नहीं होगा। ।
एक समान रूप से अच्छा तर्क एक शैली के लिए बनाया जा सकता है जो HTML टैग नामों या सीएसएस क्लॉस से अलग है, अगर यह आईडी और कक्षाओं को एक तरह से अलग कर देगा जो पठनीयता को सहायता करता है। उदाहरण के लिए, यदि आपने UpperCamelCaseआईडी और कक्षाओं के लिए उपयोग किया है, और किसी अन्य निर्माण या उद्देश्य के लिए इसका उपयोग नहीं किया है, तो आपको पता होगा कि आपने उस प्रारूप में टोकन देखा था। एक प्रतिबंध यह लगाया जा सकता है कि यह सबसे प्रभावी होगा यदि हर आईडी या वर्ग 2+ शब्द का नाम हो, लेकिन यह कई मामलों में उचित है।

इस उत्तर को लिखने में मुझे पता चला कि मैं दूसरी पसंद की ओर बहुत अधिक इच्छुक हूं, लेकिन मैं दोनों को छोड़ दूंगा क्योंकि मुझे लगता है कि दोनों मामले मेरिट हैं।

— asfallows
स्रोत

-1

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

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

— ड्वेन चारिंगटन
स्रोत

-3

आप एक साधारण तथ्य से बेखबर लग रहे हैं: अधिकांश सीएसएस प्रोग्रामर द्वारा नहीं किया जाता है ।

यह ग्राफिक डिजाइनरों द्वारा किया जाता है।

वे हमारे संपादन युद्धों के बारे में परवाह नहीं करते हैं और हम इस बारे में कम परवाह नहीं कर सकते हैं कि हम शिफ्ट कुंजी के साथ क्या करते हैं।
वे शायद यह भी नहीं जानते हैं कि फैंसी _कुंजी कहाँ है । (या इसका नाम क्या है)

वे कोड सौंदर्यशास्त्र के बारे में परवाह नहीं करते हैं , वे सौंदर्यशास्त्र सौंदर्यशास्त्र के बारे में परवाह करते हैं ।

(और वे वहाँ एक बिंदु हो सकता है)

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

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

— ZJR
स्रोत

3

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

— एड जेम्स