अधिकांश भाग के लिए यह व्यक्तिगत प्राथमिकता है, हालांकि इस पर विचार करने के लिए कुछ चीजें हैं।
संभावित कीड़े
हालांकि यह तर्क दिया जा सकता है कि ऐड-इन करने के लिए ब्रेसिज़ भूल की वजह से कीड़े, दुर्लभ हैं कि मैं क्या है, वहां से देखा कि वे करते हो कभी कभी (भूलना नहीं प्रसिद्ध आईओएस गोटो असफल बग)। इसलिए मुझे लगता है कि आपकी कोड शैली पर विचार करते समय यह एक कारक होना चाहिए (कुछ उपकरण भ्रामक-इंडेंटेशन के बारे में चेतावनी देते हैं , इसलिए यह आपके टूल चेन पर भी निर्भर करता है) ।
वैध कोड (जो पढ़ता है जैसे यह एक बग हो सकता है)
यहां तक कि यह मानते हुए कि आपका प्रोजेक्ट ऐसे बग से ग्रस्त नहीं है, जब कोड पढ़ते हुए आपको कोड के कुछ ब्लॉक दिखाई दे सकते हैं, जैसे कि वे बग हो सकते हैं - लेकिन ऐसा नहीं है, तो आपके कुछ मानसिक चक्र ले रहे हैं।
हम इसके साथ शुरू करते हैं:
if (foo)
bar();
एक डेवलपर एक उपयोगी टिप्पणी जोड़ता है।
if (foo)
// At this point we know foo is valid.
bar();
बाद में एक डेवलपर ने इस पर विस्तार किया।
if (foo)
// At this point we know foo is valid.
// This never fails but is too slow even for debug, so keep disabled.
// assert(is_valid(foo));
bar();
या एक नेस्टेड ब्लॉक जोड़ता है:
if (foo)
while (i--) {
bar(i);
baz(i);
}
या मैक्रो का उपयोग करता है:
if (foo)
SOME_MACRO();
"... चूंकि मैक्रोज़ कोड की कई पंक्तियों को परिभाषित कर सकते हैं, क्या मैक्रो do {...} while (0)कई लाइनों के लिए उपयोग करता है ? इसकी वजह यह है कि हमारी शैली-गाइड में, लेकिन मैं सिर्फ मामले में बेहतर जांच करता हूं!"
ऊपर दिए गए उदाहरण सभी मान्य कोड हैं, हालांकि कोड-ब्लॉक में जितनी अधिक सामग्री है, उतनी ही आपको यह सुनिश्चित करने के लिए पढ़ना होगा कि कोई गलती नहीं है।
हो सकता है कि आपका कोड-स्टाइल यह परिभाषित करता हो कि मल्टी-लाइन ब्लॉक को ब्रेस की आवश्यकता होती है (कोई बात नहीं, भले ही वे कोड न हों) , लेकिन मैंने इस प्रकार की टिप्पणियों को उत्पादन कोड में जोड़ा जा रहा है। जब आप इसे पढ़ते हैं, तो कुछ छोटा संदेह होता है कि जिसने भी पिछली बार संपादित किया था वह पंक्तियों को एक ब्रेस जोड़ना भूल गया था, कभी-कभी मुझे लगता है कि डबल-चेक करने की आवश्यकता है (विशेषकर कोड के इस क्षेत्र में बग की जांच करते समय) ।
मुश्किल शोर
एकल लाइनों के लिए ब्रेसिज़ का उपयोग करने का एक व्यावहारिक कारण अलग शोर को कम करना है ।
वह है, बदलना:
if (foo)
bar();
सेवा:
if (foo) {
bar();
baz();
}
... सशर्त रेखा को परिवर्तित होने के कारण एक भिन्न रूप में दिखाने का कारण बनता है, यह कुछ छोटे लेकिन अनावश्यक ओवरहेड जोड़ता है।
- पंक्तियाँ कोड-समीक्षाओं में परिवर्तित होने के रूप में दिखाई देती हैं, यदि आपके अलग-अलग उपकरण शब्द-आधारित हैं, तो आप आसानी से देख सकते हैं कि केवल ब्रेस बदल गया है, लेकिन यह जाँचने में अधिक समय लेता है, यदि रेखा बिल्कुल नहीं बदली।
कहा जा रहा है कि, सभी उपकरण शब्द-आधारित भिन्नता का समर्थन नहीं करते हैं, अंतर (svn, git, hg ... आदि) दिखाएगा जैसे कि पूरी लाइन बदल गई, यहां तक कि फैंसी उपकरण भी, कभी-कभी आपको एक सादे रेखा पर जल्दी से देखने की आवश्यकता हो सकती है। -बड़े हुए अंतर को देखने के लिए कि क्या बदल गया है।
- एनोटेशन टूल (जैसे कि
git blame) लाइन को परिवर्तित होने के रूप में दिखाएगा, जिससे वास्तविक परिवर्तन खोजने के लिए लाइन के मूल को ट्रैक करना अधिक कदम होगा ।
ये दोनों छोटे हैं, और यह इस बात पर निर्भर करते हैं कि आप कोड-समीक्षा या ट्रैकिंग-डाउन में कितना समय बिताते हैं जो कोड की बदली हुई रेखाएं हैं।
अतिरिक्त लाइनों में परिवर्तन की एक अधिक ठोस असुविधा एक अंतर में बदल जाती है, उनकी उच्च संभावना-हुड जो कोड में परिवर्तन करती है, संघर्ष का कारण होगा जो विलय और मैन्युअल रूप से हल करने की आवश्यकता है ।
इसके लिए एक अपवाद है, कोड-बेस के लिए जो {अपनी लाइन पर है - यह कोई समस्या नहीं है।
Diff शोर तर्क नहीं रखता है अगर तुम इस शैली में लिखें:
if (foo)
{
bar();
baz();
}
हालाँकि, यह इतना आम सम्मेलन नहीं है, इसलिए मुख्य रूप से पूर्णता के लिए उत्तर को जोड़ना (सुझाव नहीं है कि परियोजनाओं को इस शैली का उपयोग करना चाहिए) ।
