- नियम 1: यह अनुमान नहीं लगाया जा सकता कि प्रोग्राम अपना समय कहाँ खर्च करेगा। bottleneck अक्सर अप्रत्याशित जगहों पर आते हैं, इसलिए जब तक वास्तव में यह साबित न हो जाए कि वही bottleneck है, तब तक speed सुधारने की कोशिश न करें
- नियम 2: measurement पहले। speed tuning केवल measurement के बाद करें, और optimization पर तभी विचार करें जब code का कोई एक हिस्सा पूरे सिस्टम पर हावी हो
- नियम 3: जटिल algorithms छोटे n पर धीमे होते हैं। जटिल algorithms में बड़े constants होते हैं, इसलिए जब तक n अक्सर बड़ा न हो, सरल तरीका अपनाएँ। n बड़ा हो तब भी पहले नियम 2 लागू करें
- नियम 4: जटिल algorithms में bugs ज़्यादा होते हैं और उन्हें implement करना कठिन होता है। सरल algorithms और सरल data structures का उपयोग करना बेहतर है
- नियम 5: data ही मुख्य है। सही data structure चुनकर और उसे अच्छी तरह व्यवस्थित करके, algorithm लगभग अपने-आप स्पष्ट हो जाता है। प्रोग्रामिंग का केंद्र algorithms नहीं, बल्कि data structures हैं
संबंधित दर्शन और उद्धरण
- नियम 1 और 2, Tony Hoare के “premature optimization is the root of all evil” वाले कथन के समान अर्थ रखते हैं
- Ken Thompson ने नियम 3 और 4 को “संदेह हो तो सरल तरीका (Brute Force) अपनाओ” के रूप में पुनर्व्याख्यायित किया
- नियम 3 और 4, KISS (Keep It Simple, Stupid) design philosophy के उदाहरण हैं
- नियम 5 का उल्लेख Fred Brooks ने पहले ही 『The Mythical Man-Month』 में किया था,
और इसे अक्सर “smart objects का उपयोग करके simple code लिखो” के रूप में संक्षेपित किया जाता है
अभी कोई टिप्पणी नहीं है.