सबसे पठनीय तरीका अगर शर्तों को लंबे समय तक प्रारूपित करें? [बन्द है]

43

ifयदि संभव हो तो लंबी घुमावदार परिस्थितियों से बचा जाना चाहिए, फिर भी कभी-कभी हम सभी उन्हें लिखना समाप्त कर देते हैं। यहां तक कि अगर यह एक बहुत ही सरल स्थिति है, तो इसमें शामिल बयान कभी-कभी बहुत चिंताजनक होते हैं, इसलिए पूरी स्थिति बहुत लंबी हो जाती है। उन्हें प्रारूपित करने का सबसे पठनीय तरीका क्या है?

if (FoobarBaz::quxQuux(corge, grault) || !garply(waldo) || fred(plugh) !== xyzzy) {
    thud();
}

या

if (
    FoobarBaz::quxQuux(corge, grault)
 || !garply(waldo)
 || fred(plugh) !== xyzzy
) {
    thud();
}

या

if (FoobarBaz::quxQuux(corge, grault)
    || !garply(waldo)
    || fred(plugh) !== xyzzy) {
    thud();
}

या

thudable = FoobarBaz::quxQuux(corge, grault);
thudable ||= !garply(waldo);
thudable ||= fred(plugh) !== xyzzy;

if (thudable) {
    thud();
}

या कोई अन्य प्राथमिकताएं?

coding-style conditions

— deceze
स्रोत

30

अक्सर, एक लंबे समय तक अगर हालत कोड का संकेत होता है जिसे रिफैक्टिंग की आवश्यकता होती है, लेकिन कभी-कभी आप इसे टाल नहीं सकते हैं। उन मामलों में, मैं पहली पसंद करते हैं:

if (bar || baz || quux) { ... }

क्योंकि आप बता सकते हैं कि एक लाइन के साथ क्या हो रहा है। हालाँकि, मैं बहुत कुछ ऐसा कर सकता हूँ, जब संभव हो:

function foo() {
  return bar || baz || quux;
}

if (foo()) { ... }

— डोरियन
स्रोत

3

साइड वर्टिकल तक स्क्रॉल करना लगभग सीमित नहीं है क्योंकि यह बुरे पुराने दिनों में था ...

— बिल

2

और फ़ंक्शन को एक अर्थपूर्ण (व्यावसायिक) नाम दें ताकि लोग समझें कि यहां क्या परीक्षण किया गया है।

— मथिउ एम।

19

मैं निरंतरता को इंगित करने के लिए ऑपरेटरों को अंत में रखना पसंद करता हूं:

if (the_function_being_called() != RETURNCODE_SUCCESS &&
    the_possibly_useful_recovery_strategy() == RETURNCODE_EPICFAIL &&
    this_user_has_elected_to_recieve_error_reports)
{
    report_error();
}

— AShelly
स्रोत

1

मुझे लगता है कि मुझे यह पसंद है। मैं यह सुनिश्चित करने के लिए बहुत अधिक कोष्ठक नियोजित करता हूं कि मैं पूर्वता के क्रम को भी समझ सकता हूं।

— जसारेन

5

मैं तार्किक ऑपरेटरों को लाइन के प्रारंभ पर रखना पसंद करता हूं, क्योंकि मैं एक पंक्ति पढ़ता हूं मैं आसानी से देख सकता हूं कि यह सशर्त का हिस्सा है न कि केवल एक नियमित लाइन ऑफ कोड।

11

मैं सार्थक चर नामों का बहुत बड़ा प्रशंसक हूं:

const bool isInAStrangeCondition =
    FoobarBaz::quxQuux(corge, grault) ||
    !garply(waldo) ||
    fred(plugh) !== xyzzy;

if (isInAStrangeCondition) {
    thud();
}

या एक फ़ंक्शन के रूप में रिफ्लेक्टर, जैसा कि ऊपर उल्लेख किया गया है।

— LennyProgrammers
स्रोत

7

मैं गन्ने के उप-खंडों को तोड़ता हूं, या उन सभी को बूल चर के रूप में। तब 'अगर' कथन के शीर्ष-स्तरीय बूलियन तर्क को स्पष्ट किया जा सकता है। जिस तरह का काम मैं करता हूं, वह हमेशा कई चीजें ओर्डेड या एंडेड नहीं होती हैं।

bool goodblah = some_mess < whatever;
bool frobnacious = messy_crud != junky_expression;
bool yetanother = long_winded_condition;

if (goodblah || (frobnacious && yetanother))   {
    ...
}

यह विशेष रूप से एक डिबगर में अच्छा है, जहां मैं 'इफ' को निष्पादित करने से पहले सभी बूल को देख सकता हूं।

— DarenW
स्रोत

मुझे यह पसंद है, लेकिन आप एक लाभ खो देते हैं: यह अब शॉर्ट-सर्किट महंगी तुलना के लिए संभव नहीं है।

... और आपको सभी दिनों के टन चर के नामकरण में बहुत अच्छा होना चाहिए ...

— cronvel

6

मैं नई लाइनों की शुरुआत में ऑपरेटरों को संरेखित करता हूं ताकि मुझे याद रहे कि मैं शब्दों को कैसे संयोजित कर रहा हूं (दोनों लंबे तर्क और लंबे अंकगणित के लिए)। ऐशे ही:

if (first_attempt(data) == SUCCESS
    || (reusable(data) && second_attempt(data) == SUCCESS)
    || (still_reusable(data) && third_attempt(data) == SUCCESS))
  return SUCCESS;

यह केवल तभी काम करता है जब मैं 2-रिक्त स्थान से इंडेंट करता हूं या इंडेंट मल्टीलाइन पर अपने वातावरण को सेट करता हूं, और अधिक भविष्यवाणी करता है, अन्यथा यह बताना कठिन होगा कि कहां से विधेय समाप्त होता है और उपयोगी कोड शुरू होता है।

— होआ लॉन्ग टैम
स्रोत

0

मैं निम्नलिखित में से एक प्रशंसक हूं:

if (really_long_expression && another_really_really_long_expression && 
            another_very_long_expression_OMG_id_it_long){
    bugs();
}

इस तरह यह अभी भी एक अभिव्यक्ति की तरह दिखता है और अगर अभिव्यक्ति नहीं तो टूटी-डाउन-टू-पीस। इंडेंटेशन यह दिखाने में मदद करता है कि यह पिछली पंक्ति का एक निरंतरता है।

आप इसे तब तक इंडेंट भी कर सकते हैं जब तक कि ओपनिंग ब्रैकेट पिछली लाइन के अंत में न हो जाए ताकि यह एक्सप्रेशन के अंत में हो जैसा कि माना जाता है।

— EpsilonVector
स्रोत

1

मुझे वास्तव में आपके कीड़े () विधि पसंद आई: D

— जो फिलिप्स