अगर मैं और कोड लिखता रहूंगा तो एक समय आएगा जब मेरे लिए कोड को व्यवस्थित करना मुश्किल होगा।
यह आपकी समस्या है: संगठन को ठीक से प्राप्त करें, और शैली को अधिक आसानी से प्रवाह करना चाहिए।
अपने कोड को व्यवस्थित करने के लिए प्रतीक्षा न करें : जैसे ही आप जाते हैं, अपना कोड व्यवस्थित रखें। यद्यपि भाषा आपके लिए ऐसा नहीं करती है, फिर भी कोड को कम युग्मन और उच्च सामंजस्य वाले मॉड्यूल में व्यवस्थित किया जाना चाहिए।
ये मॉड्यूल तब स्वाभाविक रूप से एक नाम स्थान प्रदान करते हैं। टकराव से बचने के लिए अपने मॉड्यूल के साथ मॉड्यूल नाम (यदि यह लंबा है) और उपसर्ग फ़ंक्शन नामों को संक्षिप्त करें।
व्यक्तिगत पहचानकर्ताओं के स्तर पर, ये मोटे तौर पर व्यक्तिवाद के बढ़ते क्रम में हैं:
- एक सम्मेलन चुनें और इसके साथ रहें
- जैसे,
function_like_this(struct TypeLikeThis variable)आम है
निश्चित रूप से हंगेरियन नोटेशन से बचें (क्षमा करें JNL)
जब तक आप मूल रूप से इरादा के रूप में इसका उपयोग करने के लिए तैयार नहीं होते हैं, जिसका अर्थ है कि सिमोनी के ऐप नोटेशन भयानक सिस्टम संस्करण के बजाय
क्यों? मैं इस बारे में एक निबंध लिख सकता था, लेकिन मैं आपको जोएल स्पोल्स्की के इस लेख को पढ़ने के बजाय सुझाव दूंगा , और फिर अगर आप रुचि रखते हैं, तो कुछ और के आसपास शिकार करें। तल पर सिमोनी के मूल पेपर का लिंक है।
जब तक वे वास्तव में अपारदर्शी कुकी प्रकार के नहीं होते हैं, तब तक पॉइंटर टाइपडिफ्स से बचें - वे केवल चीजों को भ्रमित करते हैं
struct Type *ok;
typedef struct Type *TypePtr;
TypePtr yuck;
मुझे एक अपारदर्शी कुकी प्रकार से क्या मतलब है ? मेरा मतलब है कि किसी मॉड्यूल (या लाइब्रेरी, या जो कुछ भी) का उपयोग ग्राहक कोड के लिए किया जाना है, लेकिन वह ग्राहक कोड सीधे उपयोग नहीं कर सकता है। यह सिर्फ पुस्तकालय में वापस जाता है।
उदाहरण के लिए, एक डेटाबेस लाइब्रेरी एक इंटरफ़ेस को उजागर कर सकती है जैसे
/* Lots of buffering, IPC and metadata magic held in here.
No, you don't get to look inside. */
struct DBContextT;
/* In fact, you only ever get a pointer, so let's give it a nice name */
typedef struct DBContexT *DBContext;
DBContext db_allocate_context(/*maybe some optional flags?*/);
void db_release_context(DBContext);
int db_connect(DBContext, const char *connect);
int db_disconnect(DBContext);
int db_execute(DBContext, const char *sql);
अब, संदर्भ क्लाइंट कोड में अपारदर्शी है, क्योंकि आप अंदर नहीं देख सकते। आप इसे वापस पुस्तकालय में भेजते हैं। जैसे कुछ FILEभी अपारदर्शी है, और एक पूर्णांक फ़ाइल विवरणक भी एक कुकी है , लेकिन अपारदर्शी नहीं है।
डिजाइन पर एक नोट
मैंने बिना स्पष्टीकरण के ऊपर वाक्यांश कम युग्मन और उच्च सामंजस्य का उपयोग किया , और मुझे इसके बारे में थोड़ा बुरा लगता है। आप इसके लिए खोज कर सकते हैं, और शायद कुछ अच्छे परिणाम पा सकते हैं, लेकिन मैं इसे संक्षेप में संबोधित करने की कोशिश करूंगा (फिर से, मैं एक निबंध लिख सकता हूं लेकिन कोशिश करूंगा कि नहीं)।
डीबी लाइब्रेरी ऊपर की तरफ कम कपलिंग दिखाती है क्योंकि यह बाहरी दुनिया के लिए एक छोटे इंटरफ़ेस को उजागर करती है। इसके कार्यान्वयन विवरण (आंशिक रूप से अपारदर्शी कुकी चाल के साथ) को छिपाकर, यह ग्राहक कोड को उन विवरणों पर निर्भर होने से रोकता है।
अपारदर्शी कुकी के बजाय कल्पना करें, हम संदर्भ संरचना की घोषणा करते हैं ताकि इसकी सामग्री दिखाई दे, और इसमें डेटाबेस के लिए टीसीपी कनेक्शन के लिए सॉकेट फ़ाइल विवरणक शामिल है। यदि हम बाद में डीबी एक ही मशीन पर चल रहे हैं, तो साझा मेमोरी सेगमेंट का उपयोग करने के लिए कार्यान्वयन को बदल दें, ग्राहक को केवल पुनः लिंक किए जाने के बजाय फिर से संकलित करने की आवश्यकता है। इससे भी बदतर, क्लाइंट फ़ाइल डिस्क्रिप्टर का उपयोग करना शुरू कर सकता है , उदाहरण के setsockoptलिए डिफ़ॉल्ट बफर आकार बदलने के लिए कॉल करना, और अब इसे एक कोड परिवर्तन की भी आवश्यकता है। इन सभी विवरणों को हमारे मॉड्यूल के अंदर छिपाया जाना चाहिए जहां व्यावहारिक है, और यह मॉड्यूल के बीच कम युग्मन देता है ।
उदाहरण उच्च सामंजस्य को भी दर्शाता है , इसमें मॉड्यूल के सभी तरीके समान कार्य (डीबी एक्सेस) से संबंधित हैं। इसका मतलब है कि केवल कोड है कि जरूरतों को कार्यान्वयन विवरण के बारे में पता करने के लिए (यह है कि, हमारे कुकी की सामग्री) वास्तव में उन तक पहुंच है, जो डिबगिंग सरल।
आप यह भी देख सकते हैं कि एक ही चिंता होने से इन कार्यों को एक साथ करने के लिए एक उपसर्ग चुनना आसान हो गया है।
अब, यह कहना आसान है कि यह आसान है (विशेषकर चूंकि यह पूरा भी नहीं हुआ है), लेकिन तुरंत आपकी मदद नहीं करता है। ट्रिक देखने के लिए है, जैसा कि आप लिखते हैं और अपने कोड का विस्तार करते हैं, ऐसे कार्यों के लिए जो समान चीजें करते हैं या एक ही प्रकार पर काम करते हैं (जो अपने स्वयं के मॉड्यूल के लिए उम्मीदवार हो सकते हैं), और उन कार्यों के लिए भी जो बहुत सारी अलग-अलग चीजें करते हैं जो ' टी वास्तव में संबंधित है, और बंटवारे के लिए उम्मीदवार हो सकते हैं।