हमारी कॉन्फ़िग फ़ाइल में ज़्यादातर कमेंट क्यों हैं

इस सर्वर की .htaccess फ़ाइल 478 लाइनों की है। इनमें से 98 नियम हैं। 309 कमेंट हैं।

कुछ करने वाली हर लाइन के लिए व्याख्या की तीन लाइनें। यह अनुपात योजना से नहीं बना; यह तब होता है, जब नियम लिखने का नियम यह हो कि उसकी वजह ठीक उसके बगल में लिखी जाए।

एक रीराइट नियम को पूरे पैराग्राफ़ की ज़रूरत क्यों है

सर्वर कॉन्फ़िगरेशन का कोई नियम बाद में पढ़े जाने के लिए असाधारण रूप से प्रतिकूल होता है। वह जान-बूझकर संक्षिप्त होता है, उसका कोई नाम नहीं होता, उसे कदम-दर-कदम चलाकर नहीं देखा जा सकता, और उसका असर तब तक दिखता नहीं, जब तक ठीक वही पता न माँगा जाए। छह महीने बाद “यह यहाँ क्यों है” का अकेला ईमानदार जवाब आम तौर पर एक अंदाज़ा होता है।

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

इसलिए यहाँ हर नियम के साथ लिखा है कि वह किसलिए है और उसे कहाँ जाँचा जा सकता है। कमेंट की ग्यारह लाइनों में तारीख है, बारह में मापा गया आँकड़ा। यही दो चीज़ें भविष्य के पाठक को यह तय करने देती हैं कि वजह अब भी कायम है या नहीं।

तीन नियम, जो अपने कमेंट के बिना नहीं बचते

एक भाषा कोड, जो स्क्रिप्ट एक्सटेंशन जैसा दिखता था। बची हुई सोर्स फ़ाइलों को रोकने वाला एक नियम एक्सटेंशन से मिलान करता था, और उनमें से एक एक्सटेंशन था .pl — Perl। डिज़ाइन प्रीव्यू के नाम इस तरह रखे जाते हैं: 2900.pl.svg, जहाँ pl का मतलब है पोलिश। हर पोलिश प्रीव्यू 403 लौटाने लगा, जबकि बाकी सभी भाषाएँ ठीक थीं। अब कमेंट बताता है कि pl सूची से जान-बूझकर गायब है, क्यों, और किस दिन क्या मापा गया था। इसके बिना सूची को सँवारने वाला अगला व्यक्ति इसे वापस डाल देगा।

दो स्विच, जहाँ एक काफ़ी लगता है। पहले से कंप्रेस की गई फ़ाइलों को भेजते समय दोबारा कंप्रेस नहीं किया जाना चाहिए। कॉन्फ़िगरेशन यह सेट करता है: no-gzip, जो सर्वर के दो कंप्रेसरों में से एक को रोकता है। दूसरा कंप्रेसर तैयार फ़ाइल को दोबारा कंप्रेस करता रहा, जबकि हेडर अब भी gzip बता रहा था, और ब्राउज़रों को ऐसी सामग्री मिली जो पढ़ी नहीं जा सकती थी। कमेंट बताता है कि no-gzip और no-brotli दोनों क्यों मौजूद हैं, क्योंकि दूसरे को हटाना सफ़ाई जैसा लगता है।

रोक का एक उल्टा नियम। बैकअप कॉपियों को रोकने वाला नियम वर्जित एक्सटेंशनों की सूची नहीं बनाता। वह पूछता है कि क्या किसी फ़ाइल नाम में ऐसा सोर्स एक्सटेंशन है, जो अंत में नहीं है — इससे वे नाम भी पकड़े जाते हैं, जो अभी तक किसी ने सोचे ही नहीं। कमेंट उन पाँच नामों की सूची देता है, जिन पर सीधा-सादा वर्ज़न गलत निकला था, उनके स्टेटस कोड के साथ। अकेले नियम को पढ़ने पर वह बेवजह चालाक लगता है; कमेंट पढ़ने पर वह अकेली चीज़ लगती है जो काम करती है।

आम सबक

जो कमेंट कोड को ही दोहराते हैं, वे बेकार हैं, और यह सब जानते हैं। ये वैसे नहीं हैं। ये वह दर्ज करते हैं जो कोड नहीं कर सकता: क्या गलत हुआ, क्या मापा गया, किस तारीख को, और कौन-सा विकल्प खारिज किया गया।

कोई कमेंट लिखने लायक है या नहीं, इसकी कसौटी काफ़ी सरल है। अगर उसके ऊपर की लाइन को कोई ऐसा व्यक्ति हटा दे, जिसे पूरी कहानी नहीं पता, तो क्या कुछ चुपचाप टूट जाएगा? अगर हाँ, तो कहानी लिख दें। अगर नहीं, तो कुछ भी न लिखें।

तीन के मुकाबले एक कोई लक्ष्य नहीं है। यह वही है, जो इस कसौटी ने एक ऐसी फ़ाइल पर दिया, जिसकी लगभग हर लाइन इसलिए मौजूद है कि कुछ खास गलत हुआ था।