Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2431
EN + हिं Medium
GB What distinguishes 'black-box' from 'white-box' design in component-based software design?
IN घटक-आधारित सॉफ़्टवेयर डिज़ाइन में 'ब्लैक-बॉक्स' को 'व्हाइट-बॉक्स' डिज़ाइन से क्या अलग करता है?
A
Black-box uses dark IDE themes; white-box uses light themes ब्लैक-बॉक्स डार्क आईडीई थीम का उपयोग करता है; व्हाइट-बॉक्स हल्के विषयों का उपयोग करता है
B
Black-box specifies behaviour through interface only, hiding implementation; white-box exposes internal structure requiring users to understand internals to use it correctly ब्लैक-बॉक्स केवल इंटरफ़ेस के माध्यम से व्यवहार को निर्दिष्ट करता है, कार्यान्वयन को छुपाता है; व्हाइट-बॉक्स आंतरिक संरचना को उजागर करता है जिससे उपयोगकर्ताओं को इसे सही ढंग से उपयोग करने के लिए आंतरिक को समझने की आवश्यकता होती है
C
Black-box is for security systems; white-box for non-security ब्लैक-बॉक्स सुरक्षा प्रणालियों के लिए है; गैर-सुरक्षा के लिए व्हाइट-बॉक्स
D
Black-box components cannot be tested; white-box can be fully automated tested ब्लैक-बॉक्स घटकों का परीक्षण नहीं किया जा सकता; व्हाइट-बॉक्स का पूरी तरह से स्वचालित परीक्षण किया जा सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Black-box reuse treats a component as an opaque unit defined only by its interface contract (what it does, not how). White-box reuse requires examining and often modifying source code — creating tight coupling to implementation details that break when the component is updated.
व्याख्या (हिन्दी) ब्लैक-बॉक्स पुन: उपयोग एक घटक को एक अपारदर्शी इकाई के रूप में मानता है जो केवल उसके इंटरफ़ेस अनुबंध द्वारा परिभाषित होता है (यह क्या करता है, कैसे नहीं)। व्हाइट-बॉक्स के पुन: उपयोग के लिए स्रोत कोड की जांच और अक्सर संशोधन की आवश्यकता होती है - कार्यान्वयन विवरणों के लिए सख्त युग्मन बनाना जो घटक अद्यतन होने पर टूट जाता है।
2432
EN + हिं Medium
GB What does 'Design by Contract' (DbC) entail and how does it differ from defensive programming?
IN 'डिज़ाइन बाय कॉन्ट्रैक्ट' (DbC) में क्या शामिल है और यह रक्षात्मक प्रोग्रामिंग से कैसे भिन्न है?
A
DbC is a legal framework for software licensing डीबीसी सॉफ्टवेयर लाइसेंसिंग के लिए एक कानूनी ढांचा है
B
DbC specifies formal preconditions, postconditions, and invariants — callers meet preconditions; method guarantees postconditions. Defensive programming checks all inputs regardless of responsibility, adding redundancy डीबीसी औपचारिक पूर्वशर्तें, पश्चशर्तें और अपरिवर्तनीयताएं निर्दिष्ट करता है - कॉल करने वाले पूर्वशर्तों को पूरा करते हैं; विधि पोस्टकंडिशन की गारंटी देती है। रक्षात्मक प्रोग्रामिंग जिम्मेदारी की परवाह किए बिना, अतिरेक जोड़ते हुए सभी इनपुट की जाँच करती है
C
DbC contracts are written by lawyers; defensive programming by developers डीबीसी अनुबंध वकीलों द्वारा लिखे जाते हैं; डेवलपर्स द्वारा रक्षात्मक प्रोग्रामिंग
D
Both are equivalent approaches with different terminology दोनों अलग-अलग शब्दावली के साथ समान दृष्टिकोण हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Bertrand Meyer's DbC creates a formal agreement: preconditions (caller's responsibility), postconditions (method's guarantee), invariants (always-true properties). DbC places blame clearly. Defensive programming checks everything everywhere — safer across trust boundaries but adds overhead and ambiguity.
व्याख्या (हिन्दी) बर्ट्रेंड मेयर का डीबीसी एक औपचारिक समझौता बनाता है: पूर्व शर्त (कॉलर की जिम्मेदारी), पोस्टकंडिशन (विधि की गारंटी), अपरिवर्तनीय (हमेशा-सही गुण)। डीबीसी स्पष्ट रूप से दोषारोपण करता है। रक्षात्मक प्रोग्रामिंग हर जगह हर चीज़ की जाँच करती है - विश्वास की सीमाओं के पार सुरक्षित लेकिन ओवरहेड और अस्पष्टता जोड़ती है।
2433
EN + हिं Easy
GB What is the 'God Object' anti-pattern and what refactoring approach addresses it?
IN 'गॉड ऑब्जेक्ट' विरोधी पैटर्न क्या है और कौन सा रिफैक्टरिंग दृष्टिकोण इसे संबोधित करता है?
A
A highly reusable class handling all common utilities; should be kept and extended सभी सामान्य उपयोगिताओं को संभालने वाला एक अत्यधिक पुन: प्रयोज्य वर्ग; रखा जाना चाहिए और बढ़ाया जाना चाहिए
B
A class that knows too much or does too much — violating SRP and creating a hub of dependencies; addressed by extracting classes and redistributing responsibilities according to cohesion एक वर्ग जो बहुत अधिक जानता है या बहुत अधिक करता है - एसआरपी का उल्लंघन करता है और निर्भरता का केंद्र बनाता है; सामंजस्य के अनुसार वर्गों को निकालकर और जिम्मेदारियों को पुनर्वितरित करके संबोधित किया गया
C
The main entry point class of any application किसी भी एप्लिकेशन का मुख्य प्रवेश बिंदु वर्ग
D
Only a problem in procedural programming, not OOP केवल प्रक्रियात्मक प्रोग्रामिंग में एक समस्या है, OOP नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) God Objects accumulate as developers add functionality to an existing central class. Eventually it becomes monolithic and coupled to everything. Refactoring uses Extract Class to pull cohesive groups of responsibilities into dedicated classes.
व्याख्या (हिन्दी) जैसे ही डेवलपर्स मौजूदा केंद्रीय वर्ग में कार्यक्षमता जोड़ते हैं, गॉड ऑब्जेक्ट जमा हो जाते हैं। अंततः यह अखंड हो जाता है और हर चीज़ से जुड़ जाता है। रिफैक्टरिंग जिम्मेदारियों के एकजुट समूहों को समर्पित कक्षाओं में खींचने के लिए एक्सट्रैक्ट क्लास का उपयोग करता है।
2434
EN + हिं Medium
GB What is the fundamental difference between 'composition' and 'inheritance' as reuse mechanisms in OOP?
IN OOP में पुन: उपयोग तंत्र के रूप में 'संरचना' और 'विरासत' के बीच मूलभूत अंतर क्या है?
A
Composition only with interfaces; inheritance requires abstract classes केवल इंटरफेस के साथ रचना; विरासत के लिए अमूर्त वर्गों की आवश्यकता होती है
B
Inheritance is static compile-time reuse creating 'is-a' relationships exposing parent internals; composition is dynamic runtime 'has-a' relationship that is more flexible, testable, and avoids the fragile base class problem वंशानुक्रम स्थैतिक संकलन-समय का पुन: उपयोग है जो मूल आंतरिक को उजागर करने वाले 'ए-ए' संबंध बनाता है; रचना गतिशील रनटाइम 'है-ए' संबंध है जो अधिक लचीला, परीक्षण योग्य है, और नाजुक बेस क्लास समस्या से बचाती है
C
Composition always produces faster code than inheritance कंपोज़िशन हमेशा इनहेरिटेंस की तुलना में तेज़ कोड उत्पन्न करता है
D
Both are equivalent; choice depends only on preference दोनों समतुल्य हैं; चुनाव केवल प्राथमिकता पर निर्भर करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The 'fragile base class problem' shows inheritance's weakness: changing a parent class can break subclasses unexpectedly. GoF's 'favour composition over inheritance' recommends building objects from collaborating components, enabling runtime behaviour changes through dependency injection.
व्याख्या (हिन्दी) 'नाजुक आधार वर्ग समस्या' वंशानुक्रम की कमजोरी को दर्शाती है: मूल वर्ग को बदलने से उपवर्ग अप्रत्याशित रूप से टूट सकते हैं। GoF की 'विरासत पर अनुकूल संरचना' निर्भरता इंजेक्शन के माध्यम से रनटाइम व्यवहार परिवर्तन को सक्षम करने, सहयोगी घटकों से वस्तुओं के निर्माण की सिफारिश करती है।
2435
EN + हिं Medium
GB What problem does the 'Observer' pattern solve and when does it introduce risk?
IN 'ऑब्जर्वर' पैटर्न किस समस्या का समाधान करता है और यह कब जोखिम उत्पन्न करता है?
A
Solves performance bottlenecks; introduces risk in single-user applications प्रदर्शन संबंधी बाधाओं को हल करता है; एकल-उपयोगकर्ता अनुप्रयोगों में जोखिम लाता है
B
Solves notifying multiple dependent objects when a subject changes without tight coupling; introduces risk of memory leaks (observers not unsubscribed), unexpected update cascades, and non-deterministic notification order जब कोई विषय बिना टाइट कपलिंग के बदलता है तो कई आश्रित वस्तुओं को सूचित करने का समाधान करता है; मेमोरी लीक (पर्यवेक्षकों ने सदस्यता समाप्त नहीं की है), अप्रत्याशित अपडेट कैस्केड और गैर-नियतात्मक अधिसूचना आदेश का जोखिम पेश किया है
C
Solves creating objects without specifying their exact classes वस्तुओं को उनकी सटीक कक्षाओं को निर्दिष्ट किए बिना बनाकर हल करता है
D
Introduces risk only in multithreaded environments; safe for single-threaded use केवल बहु-थ्रेडेड वातावरण में जोखिम का परिचय देता है; एकल-थ्रेडेड उपयोग के लिए सुरक्षित
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Observer (GoF) decouples subjects from observers using publish-subscribe. Risks: memory leaks when observers are not removed; update avalanches where one notification triggers uncontrollable chains; unexpected re-entry when an observer modifies the subject during notification.
व्याख्या (हिन्दी) ऑब्जर्वर (जीओएफ) पब्लिश-सब्सक्राइब का उपयोग करके विषयों को पर्यवेक्षकों से अलग करता है। जोखिम: जब पर्यवेक्षकों को नहीं हटाया जाता है तो मेमोरी लीक हो जाती है; अद्यतन हिमस्खलन जहां एक अधिसूचना अनियंत्रित श्रृंखलाओं को ट्रिगर करती है; जब कोई पर्यवेक्षक अधिसूचना के दौरान विषय को संशोधित करता है तो अप्रत्याशित पुनः प्रवेश।
2436
EN + हिं Medium
GB What is 'separation of concerns' and how is it architecturally implemented in MVC?
IN 'चिंताओं का पृथक्करण' क्या है और इसे एमवीसी में वास्तुशिल्प रूप से कैसे लागू किया जाता है?
A
Different developers work on different parts simultaneously अलग-अलग डेवलपर अलग-अलग हिस्सों पर एक साथ काम करते हैं
B
Organising code so each module addresses a distinct aspect; MVC implements this by separating data/business logic (Model), presentation (View), and user interaction handling (Controller) कोड को व्यवस्थित करना ताकि प्रत्येक मॉड्यूल एक विशिष्ट पहलू को संबोधित करे; एमवीसी डेटा/बिजनेस लॉजिक (मॉडल), प्रेजेंटेशन (व्यू), और यूजर इंटरेक्शन हैंडलिंग (कंट्रोलर) को अलग करके इसे लागू करता है।
C
Separation of concerns only applies to database design चिंताओं का पृथक्करण केवल डेटाबेस डिज़ाइन पर लागू होता है
D
MVC implements separation by storing all state in Controller एमवीसी नियंत्रक में सभी स्थितियों को संग्रहीत करके पृथक्करण लागू करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Dijkstra's separation of concerns reduces complexity by preventing one concern from bleeding into another. MVC applies it to UI: the Model knows nothing about presentation; the View knows nothing about business rules; the Controller knows nothing about storage.
व्याख्या (हिन्दी) दिज्क्स्ट्रा की चिंताओं को अलग करने से एक चिंता को दूसरे में फैलने से रोककर जटिलता कम हो जाती है। एमवीसी इसे यूआई पर लागू करता है: मॉडल प्रस्तुति के बारे में कुछ नहीं जानता है; व्यू व्यावसायिक नियमों के बारे में कुछ नहीं जानता; नियंत्रक को भंडारण के बारे में कुछ नहीं पता है।
2437
EN + हिं Medium
GB What is the primary purpose of coding standards in a multi-developer project and what happens when inconsistently applied?
IN मल्टी-डेवलपर प्रोजेक्ट में कोडिंग मानकों का प्राथमिक उद्देश्य क्या है और असंगत रूप से लागू होने पर क्या होता है?
A
Reduce compilation time by optimising code structure कोड संरचना को अनुकूलित करके संकलन समय कम करें
B
Ensure code is readable and maintainable by any team member; inconsistent application creates cognitive overhead, introduces subtle bugs in misunderstood conventions, and makes code review ineffective सुनिश्चित करें कि कोड किसी भी टीम सदस्य द्वारा पढ़ने योग्य और रखरखाव योग्य है; असंगत अनुप्रयोग संज्ञानात्मक ओवरहेड बनाता है, गलत समझे गए सम्मेलनों में सूक्ष्म बग पेश करता है, और कोड समीक्षा को अप्रभावी बनाता है
C
Only needed for open-source projects where external contributors work on the code केवल ओपन-सोर्स परियोजनाओं के लिए आवश्यक है जहां बाहरी योगदानकर्ता कोड पर काम करते हैं
D
Automatically enforce themselves through modern IDEs आधुनिक आईडीई के माध्यम से स्वयं को स्वचालित रूप से लागू करें
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Coding standards create a shared vocabulary for the codebase. When inconsistently applied, developers must context-switch between styles. More dangerously, inconsistent conventions can obscure bugs that consistent formatting would make obvious.
व्याख्या (हिन्दी) कोडिंग मानक कोडबेस के लिए एक साझा शब्दावली बनाते हैं। असंगत रूप से लागू होने पर, डेवलपर्स को शैलियों के बीच संदर्भ-स्विच करना होगा। अधिक खतरनाक रूप से, असंगत परंपराएँ उन बगों को अस्पष्ट कर सकती हैं जिन्हें लगातार स्वरूपण स्पष्ट कर देगा।
2438
EN + हिं Medium
GB What is the 'magic number' anti-pattern in coding and how does it violate maintainability principles?
IN कोडिंग में 'मैजिक नंबर' एंटी-पैटर्न क्या है और यह कैसे रखरखाव सिद्धांतों का उल्लंघन करता है?
A
Randomly generated cryptographic keys embedded in code कोड में एम्बेडेड बेतरतीब ढंग से उत्पन्न क्रिप्टोग्राफ़िक कुंजियाँ
B
Unexplained numeric literals without context in code (e.g., 'if status == 4'); they make code intent opaque and require future maintainers to guess what the value represents कोड में संदर्भ के बिना अस्पष्ट संख्यात्मक अक्षर (उदाहरण के लिए, 'यदि स्थिति == 4'); वे कोड के इरादे को अपारदर्शी बनाते हैं और भावी अनुरक्षकों को यह अनुमान लगाने की आवश्यकता होती है कि मूल्य क्या दर्शाता है
C
Performance-critical constants that must remain unexplained to prevent reverse engineering प्रदर्शन-महत्वपूर्ण स्थिरांक जिन्हें रिवर्स इंजीनियरिंग को रोकने के लिए अस्पष्टीकृत रहना चाहिए
D
Only refers to values 0 and 1 in boolean contexts केवल बूलियन संदर्भों में मान 0 और 1 को संदर्भित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A magic number like 'if (retries == 3)' conveys no meaning. Naming it 'MAX_RETRY_ATTEMPTS = 3' documents intent, enables searching, and makes updates trivial. This is a fundamental readability and DRY violation.
व्याख्या (हिन्दी) 'if (पुनः प्रयास == 3)' जैसी जादुई संख्या का कोई मतलब नहीं है। इसे 'MAX_RETRY_ATTEMPTS = 3' नाम देने से दस्तावेज़ का उद्देश्य खोज करना संभव हो जाता है, और अपडेट को तुच्छ बना देता है। यह एक मौलिक पठनीयता और DRY उल्लंघन है।
2439
EN + हिं Easy
GB What does the DRY principle prohibit and what is its violation called?
IN DRY सिद्धांत किस पर रोक लगाता है और इसका उल्लंघन क्या कहलाता है?
A
Writing comments in code; violations called 'over-commenting' कोड में टिप्पणियाँ लिखना; उल्लंघन जिसे 'अति-टिप्पणी' कहा जाता है
B
Having multiple representations of the same knowledge in the system; violations called 'WET' leading to inconsistent updates when one copy changes but others don't सिस्टम में एक ही ज्ञान के कई प्रतिनिधित्व होना; 'WET' नामक उल्लंघनों के कारण जब एक प्रति बदलती है लेकिन अन्य नहीं बदलती तो असंगत अद्यतन होते हैं
C
Using the same variable name in different scopes विभिन्न क्षेत्रों में एक ही चर नाम का उपयोग करना
D
Only about avoiding copy-pasted code blocks, not data duplication केवल कॉपी-पेस्ट किए गए कोड ब्लॉक से बचने के बारे में, डेटा डुप्लिकेशन के बारे में नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hunt and Thomas defined DRY as: 'Every piece of knowledge must have a single, unambiguous, authoritative representation.' WET code creates synchronisation problems — if business rule X is encoded in three places and one changes, the system becomes inconsistent.
व्याख्या (हिन्दी) हंट और थॉमस ने DRY को इस प्रकार परिभाषित किया: 'ज्ञान के प्रत्येक टुकड़े में एक एकल, स्पष्ट, आधिकारिक प्रतिनिधित्व होना चाहिए।' WET कोड सिंक्रनाइज़ेशन समस्याएँ पैदा करता है - यदि व्यवसाय नियम X को तीन स्थानों पर एन्कोड किया गया है और एक में परिवर्तन होता है, तो सिस्टम असंगत हो जाता है।
2440
EN + हिं Medium
GB What is the 'Boy Scout Rule' in software development and how does it relate to managing technical debt?
IN सॉफ्टवेयर विकास में 'बॉय स्काउट नियम' क्या है और यह तकनीकी ऋण प्रबंधन से कैसे संबंधित है?
A
Requires all developers to attend outdoor team-building activities monthly सभी डेवलपर्स को मासिक रूप से आउटडोर टीम-निर्माण गतिविधियों में भाग लेने की आवश्यकता है
B
'Leave the campground cleaner than you found it' applied to code: whenever you touch a module leave it slightly cleaner — incrementally paying down technical debt without dedicated refactoring sprints कोड पर लागू 'कैंपग्राउंड को जितना आपने पाया था उससे अधिक साफ-सुथरा छोड़ें': जब भी आप किसी मॉड्यूल को छूते हैं तो इसे थोड़ा साफ छोड़ दें - समर्पित रीफैक्टरिंग स्प्रिंट के बिना तकनीकी ऋण का क्रमिक रूप से भुगतान करना
C
Junior developers clean up code written by senior developers जूनियर डेवलपर्स वरिष्ठ डेवलपर्स द्वारा लिखे गए कोड को साफ़ करते हैं
D
A security practice requiring code review before deployment एक सुरक्षा अभ्यास जिसमें तैनाती से पहले कोड समीक्षा की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Robert Martin's Boy Scout Rule addresses the reality that dedicated refactoring sprints are often deprioritised. By making incremental improvement routine — rename a confusing variable, extract a long method — teams prevent codebase degradation without special effort allocation.
व्याख्या (हिन्दी) रॉबर्ट मार्टिन का बॉय स्काउट नियम इस वास्तविकता को संबोधित करता है कि समर्पित रिफैक्टरिंग स्प्रिंट को अक्सर प्राथमिकता नहीं दी जाती है। वृद्धिशील सुधार की दिनचर्या बनाकर - एक भ्रमित करने वाले चर का नाम बदलें, एक लंबी विधि निकालें - टीमें विशेष प्रयास आवंटन के बिना कोडबेस गिरावट को रोकती हैं।
2441
EN + हिं Easy
GB What is 'defensive coding' and in what scenario is it specifically inappropriate?
IN 'रक्षात्मक कोडिंग' क्या है और किस परिदृश्य में यह विशेष रूप से अनुपयुक्त है?
A
Writing code that anticipates errors; inappropriate in cryptographic implementations where branches create timing side-channels त्रुटियों का पूर्वानुमान करने वाला कोड लिखना; क्रिप्टोग्राफ़िक कार्यान्वयन में अनुपयुक्त जहां शाखाएं टाइमिंग साइड-चैनल बनाती हैं
B
It is unnecessary when using statically typed languages स्थिर रूप से टाइप की गई भाषाओं का उपयोग करते समय यह अनावश्यक है
C
Inappropriate in any performance-critical system due to overhead ओवरहेड के कारण किसी भी प्रदर्शन-महत्वपूर्ण प्रणाली में अनुपयुक्त
D
Should be avoided in test code to keep tests simple परीक्षणों को सरल बनाए रखने के लिए परीक्षण कोड से बचना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Defensive coding proactively validates inputs and handles error conditions. In cryptographic code, defensive branches can create timing variations measurable by attackers — timing side-channel attacks exploit different execution times depending on secret values. Constant-time algorithms deliberately avoid conditional branches.
व्याख्या (हिन्दी) रक्षात्मक कोडिंग सक्रिय रूप से इनपुट को मान्य करती है और त्रुटि स्थितियों को संभालती है। क्रिप्टोग्राफ़िक कोड में, रक्षात्मक शाखाएं हमलावरों द्वारा मापने योग्य समय भिन्नताएं बना सकती हैं - टाइमिंग साइड-चैनल हमले गुप्त मूल्यों के आधार पर विभिन्न निष्पादन समय का फायदा उठाते हैं। लगातार-समय एल्गोरिदम जानबूझकर सशर्त शाखाओं से बचते हैं।
2442
EN + हिं Medium
GB What is the key difference between a 'code smell' and a 'bug' and why do code smells matter?
IN 'कोड गंध' और 'बग' के बीच मुख्य अंतर क्या है और कोड गंध क्यों मायने रखती है?
A
Code smells are compiler warnings; bugs are runtime errors कोड गंध संकलक चेतावनियाँ हैं; बग रनटाइम त्रुटियाँ हैं
B
A bug is a functional defect causing incorrect behaviour; a code smell is a structural indicator of potential design problems that may not currently fail but increase likelihood of future bugs and raise maintenance costs बग एक कार्यात्मक दोष है जो गलत व्यवहार का कारण बनता है; कोड गंध संभावित डिज़ाइन समस्याओं का एक संरचनात्मक संकेतक है जो वर्तमान में विफल नहीं हो सकती है लेकिन भविष्य में बग की संभावना बढ़ जाती है और रखरखाव लागत बढ़ जाती है
C
Code smells only relevant in Python and JavaScript due to dynamic typing गतिशील टाइपिंग के कारण कोड केवल पायथन और जावास्क्रिप्ट में ही प्रासंगिक लगता है
D
Code smells and bugs are synonymous in code review कोड समीक्षा में कोड गंध और बग पर्यायवाची हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Fowler's code smells (long methods, large classes, duplicate code) are structural warning signs suggesting refactoring is needed. They don't cause immediate failures but signal design decay making future modification error-prone.
व्याख्या (हिन्दी) फाउलर के कोड की गंध (लंबी विधियां, बड़ी कक्षाएं, डुप्लिकेट कोड) संरचनात्मक चेतावनी संकेत हैं जो सुझाव देते हैं कि रीफैक्टरिंग की आवश्यकता है। वे तत्काल विफलताओं का कारण नहीं बनते हैं लेकिन सिग्नल डिज़ाइन ख़राब हो जाते हैं जिससे भविष्य में संशोधन में त्रुटि-प्रवण हो जाता है।
2443
EN + हिं Easy
GB What is the correct interpretation of 'responsibility' in the Single Responsibility Principle (SRP)?
IN एकल उत्तरदायित्व सिद्धांत (एसआरपी) में 'जिम्मेदारी' की सही व्याख्या क्या है?
A
A class should have only one method एक कक्षा में केवल एक ही विधि होनी चाहिए
B
A class should have only one reason to change — where 'reason to change' corresponds to a stakeholder group or business concern, not merely a functional category एक वर्ग के पास परिवर्तन का केवल एक ही कारण होना चाहिए - जहां 'परिवर्तन का कारण' एक हितधारक समूह या व्यावसायिक चिंता से मेल खाता है, न कि केवल एक कार्यात्मक श्रेणी से।
C
Each developer is responsible for maintaining exactly one class प्रत्येक डेवलपर ठीक एक वर्ग को बनाए रखने के लिए जिम्मेदार है
D
Only applicable to functional programming, not OOP केवल कार्यात्मक प्रोग्रामिंग पर लागू, OOP पर नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Robert Martin clarified that 'responsibility' means 'a reason to change' corresponding to a specific stakeholder or user group. A class generating a report AND emailing it has two reasons to change — finance team wanting different content, and IT changing email infrastructure. These are separate responsibilities.
व्याख्या (हिन्दी) रॉबर्ट मार्टिन ने स्पष्ट किया कि 'जिम्मेदारी' का अर्थ किसी विशिष्ट हितधारक या उपयोगकर्ता समूह के अनुरूप 'परिवर्तन का एक कारण' है। एक वर्ग जो रिपोर्ट तैयार करता है और उसे ईमेल करता है, उसमें बदलाव के दो कारण होते हैं - वित्त टीम अलग सामग्री चाहती है, और आईटी ईमेल बुनियादी ढांचे को बदल रही है। ये अलग जिम्मेदारियां हैं.
2444
EN + हिं Medium
GB Why is 'premature optimisation' considered a coding standard violation and when is optimisation legitimate?
IN 'समयपूर्व अनुकूलन' को कोडिंग मानक का उल्लंघन क्यों माना जाता है और अनुकूलन कब वैध है?
A
Premature optimisation is when code is optimised before compilation समयपूर्व अनुकूलन तब होता है जब कोड को संकलन से पहले अनुकूलित किया जाता है
B
Premature optimisation prioritises performance over correctness and maintainability without profiling data — Knuth's rule applies; optimisation is legitimate after profiling identifies actual hotspots समयपूर्व अनुकूलन प्रोफाइलिंग डेटा के बिना शुद्धता और रखरखाव पर प्रदर्शन को प्राथमिकता देता है - नथ का नियम लागू होता है; प्रोफाइलिंग से वास्तविक हॉटस्पॉट की पहचान होने के बाद अनुकूलन वैध है
C
All performance optimisation is premature सभी प्रदर्शन अनुकूलन समयपूर्व हैं
D
Premature optimisation only applies to sorting algorithms समयपूर्व अनुकूलन केवल सॉर्टिंग एल्गोरिदम पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Knuth's full quote: 'Premature optimisation is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.' Profiling data identifies which 3% matters. Optimising guessed bottlenecks makes code complex and unmaintainable for no measurable gain.
व्याख्या (हिन्दी) नथ का पूरा उद्धरण: 'समयपूर्व अनुकूलन सभी बुराइयों की जड़ है। फिर भी हमें उस महत्वपूर्ण 3% में अपने अवसर नहीं गंवाने चाहिए।' प्रोफ़ाइलिंग डेटा पहचानता है कि कौन सा 3% मायने रखता है। अनुमानित बाधाओं को अनुकूलित करने से कोड जटिल हो जाता है और बिना किसी मापनीय लाभ के रखरखाव योग्य नहीं रह जाता है।
2445
EN + हिं Medium
GB What specific problem does the 'assert' statement solve and why should it NOT be used for input validation?
IN 'जोर' कथन किस विशिष्ट समस्या का समाधान करता है और इसका उपयोग इनपुट सत्यापन के लिए क्यों नहीं किया जाना चाहिए?
A
Used to improve performance by eliminating runtime type checks रनटाइम प्रकार की जांच को समाप्त करके प्रदर्शन में सुधार करने के लिए उपयोग किया जाता है
B
Asserts document and enforce invariants about program's internal state; should not validate external inputs because assertions are typically disabled in production builds allowing invalid inputs to pass unchecked प्रोग्राम की आंतरिक स्थिति के बारे में दस्तावेज़ पर जोर देता है और अपरिवर्तनीयताओं को लागू करता है; बाहरी इनपुट को मान्य नहीं करना चाहिए क्योंकि उत्पादन बिल्ड में दावे आम तौर पर अक्षम होते हैं जिससे अमान्य इनपुट अनियंत्रित हो जाते हैं
C
Assert statements equivalent to unit tests and can replace them यूनिट परीक्षणों के समतुल्य कथनों पर जोर दें और उन्हें प्रतिस्थापित कर सकते हैं
D
Asserts should only be used in languages without exception handling दावे का उपयोग केवल अपवाद प्रबंधन के बिना भाषाओं में किया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Assertions check internal assumptions that should never be false if code is correct. For user-supplied data, use explicit validation with informative exceptions because: assertions may be compiled out, they produce poor user-facing messages, and they conflate internal logic errors with external input errors.
व्याख्या (हिन्दी) दावे आंतरिक धारणाओं की जाँच करते हैं जो कोड सही होने पर कभी भी गलत नहीं होने चाहिए। उपयोगकर्ता द्वारा प्रदत्त डेटा के लिए, सूचनात्मक अपवादों के साथ स्पष्ट सत्यापन का उपयोग करें क्योंकि: दावे संकलित किए जा सकते हैं, वे खराब उपयोगकर्ता-सामना वाले संदेश उत्पन्न करते हैं, और वे बाहरी इनपुट त्रुटियों के साथ आंतरिक तर्क त्रुटियों को मिलाते हैं।
2431–2445 of 2726