Dennis Ritchie on the priorities of && || vs. == आदि (1982)

मूल लेख ↗ Hacker News चर्चा ↗

C और संबंधित भाषाओं में boolean और bitwise operators—विशेषकर `&&`, `||`, `&`, `|`, और `==`—की operator precedence को लंबे समय से subtle bugs और confusion का स्रोत माना जाता है। टिप्पणीकार Dennis Ritchie द्वारा दिए गए ऐतिहासिक कारणों की जाँच करते हैं, जैसे `&` को `==` से कम precedence देना, और इसे Boolean algebra, set theory, और probability से आने वाली mathematical intuitions से तुलना करते हैं। कई लोग explicit parentheses या ऐसी language designs के पक्ष में हैं जो ambiguous expressions को सीमित करें, यह नोट करते हुए कि नई भाषाएँ और linters memorized precedence rules पर निर्भर रहने के बजाय clarity को अधिक प्राथमिकता देते हैं।

मुख्य भ्रम: तार्किक ऑपरेटरों की precedence

  • कई लोग स्वीकार करते हैं कि वे && बनाम || (और अक्सर SQL के AND/OR) को भरोसेमंद तरीके से याद नहीं रखते, और मिश्रित expressions को हमेशा parentheses में घेरना चुनते हैं।
  • अन्य लोगों का तर्क है कि developers को बस rules सीख लेने चाहिए, और &&/|| की precedence की तुलना */+ से करते हैं।
  • कई लोग नोट करते हैं कि जो लोग नियम जानते भी हैं, वे भाषाएँ बदलते समय फिर भी फँस जाते हैं जहाँ precedence अलग होती है (जैसे shells)।

अंकगणित, Boolean algebra, और mnemonics

  • कई टिप्पणियाँ && को 0/1 values के लिए multiplication और || को addition से जोड़ती हैं: product = AND, (saturated) sum = OR।
  • अन्य लोग set theory को पसंद करते हैं: && को intersection और || को union के रूप में, जहाँ distributive laws Boolean algebra की तरह होती हैं।
  • कुछ लोग बताते हैं कि XOR mod‑2 arithmetic में addition के साथ अधिक साफ़ तरीके से मेल खाता है, लेकिन यह analogy फिर भी relative precedence याद रखने में मदद करती है।

Parentheses as style and safety

  • स्पष्ट parentheses के पक्ष में मजबूत camp है, किसी भी nontrivial Boolean expression के लिए, भले ही precedence ज्ञात हो।
  • तर्क:
    • भविष्य के readers और code reviewers के लिए आसान।
    • expressions के edit या copy होने पर subtle bugs से बचाता है।
    • a && b || c जैसी expressions पर चेतावनी देने वाले linters को real-world bugs के बाद स्वागत किया जाता है।
  • प्रतितर्क:
    • अतिरिक्त parentheses noise और cognitive overhead बढ़ाते हैं; उन्हें overrides दिखाने चाहिए, defaults दोहराने नहीं।
    • अनावश्यक == true / == false और ज़रूरत से ज़्यादा parenthesizing को कमजोर समझ का संकेत माना जाता है।

C की bitwise बनाम comparison precedence (“the real” Ritchie topic)

  • स्पष्ट किया जाता है कि मूल article मुख्यतः इस बारे में है कि bitwise &/| की precedence == और अन्य operators से कम क्यों है, न कि && बनाम || के बारे में।
  • ऐतिहासिक रूप से, && मौजूद होने से पहले & का उपयोग logical AND के लिए होता था, इसलिए a==b & c==d को logically behave करना था; बाद में यही चयन addr & mask == 0 जैसी expressions को intuitively गलत तरह से addr & (mask == 0) के रूप में parse कर देता है।
  • टिप्पणीकार सहमत हैं कि इसे व्यापक रूप से design mistake माना जाता है, लेकिन backward compatibility के लिए इसे बनाए रखा गया।

Language design alternatives

  • कुछ languages अलग-अलग infix operators को मिलाने पर parentheses की मांग करती हैं (logical ops के लिए Ada; Pony, आंशिक रूप से Zig, WGSL, Carbon-style approaches)।
  • अन्य लोग precedence से बचते हैं या उसे कम करते हैं (Smalltalk left‑to‑right; Lisp/Scheme prefix notation के माध्यम से)।
  • सख्ती से typed या newer languages precedence को समायोजित करती हैं (Go/Rust/Swift, Python) या bitwise/logical operators को नियंत्रित तरीक़े से merge करती हैं (जैसे Sail), अक्सर booleans पर short-circuiting के साथ।