सी ++ परियोजना स्रोत कोड लेआउट

Question

परियोजना निर्देशिका व्यवस्थित करने के लिए या अधिक कम इस तरह है लोकप्रिय तरीका में से एक:

 
MyLib 
    +--mylib_class_a.h 
     mylib_class_a.cpp 
     mylib_library_private_helpers.h 
     mylib_library_private_helpers.cpp 

MyApp 
    +--other_class.h 
     other_class.cpp 
     app.cpp 

app.cpp: एक ही पुस्तकालय के लिए

#include "other_class.h" 
#include <mylib_class_a.h> // using library MyLib 

सभी .h और .cpp फ़ाइलें हैं एक ही निर्देशिका में। नाम टकराव से बचने के लिए, फ़ाइल नाम अक्सर कंपनी के नाम और/या लाइब्रेरी नाम के साथ उपसर्ग होते हैं। MyLib MyApp के हेडर सर्च पथ, आदि में होगा। मैं फाइलनामों को उपसर्ग करने का प्रशंसक नहीं हूं, लेकिन मुझे #include को देखने का विचार पसंद है और पता है कि वह हेडर फ़ाइल कहां से संबंधित है। मुझे फ़ाइलों को व्यवस्थित करने के इस दृष्टिकोण से नफरत नहीं है, लेकिन मुझे लगता है कि एक बेहतर तरीका होना चाहिए।

जब से मैं एक नई परियोजना शुरू कर, मैं कुछ निर्देशिका संगठन विचारों की प्रार्थना करना चाहते।

 
ProjA 
    +--include 
      +--ProjA 
        +--mylib 
          +--class_a.h 
        +--app 
          +--other_class.h 
    +--src 
     +--mylib 
       +--class_a.cpp 
        library_private_helpers.h 
        library_private_helpers.cpp 
     +--app 
       +--other_class.cpp 
       app.cpp 
       util.h 

app.cpp:

#include "util.h" // private util.h file 
#include <ProjA/app/other_class.h> // public header file 
#include <ProjA/mylib/class_a.h> // using class_a.h of mylib 
#include <other3rdptylib/class_a.h> // class_a.h of other3rdptylib, no name collision 
#include <class_a.h> // not ProjA/mylib/class_a.h 
#include <ProjA/mylib/library_private_helpers.h> // error can't find .h 

.cpp फ़ाइलों और निजी (केवल तत्काल पुस्तकालय देखने योग्य) .h फ़ाइलों src निर्देशिका के अंतर्गत जमा हो जाती है (src कभी कभी lib कहा जाता है) वर्तमान में मैं इस निर्देशिका संरचना की तरह। सार्वजनिक हेडर फ़ाइलों को एक परियोजना/lib निर्देशिका संरचना में व्यवस्थित किया जाता है और <ProjectName/LibraryName/headerName.h> के माध्यम से शामिल किया जाता है। फ़ाइल नाम किसी भी चीज़ के साथ prefixed नहीं हैं। अगर मुझे कभी भी अन्य टीमों द्वारा उपयोग किए जाने के लिए माईलिब को पैकेज करने की आवश्यकता होती है, तो मैं उपयुक्त बाइनरी फ़ाइलों और संपूर्ण शामिल/प्रोजा निर्देशिका की प्रतिलिपि बनाने के लिए बस अपना मेकफ़ाइल बदल सकता हूं।

एक बार फ़ाइलें स्रोत नियंत्रण में जाँच कर रहे हैं और लोगों को उन पर काम शुरू यह निर्देशिका संरचना को बदलने के लिए मुश्किल हो जाएगा। इसे पाने के लिए सही है।

अनुभव इस तरह स्रोत कोड के आयोजन के साथ कोई भी? आपको इसके बारे में कुछ पसंद नहीं है? यदि आपके पास ऐसा करने का बेहतर तरीका है, तो मैं इसके बारे में बहुत कुछ सुनना चाहूंगा।

Answer 1

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

जब आपके पास प्रबंधन करने के लिए कई फाइलें नहीं हैं तो बहुत अधिक फ़ोल्डर्स मेरी राय ओवरकिल में हैं। जब आपको केवल कुछ फाइलें मिलती हैं तो यह फ़ोल्डर्स में और बाहर कष्टप्रद खुदाई हो जाती है।

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

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

KISS आमतौर पर प्रोग्रामिंग में हमेशा समाधान होता है -> जितना संभव हो सके सब कुछ सरल रखें।

Answer 2

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

मैं आमतौर पर इस नियम का उपयोग: अनुप्रयोगों और घर में पुस्तकालयों पहली विधि का उपयोग। सार्वजनिक ओपन सोर्स लाइब्रेरी दूसरी विधि का उपयोग करते हैं। जब आप कोड जारी कर रहे होते हैं, तो इसमें फ़ाइलों की एक अलग निर्देशिका में बहुत मदद मिलती है।

Answer 3

पहले की तरह कुछ क्यों नहीं, केवल निर्देशिका कि MyLib शामिल निर्देश है, जो मूर्ख लगाकर कम कर देता है के भाग के रूप में रहता है का उपयोग करें:

#include <MyLib/ClassA.h> 

कि आपको बताता है कि वे कहाँ से कर रहे हैं। दूसरी पसंद के लिए, जब मैं एक हेडर या स्रोत फ़ाइल खोलता हूं, तो मैं व्यक्तिगत रूप से नाराज हो जाता हूं, और दूसरे को ढूंढने और इसे खोलने के लिए निर्देशिका संरचना के माध्यम से चारों ओर नेविगेट करना पड़ता है। आपके दूसरे उदाहरण के साथ, यदि आपके पास src/mylib/class_a.cpp खुला था, और हेडर को संपादित करना चाहता था, तो कई संपादकों में आपको दो स्तरों पर वापस जाना होगा, फिर शीर्षलेख ढूंढने से पहले include/ProjA में। और हम कैसे जान सकते हैं कि शीर्षलेख ProjA उपनिर्देशिका में किसी अन्य बाहरी सुराग के बिना है? इसके अलावा, एक फ़ाइल के लिए यह बहुत आसान है या दूसरे को एक अलग जगह में स्थानांतरित करने के लिए बहुत आसान है जो "बेहतर" का प्रतिनिधित्व करता है, इसका उपयोग कैसे किया जाता है, वैकल्पिक फ़ाइल को स्थानांतरित किए बिना। जब मैं इसे अपने काम पर सामना करता हूं तो यह मुझे सिरदर्द देता है (और हमारे पास हमारे कोडबेस के कुछ हिस्सों हैं जहां लोगों ने अभी तक हर संभावित समस्या का उल्लेख किया है)।