आप पुस्तकालयों

Question

अधिकांश सी ++ नामकरण की परंपरा के उन लोगों के साथ आम सी ++ नामकरण रिवाजों का कैसे सामंजस्य करते camelCaseIdentifiers के उपयोग के हुक्म और चर (getPrice(), isValid(), largestValue)। ये अनुशंसाएं सी ++ पुस्तकालय का नामकरण सम्मेलनों, जो वर्गों (string, set, map, fstream) और तरीकों और क्षेत्रों के लिए names_joined_with_an_underscore (find_first_of, lower_bound, reverse_iterator, first_type) के लिए लोअरकेस नाम शामिल साथ अंतर पर पूरी तरह से कर रहे हैं। तस्वीर को और जटिल बनाने के लिए ऑपरेटिंग सिस्टम और सी लाइब्रेरी फ़ंक्शंस हैं, जिनमें सी और यूनिक्स में संपीड़ित लोअरकेस नाम शामिल हैं और विंडोज़ में अपरकेस अक्षर से शुरू होने वाले फ़ंक्शन शामिल हैं।

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

तो, आप इन अलग-अलग नामकरण सम्मेलनों का मेल कैसे करते हैं?

Answer 1

सी ++ naming_convention को अपनाने का एक तरीका यह है कि साहित्य में आजकल अधिकांश कोड उदाहरण हैं।

मैं धीरे-धीरे इन सम्मेलनों को उत्पादन कोड में ले जाता हूं लेकिन यह एमएफसी नामकरण सम्मेलनों के खिलाफ एक लड़ाई है जो अभी भी कई स्थानों पर प्रबल है।

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

Answer 2

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

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

Answer 3

मेल करने की आवश्यकता क्यों है? जब तक कोड संकलित होता है, और आप काम पूरा कर सकते हैं, इसके बारे में चिंता न करें।

Answer 4

Fav बोली ::

मानकों के बारे में सबसे अच्छी बात वहाँ से चुनने के लिए बहुत सारे हैं कि है!

मेरे सुझाव है कि सबसे अधिक बार अपनी कंपनी के कोड में होता है (शायद सी ++ पुस्तकालय है, जो मैं भी करने के लिए लाठी को बढ़ावा देने का मानना ​​है) लाइब्रेरी की सम्मेलन लेते हैं, और अपने मानक कि बनाने के लिए किया जाएगा। अन्यथा, आप भी एक बिल्कुल नहीं हो सकता है।

Answer 5

परियोजनाओं में मैं काम कर रहा हूं, मैं अपने प्रोजेक्ट के लिए कोड सम्मेलनों का पालन करता हूं। जब मैं कुछ और कहता हूं तो मैं उस पुस्तकालय के एपीआई का उपयोग करता हूं।

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

Answer 6

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

अंत में मैंने लिखने वाले सभी नए कोड (Google सी ++ शैली दिशानिर्देशों के आधार पर) के लिए एक ही शैली अपनाई है और मैं उपयुक्त होने पर इस शैली का उपयोग करने के लिए पुराने कोड को दोबारा प्रतिक्रिया देता हूं। आप अलग-अलग नामकरण सम्मेलनों को आसानी से मेल नहीं कर सकते हैं, इसलिए कोशिश करने में समय बर्बाद न करें। अपनी टीम/विभाग/कंपनी के लिए एक योजना लागू करें - लेकिन योजनाओं के मिश्रण का उपयोग करते समय कोड को 'बदसूरत' कैसे देख सकता है, इस पर लटका नहीं है।

Google सी ++ दिशानिर्देश बहुत अच्छे IMHO हैं - कुछ मामूली संशोधन के साथ। यहाँ गाइड की जाँच करें:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Answer 7

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

Answer 8

मुझे लगता है कि लंबे समय से पढ़ना याद है कि वे टकराव नामकरण से बचने के लिए मानक पुस्तकालय को उद्देश्य पर अनुशंसित कोडिंग सम्मेलन से अलग करना चुनते हैं। मुझे कोई संदर्भ नहीं मिल रहा है जो कि अब उल्लेख करता है। मुझे याद है कि आपको प्रमुख लोअरकेस अक्षरों का प्रकार नामों में उपयोग नहीं करना चाहिए क्योंकि वे मानक पुस्तकालयों के लिए आरक्षित थे। मुझे लगता है कि अंडरस्कोर के उपयोग के साथ कुछ ऐसा चल रहा है। मुझे वास्तव में एक समस्या के रूप में एकाधिक नामकरण सम्मेलनों को नहीं दिखाई देता है, क्योंकि यह स्पष्ट रूप से मानक प्रोजेक्ट को आपके प्रोजेक्ट में कोड से अलग करता है। मैं हमेशा परियोजनाओं के लिए पूंजी ऊंट मामले और विधियों/सदस्यों के लिए कम ऊंट मामले का उपयोग कर अपनी परियोजनाओं में सामान कोड करता हूं। मेरी वर्तमान कार्यस्थल प्रकार के अलावा विधियों के लिए पूंजी ऊंट केस का उपयोग करती है, जो मुझे बहुत परेशान करती है। लेकिन, वे हंगेरियन वार्स भी पसंद करते हैं, जो एमएस ने भी अस्वीकार कर दिया है: पी

Answer 9

ईमानदारी से, मैं पुस्तकालय का उपयोग करता हूं और अपनी कोडिंग शैली से चिपक जाता हूं। आप इसे लपेट सकते हैं, लेकिन यह अधिकतर की तरह लगता है।

Answer 10

आपको अंतर को गले लगा देना चाहिए।

जब लोग remove_copy_if का उपयोग देखते हैं, तो उन्हें तुरंत पता चलेगा कि यह एक एल्गोरिदम है। यह वास्तव में एक सकारात्मक विशेषता है क्योंकि एल्गोरिदम कुछ गारंटी (या की कमी) के साथ आते हैं।

हम अपने स्वयं के कस्टम एल्गोरिदम के लिए नामकरण सम्मेलन का भी उपयोग करते हैं।