प्रोग्राम लिखते समय कभी ऐसा मन होता है कि कोड को कमाल की चतुराई से एक पंक्ति में समेट दें या ऐसा अनोखा समाधान अपनाएँ जो दूसरों को आसानी से न सूझे। ऐसा इसलिए होता है क्योंकि छोटा और चतुर कोड अपनी कुशलता का प्रमाण लगता है। लेकिन कुछ महीनों बाद उसी कोड में त्रुटि आने पर अक्सर उसे लिखने वाले व्यक्ति को भी उसका अर्थ समझने के लिए देर तक देखना पड़ता है। इसी स्थिति को सटीक ढंग से बयान करने वाला अनुभवजन्य नियम है ‘कर्निहैन का नियम (Kernighan's Law)’।
सरल शब्दों में, कर्निहैन के नियम का अर्थ है कि ‘त्रुटियाँ खोजकर सुधारना पहली बार कोड लिखने से दोगुना कठिन होता है, इसलिए यदि आप अपनी पूरी चतुराई लगाकर कोड लिखते हैं, तो आप स्वयं उसे सुधार नहीं पाएँगे।’ चतुराई से अधिक स्पष्टता को महत्व देने की यह सलाह आज भी प्रोग्रामरों के बीच व्यापक रूप से उद्धृत की जाती है।
इस सामग्री में हम क्रम से देखेंगे कि कर्निहैन का नियम किस पृष्ठभूमि में सामने आया, उसके कथन का क्या अर्थ है, उससे जुड़ी गलतफहमियाँ क्या हैं और व्यावहारिक काम में उसे कैसे अपनाया जा सकता है।
चतुर कोड की तुलना में स्पष्ट कोड अधिक समय तक क्यों टिकता है
बेल प्रयोगशालाओं से निकला एक कथन
यह कथन लिखने वाले ब्रायन कर्निहैन (Brian Kernighan) कनाडा में जन्मे कंप्यूटर वैज्ञानिक हैं, जिन्होंने अमेरिका की बेल प्रयोगशालाओं में काम किया। उन्होंने डेनिस रिची (Dennis Ritchie) के साथ मिलकर वह पुस्तक लिखी जिसे C भाषा की मानक पाठ्यपुस्तक माना जाता है, और यूनिक्स के विकास में भी गहराई से भाग लिया। पाठ प्रसंस्करण भाषा awk के नाम के तीन अक्षरों में K भी उन्हीं के उपनाम से लिया गया है। वे 2000 से प्रिंसटन विश्वविद्यालय में विद्यार्थियों को पढ़ा रहे हैं।
- स्रोत (The Elements of Programming Style): यह कथन 1974 में उनके सहकर्मी पी. जे. प्लॉगर (P. J. Plauger) के साथ प्रकाशित पुस्तक ‘प्रोग्रामिंग शैली के तत्व’ में आया था।
- संशोधित संस्करण (Second Edition): 1978 में संस्करण 2 प्रकाशित हुआ, और यह कथन सूत्रों तथा व्यंजकों पर केंद्रित अध्याय 2 में शामिल है।
- लेखन की प्रेरणा (Textbook Examples): दोनों लेखकों ने उस समय की पाठ्यपुस्तकों में दिए गए खराब ढंग से लिखे FORTRAN और PL/I कोड को एक-एक करके सुधारा और उनसे अच्छे कोड के नियम निकाले।
पुस्तक का शीर्षक लेखन संबंधी प्रसिद्ध मार्गदर्शिका ‘शैली के तत्व (The Elements of Style)’ से प्रेरित है। पूरी पुस्तक इस विचार पर आधारित है कि अच्छे वाक्य की तरह अच्छे कोड का अर्थ भी अनावश्यक विस्तार के बिना स्पष्ट होना चाहिए।
दोगुना कठिन होने का अर्थ
मूल कथन के दो वाक्यों का अर्थ है, ‘जैसा कि सभी जानते हैं, डीबगिंग पहली बार प्रोग्राम लिखने से दोगुनी कठिन होती है। तो यदि आपने लिखते समय अपनी पूरी चतुराई लगा दी, तो आखिर उसकी डीबगिंग कैसे करेंगे?’ यहाँ डीबगिंग (Debugging) का अर्थ प्रोग्राम की त्रुटियों, यानी बग, को खोजकर सुधारना है।
(1) सुधारना लिखने से कठिन है
कोड लिखते समय हमारा उद्देश्य मन में ताजा होता है, लेकिन त्रुटि खोजते समय हमें पीछे की ओर जाँचते हुए पता लगाना पड़ता है कि उद्देश्य और वास्तविक व्यवहार में कहाँ अंतर आया। यह इसलिए अधिक कठिन होता है क्योंकि गलती उसी हिस्से में कहीं छिपी होती है जिसे हम सही मान रहे थे।
(2) पूरी चतुराई लगा देने पर आगे के लिए क्षमता नहीं बचती
अपनी क्षमता की अंतिम सीमा तक जाकर लिखे गए कोड की डीबगिंग जब उससे दोगुनी कठिन होती है, तो हमारी क्षमता कम पड़ जाती है। यहाँ दोगुना कोई सटीक माप नहीं, बल्कि अंतर बड़ा होने पर जोर देने की अभिव्यक्ति है।
(3) इसलिए स्पष्ट ढंग से लिखना चाहिए
निष्कर्ष यह है कि अपनी कुछ चतुराई बचाकर रखें। यदि शुरुआत से ही ऐसा कोड लिखें जिसे अपनी लगभग आधी क्षमता से समझ सकें, तो बाद में समस्या आने पर बची हुई क्षमता से उसका कारण आसानी से खोज सकते हैं। वास्तव में, इसी पुस्तक में यह नियम भी दिया गया है: ‘स्पष्ट लिखें, जरूरत से ज्यादा चतुर बनने की कोशिश न करें (Write clearly - don't be too clever)।’
नियम से जुड़ी गलतफहमियाँ
कर्निहैन का नियम संक्षिप्त और चुटीला है, इसलिए कभी-कभी उसका अर्थ मूल आशय से अलग भी समझ लिया जाता है।
क्या इसका अर्थ कठिन तकनीकों का उपयोग न करना है
यह नियम कठिन तकनीकों के उपयोग पर अपने आप में रोक नहीं लगाता। जहाँ जरूरी हो वहाँ परिष्कृत तरीका अपनाना और आसानी से हल हो सकने वाली समस्या को जानबूझकर उलझाना अलग बातें हैं। जिस आदत से बचना चाहिए, वह है शान दिखाने के लिए समझने में कठिन कोड लिखना। अक्षरों की संख्या अधिकतम घटाने का खेल, कोड गोल्फ (Code Golf), दिमाग की एक मजेदार कसरत है, लेकिन ऐसा कोड वास्तविक सेवा में ज्यों का त्यों डाल देने पर उसे सुधारने वाले को परेशानी होती है।
कर्निहैन के उत्तोलक के रूप में एक अलग व्याख्या
स्वीडन के प्रोग्रामर लिनुस ओकेसोन (Linus Åkesson) ने इस कथन को ‘कर्निहैन का उत्तोलक (Kernighan's Lever)’ के रूप में नए सिरे से पढ़ा। उनकी व्याख्या है कि अपनी क्षमता से कठिन कोड को सुधारने के लिए संघर्ष करने की प्रक्रिया में हमारी क्षमता बढ़ती है। हालाँकि, यह बात सीखने की स्थिति पर लागू होती है; जिस कोड का कई लोग लंबे समय तक उपयोग करते हैं, उसमें मूल सलाह अपनाना अधिक सुरक्षित है।
व्यावहारिक काम में कर्निहैन के नियम को कैसे अपनाएँ
कर्निहैन का नियम कोड को पढ़ने में आसान बनाने वाली कई आदतों का आधार बनता है।
(1) पहले पढ़ने वाले के बारे में सोचें
कोड एक बार लिखा जाता है और कई बार पढ़ा जाता है। नाम स्पष्ट रखें और एक पंक्ति में बहुत सारे काम न भरें, ताकि कुछ महीनों बाद आप स्वयं या पहली बार उसे देखने वाला सहकर्मी तुरंत समझ सके।
(2) पहले सही बनाएँ, फिर तेज बनाएँ
इसी पुस्तक में सलाह दी गई है कि ‘तेज बनाने से पहले उसे सही बनाएँ।’ प्रदर्शन बेहतर करने के लिए कोड में पेचीदा बदलाव करने से पहले यह पता लगा लेना पर्याप्त है कि वास्तव में कौन-सा हिस्सा धीमा है।
(3) छोटे कोड से अधिक आसानी से सुधारे जा सकने वाले कोड को चुनें
आजकल कृत्रिम बुद्धिमत्ता के उपकरण पल भर में जटिल कोड बना देते हैं, लेकिन उसे समझने और सुधारने की जिम्मेदारी अब भी मनुष्य की है। जिस कोड को आप समझा नहीं सकते, उसे ज्यों का त्यों स्वीकार न करना अधिक सुरक्षित है।
कर्निहैन ने 1979 के एक लेख में यह भी कहा था कि सबसे प्रभावी डीबगिंग उपकरण अब भी सावधानी से किया गया विचार और उचित स्थानों पर रखे गए आउटपुट कथन हैं। इसका अर्थ है कि समस्या सुलझाने का आधार चमकदार उपकरणों से अधिक ऐसा सरल कोड है जिस पर शांत मन से विचार किया जा सके।
कर्निहैन का नियम अपनी कुशलता छिपाने के लिए नहीं कहता, बल्कि यह सलाह देता है कि उसे कहाँ लगाना चाहिए। आज लिखी गई एक चतुर पंक्ति की तुलना में कल भी आसानी से पढ़ी जा सकने वाली दस साधारण पंक्तियाँ अंततः अधिक समय बचाती हैं।
कोड में उतनी ही चतुराई रखें कि आप अपनी समझ से उसे दोबारा सुलझा सकें। लंबे समय तक टिकने वाले कोड की ओर यही पहला कदम है।
