03 दिस॰ 2025·8 मिनट
कर्निघन पर प्रोग्रामिंग स्पष्टता: चालाकी से बेहतर स्वाद
ब्रायन कर्निघन का “अच्छा स्वाद” बताता है कि कैसे पठनीय कोड समय बचाता है, बग घटाता है, और चालाक तरकीबों से बेहतर टीमों को तेज़ी से आगे बढ़ने में मदद करता है।
ब्रायन कर्निघन का “अच्छा स्वाद” बताता है कि कैसे पठनीय कोड समय बचाता है, बग घटाता है, और चालाक तरकीबों से बेहतर टीमों को तेज़ी से आगे बढ़ने में मदद करता है।
ब्रायन कर्निघन का नाम उन जगहों पर मिलता है जिनका उपयोग कई डेवलपर्स बिना सोचे करते हैं: क्लासिक Unix टूल्स, C पारिस्थितिकी, और दशकों की लेखनी जिसने लोगों को प्रोग्राम्स को साफ़ तरीके से समझाना सिखाया। चाहे आप The C Programming Language (Dennis Ritchie के साथ), The Unix Programming Environment, या उनके निबंध और बातें याद रखें — आम धागा सरल विचारों को साफ़ ढंग से व्यक्त करने की जिद है।
कर्निघन की सबसे अच्छी सलाह C सिंटैक्स या Unix रीति-रिवाजों पर निर्भर नहीं करती। यह इस बात के बारे में है कि इंसान कैसे पढ़ते हैं: हम संरचना के लिए स्कैन करते हैं, नामों पर निर्भर करते हैं, इरादे का अनुमान लगाते हैं, और जब कोड मतलब छिपाता है तो भ्रमित हो जाते हैं। इसलिए जब आप TypeScript, Python, Go, Java, या Rust लिख रहे होते हैं तब भी पठनीयता में “स्वाद” मायने रखता है।
भाषाएँ बदलती हैं। टूलिंग बेहतर होती है। टीमें अभी भी समय के दबाव में फीचर शिप करती हैं, और अधिकांश कोड मूल लेखक के अलावा किसी और द्वारा मेंटेन किया जाता है (अक्सर भविष्य-आप)। स्पष्टता वह गुणनकर्ता है जो इन सबको संभालने योग्य बनाता है।
यह “हीरो कोडिंग” का गुणगान नहीं है और न ही पुराने नियमों को याद करने का आह्वान। यह उन आदतों के लिए एक व्यावहारिक गाइड है जो रोज़मर्रा के कोड को काम करने में आसान बनाती हैं:
कर्निघन का प्रभाव इसलिए महत्वपूर्ण है क्योंकि यह एक सरल, टीम-फ्रेंडली लक्ष्य की ओर इशारा करता है: ऐसा कोड लिखो जो संवाद करता हो। जब कोड एक स्पष्ट व्याख्या की तरह पढ़ता है, तो आप उसे डिकोड करने में कम समय खर्च करते हैं और उसे बेहतर बनाने में ज़्यादा।
पठनीय कोड में “अच्छा स्वाद” व्यक्तिगत शैली, फैंसी पैटर्न, या समाधान को न्यूनतम लाइनों में संकुचित करने का मामला नहीं है। यह उस आदत का नाम है जिसमें आप ऐसा सबसे सरल और स्पष्ट विकल्प चुनते हैं जो भरोसेमंद तरीके से इरादे संप्रेषित करे।
एक अच्छा-स्वाद समाधान अगले पाठक के लिए एक बुनियादी प्रश्न का उत्तर देता है: यह कोड क्या करने की कोशिश कर रहा है, और इसे इस तरह क्यों किया गया है? अगर उस उत्तर के लिए मानसिक व्यायाम, छिपी धारणाएँ, या चालाक तरकीबों को डीकोड करना पड़ता है, तो कोड टीम का समय बर्दाश्त कर रहा है।
अधिकांश कोड लिखा जाने की तुलना में बहुत ज़्यादा पढ़ा जाता है। “अच्छा स्वाद” पढ़ने को प्राथमिक गतिविधि मानता है:
इसीलिए पठनीयता सिर्फ़ सौंदर्यशास्त्र (इंडेंटेशन, लाइन चौड़ाई, या आप snake_case पसंद करते हैं या नहीं) नहीं है। वे मददगार हैं, पर “अच्छा स्वाद” मुख्य रूप से तर्क को आसान बनाने के बारे में है: साफ़ नाम, स्पष्ट नियंत्रण प्रवाह, और अनुमानित संरचना।
एक सामान्य गलती संक्षेप के लिए ऑप्टिमाइज़ करना है न कि स्पष्टता के लिए। कभी-कभी सबसे स्पष्ट कोड थोड़ा लंबा होता है क्योंकि वह कदमों को स्पष्ट कर देता है।
उदाहरण के लिए, इन दो दृष्टिकोणों की तुलना करें:
दूसरा संस्करण कुछ लाइनें जोड़ सकता है, पर यह सत्यापन के लिए आवश्यक संज्ञानात्मक भार घटा देता है। यह बग्स को अलग करना और बदलाव सुरक्षित रूप से लागू करना भी आसान बनाता है।
अच्छा स्वाद जानना है कि कब चालाकी के साथ “सुधार” बंद करना है और इरादे को स्पष्ट करना है। अगर कोई साथी बिना आपके मार्गदर्शन के कोड समझ सके, तो आपने अच्छा चुना है।
चतुर कोड अक्सर पल में जीत जैसा लगता है: कम लाइनें, एक सूक्ष्म तरकीब, diff में “वाह” कारक। असल टीम में वह चतुराई recurring बिल बन जाती है—जो ऑनबोर्डिंग समय, रिव्यू समय, और हर बार कोड छेड़ने पर हिचक के रूप में भुगतान होती है।
ऑनबोर्डिंग धीमी पड़ती है। नए साथी केवल प्रोडक्ट नहीं सीखते; उन्हें आपकी निजी शॉर्टकट भाषा भी सीखनी पड़ती है। अगर किसी फ़ंक्शन को समझने के लिए चालाक ऑपरेटर्स या निहित कन्वेंशन को डीकोड करना पड़ता है, तो लोग उसे बदलने से बचेंगे—या डर के साथ बदलेंगे।
रिव्यूज़ लंबे और कम भरोसेमंद हो जाते हैं। रिव्यूअर यह साबित करने में ऊर्जा बर्बाद करते हैं कि तरकीब सही है, बजाय यह देखे कि व्यवहार इरादे से मेल खाता है। बदतर बात यह है कि चतुर कोड की मानसिक सिमुलेशन कठिन होती है, इसलिए रिव्यूअर उन एज केस्स को छोड़ देते हैं जिन्हें सरल संस्करण पकड़ सकता था।
चतुराई जोड़ती है:
दो-तीन बार दिखने वाले अपराधी:
17, 0.618, -1) जो नियम एन्कोड करते हैं जिन्हें कोई याद नहीं रखता।\u0026\u0026 / || तरकीबें) जो पाठक के सूक्ष्म मूल्यांकन नियमों के ज्ञान पर निर्भर करते हैं।कर्निघन का “स्वाद” का बिंदु यहीं आता है: स्पष्टता अधिक लिखने के बारे में नहीं है; यह इरादे को स्पष्ट करने के बारे में है। अगर “स्मार्ट” संस्करण आज 20 सेकंड बचाता है पर हर भविष्य के पाठक के लिए 20 मिनट खर्च कराता है, तो वह स्मार्ट नहीं बल्कि महंगा है।
कर्निघन का “स्वाद” अक्सर छोटे, दोहराने योग्य निर्णयों में दिखता है। बड़े रीफैक्टर की ज़रूरत नहीं—छोटी स्पष्टता जीतें हर बार जमा होती हैं जब कोई फ़ाइल स्कैन करता है, व्यवहार खोजता है, या समय दबाव में बग फिक्स करता है।
एक अच्छा नाम टिप्पणियों की आवश्यकता घटाता है और गलतियों को छिपना कठिन बनाता है।
इरादा-प्रकट करने वाले नामों का लक्ष्य रखें जो आपकी टीम की भाषा से मेल खाते हों:
sum के बजाय invoiceTotalCents पसंद करें।अगर किसी नाम को डीकोड करना पड़ता है, तो वह अपना काम उल्टा कर रहा है।
अधिकांश पढ़ना स्कैनिंग है। लगातार व्हाइटस्पेस और संरचना आँख को यह खोजने में मदद करती है कि क्या महत्वपूर्ण है: फ़ंक्शन सीमाएँ, कंडीशन्स, और “हैप्पी पाथ”।
कुछ व्यावहारिक आदतें:
जब लॉजिक जटिल हो जाता है, पठनीयता आम तौर पर निर्णयों को स्पष्ट करके सुधरती है।
इन दो शैलियों की तुलना करें:
// Harder to scan
if (user \u0026\u0026 user.active \u0026\u0026 !user.isBanned \u0026\u0026 (role === 'admin' || role === 'owner')) {
allow();
}
// Clearer
if (!user) return deny('missing user');
if (!user.active) return deny('inactive');
if (user.isBanned) return deny('banned');
if (role !== 'admin' \u0026\u0026 role !== 'owner') return deny('insufficient role');
allow();
दूसरा संस्करण लंबा है, पर यह एक चेकलिस्ट की तरह पढ़ता है—और विस्तार करने पर भी बिना टूटे आसान रहता है।
ये “छोटी” चुनाव हैं, पर ये मेंटेनेबल कोड की रोज़मर्रा की कला हैं: ईमानदार नाम, पाठक को मार्गदर्शन करने वाला फ़ॉर्मैटिंग, और ऐसा कंट्रोल फ्लो जो आपको मानसिक व्यायाम करने पर मजबूर न करे।
कर्निघन की स्पष्टता की शैली सबसे ज़्यादा दिखती है कि आप काम को फ़ंक्शन्स और मॉड्यूल में कैसे तोड़ते हैं। एक पाठक को संरचना स्किम करके अनुमान लगाना चाहिए कि हर हिस्से का क्या काम है—और विवरण पढ़ने से पहले वह ज्यादातर ठीक होना चाहिए।
ऐसे फ़ंक्शन्स का लक्ष्य रखें जो एक ही “ज़ूम स्तर” पर एक ही काम करें। जब एक फ़ंक्शन वैलिडेशन, बिजनेस नियम, फॉर्मैटिंग, और I/O मिलाता है, तो पाठक को कई थ्रेड्स दिमाग में रखना पड़ता है।
एक त्वरित परीक्षण: अगर आप फ़ंक्शन के अंदर "// now do X" जैसा कमेंट लिख रहे हैं, तो अक्सर X को एक अलग नाम वाले फ़ंक्शन में रखना अच्छा संकेत है।
लंबी पैरामीटर सूचियाँ एक छिपा हुआ जटिलता कर हैं: हर कॉल साइट एक मिनी-कन्फिगरेशन बन जाती है।
यदि कई पैरामीटर हमेशा साथ चलते हैं, तो उन्हें समझदारी से ग्रुप करें। विकल्प ऑब्जेक्ट्स (या छोटे डेटा स्ट्रक्ट्स) कॉल साइट्स को स्व-स्पष्टीकरणीय बना सकते हैं—बशर्ते आप समूह को सारगर्भित रखें और सब कुछ एक "misc" बैग में न डालें।
इसके अलावा, प्रिमिटिव्स के बजाय डोमेन कांसेप्ट्स पास करने को प्राथमिकता दें। UserId किसी string से बेहतर है, और DateRange (start, end) से बेहतर जब उन मानों के नियम हों।
मॉड्यूल वादे होते हैं: “जिस कॉन्सेप्ट के लिए तुम्हें सब चाहिए वो यहाँ है, और बाकी कहीं और है।” मॉड्यूल इतने छोटे रखें कि आप उनका उद्देश्य दिमाग में रख सकें, और सीमाएँ ऐसी बनाएं जो साइड-इफेक्ट्स कम करें।
सहायक आदतें:
जब साझा स्टेट की ज़रूरत हो, तो उसे ईमानदारी से नाम दें और इनवारियंट्स का दस्तावेज़ रखें। स्पष्टता जटिलता से बचने के बारे में नहीं है—यह उसे वहाँ रखने के बारे में है जहाँ पाठक उम्मीद करें। अधिक बदलावों के दौरान इन सीमाओं को बनाये रखने के बारे में और पढ़ें: /blog/refactoring-as-a-habit.
कर्निघन का “स्वाद” इस बात में दिखता है कि आप कैसे टिप्पणी करते हैं: उद्देश्य हर लाइन को एनोटेट करना नहीं है, बल्कि भविष्य के भ्रम को कम करना है। सबसे अच्छी टिप्पणी वह है जो गलत धारणा को रोकती है—खासकर जब कोड सही है पर आश्चर्यजनक हो।
कोड को दोहराने वाली टिप्पणी ("i को इन्क्रीमेंट करो") अव्यवस्था जोड़ती है और पाठकों को टिप्पणियाँ अनदेखा करने सिखाती है। उपयोगी टिप्पणियाँ इरादा, ट्रेडऑफ़, या उन सीमाओं को समझाती हैं जो सिंटैक्स से स्पष्ट नहीं हैं।
# Bad: says what the code already says
retry_count += 1
# Good: explains why the retry is bounded
retry_count += 1 # Avoids throttling bans on repeated failures
अगर आप “क्या” टिप्पणियाँ लिखने के लिए प्रेरित हो रहे हैं, तो अक्सर यह संकेत होता है कि कोड को साफ़ करना चाहिए (बेहतर नाम, छोटा फ़ंक्शन, सरल नियंत्रण प्रवाह)। कोड तथ्य बढ़ाये; टिप्पणियाँ तर्क रखें।
कुछ भी भरोसा तबाही कर देता है जितनी जल्दी एक पुरानी टिप्पणी गलत हो जाए। अगर एक टिप्पणी वैकल्पिक है, तो वह समय के साथ ड्रिफ्ट करेगी; अगर गलत हो, तो वह सक्रिय बग का स्रोत बन जाती है।
एक व्यावहारिक आदत: टिप्पणी अपडेट को परिवर्तन का हिस्सा मानें, न कि "हो जाएगा"। रिव्यूज़ के दौरान यह पूछना उचित है: क्या यह टिप्पणी अभी भी व्यवहार से मेल खाती है? अगर नहीं, तो या तो इसे अपडेट करें या हटा दें। "कोई टिप्पणी नहीं" गलत टिप्पणी से बेहतर है।
इनलाइन टिप्पणियाँ स्थानीय आश्चर्यों के लिए हैं। व्यापक मार्गदर्शन docstrings, READMEs, या डेवलपर नोट्स में रखें—खासकर:
एक अच्छी docstring बताएगी कि फ़ंक्शन को सही तरीके से कैसे उपयोग करें और कौन सी त्रुटियाँ अपेक्षित हैं, बिना इम्प्लीमेंटेशन के वर्णन के। एक छोटा /docs या /README नोट “हमने इसे इस तरह क्यों किया” कहानी पकड़ सकता है ताकि वह रीफ़ैक्टर के दौरान भी बची रहे।
मौन जीत: कम टिप्पणियाँ, पर हर एक की अपनी कीमत हो।
अधिकांश कोड हैप्पी पाथ पर "ठीक" दिखता है। स्वाद की सच्ची परीक्षा तब होती है जब इनपुट गायब हो, सर्विस टाइमआउट करे, या यूज़र कुछ अप्रत्याशित करे। दबाव में, चतुर कोड सचाई छिपा देता है; स्पष्ट कोड विफलता को स्पष्ट—और रिकवर करने योग्य—बना देता है।
त्रुटि संदेश आपका उत्पाद और डिबगिंग वर्कफ़्लो का हिस्सा हैं। उन्हें ऐसे लिखें जैसे अगला व्यक्ति थका हुआ और ऑन-लॉक है।
शामिल करें:
यदि आपके पास लॉगिंग है, तो संरचित संदर्भ जोड़ें (जैसे requestId, userId, या invoiceId) ताकि संदेश बिना अप्रासंगिक डेटा खोदे actionable हो।
हर चीज को एक clever one-liner में निपटाने की प्रवृत्ति होती है। अच्छा स्वाद उन कुछ एज केस्स को चुनने में है जो मायने रखते हैं और उन्हें दिखाई देने वाला बनाना है।
उदाहरण के लिए, “empty input” या “not found” के लिए एक स्पष्ट ब्रांच अक्सर एक श्रृंखला-आधारित ट्रांसफ़ॉर्म के बजाय बेहतर पढ़ता है जो कहीं null पैदा कर देता है। जब कोई विशेष मामला महत्वपूर्ण हो, उसे नाम दें और सामने रखें।
विभिन्न वापसी शेप्स (कभी ऑब्जेक्ट, कभी स्ट्रिंग, कभी false) पाठकों को मानसिक निर्णय वृक्ष रखने के लिए मजबूर करता है। उन पैटर्न्स को पसंद करें जो सुसंगत रहें:
साफ़ विफलता हैंडलिंग आश्चर्य घटाती है—और आश्चर्य वहाँ पनपता है जहाँ बग और मध्यरात्रि की कॉल्स जन्म लेती हैं।
स्पष्टता केवल इसके बारे में नहीं है कि आप क्या मतलब रखते थे जब आपने कोड लिखा। यह इस बारे में भी है कि अगला व्यक्ति फ़ाइल खोलते समय क्या देखने की उम्मीद करेगा। संगति पढ़ना पैटर्न पहचान में बदल देती है—कम आश्चर्य, कम गलतफहमियाँ, और कम बहसें जो हर स्प्रिंट दोहराई जाती हैं।
एक अच्छा टीम स्टाइल गाइड छोटा, विशिष्ट और व्यावहारिक होता है। यह हर पसंद नहीं दर्ज करने की कोशिश करता; यह बार-बार सवालों को सुलझाता है: नामकरण कन्वेंशन्स, फ़ाइल संरचना, त्रुटि-हैंडलिंग पैटर्न, और टेस्ट के लिए "है क्या"।
असल मूल्य सोशल है: यही वही बहस रोकता है जो हर नए PR में दोहराई जाती है। जब कुछ लिखित हो, रिव्यूज़ "मुझे X पसंद है" से बदलकर "हमने X पर सहमति बनायी थी (और कारण)।" बन जाते हैं। इसे जीवंत और खोजने में आसान रखें—कई टीमें इसे रेपो में पिन करती हैं (उदा., /docs/style-guide.md) ताकि यह कोड के पास रहे।
फॉर्मैटर्स और लिन्टर्स उन चीजों के लिए उपयोग करें जो मापने योग्य और उबाऊ हैं:
इससे इंसानों को अर्थ पर ध्यान देने की आज़ादी मिलती है: नामकरण, API आकार, एज केस्स, और क्या कोड इरादे से मेल खाता है।
मैनुअल नियम तब भी मायने रखते हैं जब वे डिज़ाइन विकल्पों को बयान करते हैं—उदा., "नेस्टिंग कम करने के लिए early returns पसंद करें" या "प्रति मॉड्यूल एक सार्वजनिक एंट्री पॉइंट"। टूल्स उन सभी का फैसला नहीं कर सकते।
कभी-कभी जटिलता जायज़ होती है: कड़ा परफॉर्मेंस बजट, एम्बेडेड सीमाएँ, कठिन concurrency, या प्लेटफ़ॉर्म-विशेष व्यवहार। समझौता यह होना चाहिए: अपवाद अनुमति हैं, पर स्पष्ट होने चाहिए।
एक सरल मानक मदद करता है: ट्रेडऑफ़ को छोटा टिप्पणी में दस्तावेज़ करें, प्रदर्शन का हवाला देते समय माइक्रो-बेंचमार्क या माप दिखाएँ, और जटिल कोड को एक साफ़ इंटरफ़ेस के पीछे अलग रखें ताकि कोडबेस का अधिकांश हिस्सा पठनीय रहे।
एक अच्छा कोड रिव्यू निरीक्षण की तरह महसूस नहीं होना चाहिए बल्कि “अच्छे स्वाद” की एक छोटी, केंद्रित पाठ होनी चाहिए। कर्निघन का तर्क यह नहीं कि चतुर कोड बुरा है—बल्कि यह कि जब दूसरे लोग उसके साथ जीना पड़ता है तो चतुराई महँगी होती है। रिव्यूज़ वह जगह हैं जहाँ टीमें इस ट्रेडऑफ़ को दिखा सकती हैं और जानबूझकर स्पष्टता चुन सकती हैं।
शुरूआत में पूछें: "क्या कोई साथी एक पास में इसे समझ सकता है?" इसका अर्थ आम तौर पर नामकरण, संरचना, टेस्ट, और व्यवहार देखना है, माइक्रो-ऑप्टिमाइज़ेशन्स में जाने से पहले।
अगर कोड सही है पर पढ़ने में कठिन, तो पठनीयता को एक वास्तविक दोष मानें। सुझाव दें: नामों को बदलना ताकि इरादा झलके, लंबे फ़ंक्शन्स को विभाजित करना, नियंत्रण प्रवाह को सरल बनाना, या एक छोटा टेस्ट जोड़ना जो अपेक्षित व्यवहार दिखाए। एक रिव्यू जो पकड़ता है "यह काम करता है, पर मैं नहीं समझ पा रहा कि क्यों" भविष्य में हफ्तों की भ्रम को रोकता है।
एक व्यावहारिक क्रम जो अच्छा काम करता है:
रिव्यूज़ तब उलझ जाते हैं जब फीडबैक अंकगणित जैसा हो। "आपने ऐसा क्यों किया?" की जगह कोशिश करें:
प्रश्न सहयोग को आमंत्रित करते हैं और अक्सर उन बंदिशों को उजागर करते हैं जिनके बारे में आपको पता नहीं था। सुझाव दिशा बताते हैं बिना क्षमता पर उंगली उठाए। यह वही टोन है जिससे टीम में “स्वाद” फैलता है।
यदि आप निरंतर पठनीयता चाहते हैं तोReviewer के मूड पर भरोसा मत करें। अपनी रिव्यू टेम्पलेट और definition of done में कुछ "clarity checks" जोड़ें। उन्हें छोटा और विशिष्ट रखें:
समय के साथ, यह रिव्यूज़ को शैली पर पुलिसिंग से निर्णय सिखाने में बदल देता है—ठीक वही रोज़मर्रा की अनुशासन जो कर्निघन का प्रचार था।
LLM टूल्स काम करने वाला कोड जल्दी बना सकते हैं, पर कर्निघन जिस मापदंड की ओर इशारा कर रहे थे वह "चलता है" नहीं बल्कि "संचार करता है" है। यदि आपकी टीम चैट-आधारित वर्कफ़्लो का उपयोग करती है और जेनरेटेड कोड के साथ इंटरेट करती है, तो पठनीयता को प्राथमिक स्वीकृति मानक बनाना समझदारी है।
प्लेटफ़ॉर्म्स जैसे Koder.ai पर, जहाँ आप चैट प्रॉम्प्ट से React फ्रंटेंड्स, Go बैकएंड्स, और Flutter मोबाइल ऐप्स जेनरेट कर सकते हैं (और बाद में सोर्स कोड एक्सपोर्ट कर सकते हैं), वही स्वाद-चालित आदतें लागू होती हैं:
स्पीड तब सबसे ज़्यादा मूल्यवान है जब आउटपुट इंसानों के लिए रिव्यू, मेंटेन और एक्सटेंड करने में आसान हो।
स्पष्टता कोई एक बार की उपलब्धि नहीं है। कोड पठनीय तब तक रहती है जब तक आप इसे बदलते हुए धीरे-धीरे वापस साधारण भाषा की ओर धकेलते रहते हैं। कर्निघन की सोच यहाँ फिट बैठती है: बहादुर रीराइट्स या आज़ादी दिखाने वाली चतुर एक-लाइनरों के बजाय धीरे-धीरे, समझदारी भरे सुधारों को पसंद करें।
सबसे सुरक्षित रीफ़ैक्टरिंग बोरिंग होती है: छोटे बदलाव जो व्यवहार.identical रखते हैं। हर कदम के बाद टेस्ट चलाएँ। यदि आपके पास टेस्ट नहीं हैं, तो उस हिस्से के चारों ओर कुछ फोकस्ड चेक जोड़ें—इन्हें अस्थायी गार्डरेल समझें ताकि आप संरचना बिना भय के सुधार सकें।
एक व्यावहारिक ताल:
छोटे कमिट्स रिव्यू को भी आसान बनाते हैं: साथियों को इरादा पर निर्णय लेना आसान होता है, साइड-इफेक्ट्स नहीं खोजना पड़ता।
आपको हर "चतुर" उपकरण को एक बार में हटाना जरूरी नहीं। जब आप किसी कोड को फीचर या बगफिक्स के लिए छूते हैं, तब चतुर शॉर्टकट्स को सरल समकक्षों से बदलें:
इस तरह स्पष्टता असली टीम्स में जीतती है: हर बार जब कोई काम कर रहा होता है, वही हॉटस्पॉट सुधरता है।
सभी क्लीनअप तात्कालिक नहीं होता। एक उपयोगी नियम: कोड तब रीफ़ैक्टर करें जब वह सक्रिय रूप से बदल रहा हो, बार-बार गलत समझा जा रहा हो, या बग का कारण बनने की संभावना हो। बाद में शेड्यूल करें जब वह स्थिर और अलग हो।
रीफ़ैक्टरिंग कर्ज़ को दृश्यमान रखें: एक छोटा TODO छोड़ें संदर्भ के साथ, या एक टिकट जोड़ें जो दर्द का वर्णन करे ("नए पेमेंट मेथड्स जोड़ना कठिन; फ़ंक्शन 5 काम करता है")। फिर आप जानबूझकर निर्णय ले सकते हैं—बनियादी तौर पर भ्रमित कोड टीम का नियमित कर नहीं बनने देते।
यदि आप चाहते हैं कि "अच्छा स्वाद" लगातार दिखे, तो इसे अभ्यास में लाना आसान बनाएं। यहाँ एक हल्का-फुल्का चेकलिस्ट है जिसे आप प्लानिंग, कोडिंग और रिव्यू में दोहरा सकते हैं—याद रखने के लिए छोटा, क्रिया करने के लिए पर्याप्त विशिष्ट।
पहले: process(data) एक जगह वैलिडेशन, पार्सिंग, सेविंग, और लॉगिंग करता है।
बाद में: इसे validateInput, parseOrder, saveOrder, logResult में बाँट दें। मुख्य फ़ंक्शन पठनीय रूप से एक रूपरेखा बन जाता है।
पहले: if not valid then return false पाँच बार重复।
बाद में: एक अग्रिम गार्ड सेक्शन (या एक validation फ़ंक्शन) जो स्पष्ट मुद्दों की सूची लौटाता है।
पहले: x, tmp, flag2, doThing()।
बाद में: retryCount, draftInvoice, isEligibleForRefund, sendReminderEmail()।
पहले: एक लूप जिसमें बीच में तीन विशेष मामले छिपे हों।
बाद में: विशेष मामलों को पहले हैंडल करें (या हेल्पर्स में निकालें), फिर साधारण लूप चलाएँ।
इस सप्ताह अपनाने के लिए एक सुधार चुनें: “कोई नई संक्षेप नहीं”, “पहले हैप्पी पाथ”, “हर PR पर एक हेल्पर निकालें”, या “हर त्रुटि संदेश में अगला कदम शामिल हो।” इसे सात दिनों तक ट्रैक करें, फिर वही रखें जिसने वास्तव में पढ़ना आसान किया।
कर्निघन का प्रभाव सी तक सीमित नहीं है; यह एक टिकाऊ सिद्धांत है: कोड संचार का एक माध्यम है।
भाषाएँ और फ्रेमवर्क बदलते रहते हैं, लेकिन टीमों को ऐसा कोड चाहिए जो जल्दी स्कैन, समझा, रिव्यू और डिबग हो सके—खासकर महीनों बाद या दबाव में।
“अच्छा स्वाद” का मतलब है लगातार सबसे सरल और स्पष्ट विकल्प चुनना जो इरादे बताता हो।
एक उपयोगी परीक्षण है: क्या कोई साथी ये बता सकता है—“यह क्या कर रहा है, और यह इस तरह क्यों किया गया है?”—बिना चालाक तरकीबों को डीकोड किए या छिपी धारणाओं पर निर्भर हुए।
क्योंकि अधिकांश कोड पढ़ा जाता है उससे कहीं ज्यादा लिखा जाता है।
पाठकों के लिए ऑप्टिमाइज़ करने से ऑनबोर्डिंग समय, रिव्यू घर्षण और गलत बदलाव के जोखिम कम होते हैं—खासकर जब मेंटेनर “भविष्योन्मुख आप” होता है जिसकी संदर्भ कम होता है।
“चतुराई कर होने वाला कर्ज़” रोज़मर्रा में ऐसे दिखता है:
यदि चतुर संस्करण आज कुछ सेकंड बचाता है पर हर बार छेड़छाड़ पर मिनट्स खर्च कराता है, तो यह घाटे में है।
आम रूप से नुकसान पहुँचाने वाले पैटर्न:
ये पैटर्न मध्यवर्ती स्टेट छिपाते हैं और रिव्यू में एज केस्स चूकने देते हैं।
जब यह संज्ञानात्मक भार कम कर दे।
नाम दिए हुए इंटरमीडिएट वेरिएबल्स (जैसे validate → normalize → compute) के साथ कदम स्पष्ट करना correctness सत्यापित करना, डिबगिंग को सरल बनाना और भविष्य के बदलाव सुरक्षित करना आसान कर सकता है—भले ही इससे कुछ लाइनों का इज़ाफ़ा हो।
लक्ष्य रखें:
invoiceTotalCents बजाय sum)यदि किसी नाम को डीकोड करना पड़ता है, तो वह अपना काम नहीं कर रहा—नाम टिप्पणी की आवश्यकता कम कर दे।
सरल, स्पष्ट ब्रांचिंग पसंद करें और “हैप्पी पाथ” को प्रमुख रखें।
सहायक उपाय:
क्या करना चाहिए:
अच्छी टिप्पणियाँ इरादा, ट्रेडऑफ़ या अनजाने नियमों को समझाती हैं। स्पष्ट कोड लिखने की कोशिश करें; अगर आप “क्या” टिप्पणी लिखने का मन कर रहा है, तो शायद कोड को सुधारा जाना चाहिए।
टिप्पणियाँ अपडेट करने को बदलाव का हिस्सा मानें—गलत टिप्पणी न होने से बेहतर है।
यंत्रों के लिए निर्धारित नियम और लोगों के लिए अर्थ।