सिंगल लाइन स्टेटमेंट और अच्छे आचरण

Question

मैंने हाल ही में एक आदत हासिल की है, जिसे मैं जानता हूं कि आप में से बहुत से लोग आगे बढ़ सकते हैं, लेकिन अंत में, मुझे एकल की संरचना के बजाय वैश्विक कोड संरचना पर नज़र रखने में मदद मिलती है, (कभी-कभी) दोहराव विधि: एक संख्या समूह बनाना एक पंक्ति में कथनों की इस तरह:

textBox1.Text = "Something!"; textBox2.Text = "Another thing!"; textBox3.Text = "Yet another thing!";

विरोध के रूप में

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";

मैं ऐसा करने के लिए दोहराए जाने वाले कार्यों का उपयोग करता हूं ताकि समग्र कोड "सौंदर्य" बनाए रखा जा सके और मुझे प्रोग्राम संरचना को आसानी से ट्रैक करने में मदद मिल सके, लेकिन मैं मानता हूं कि यह एक अच्छा अभ्यास नहीं हो सकता है। मैं वास्तव में इसका बहुत उपयोग करता हूं, इसलिए मैं जानना चाहता हूं कि इस पर आपके क्या विचार हैं। इसके अलावा, क्या आपको लगता है कि जो कोई भी कभी भी मेरे कोड को बनाए रखेगा उसे इस दृष्टिकोण से समस्या होगी?

Comments

इस के लिए एक अच्छा सवाल हो सकता है codereview.stackexchange.com

अगर मुझे बनाए रखना है तो मुझे समस्या होगी। पहली चीज़ जो मैं करूँगा वह है "," के लिए एक CTRL + F करना। और एक लाइन तोड़ दिया। लेकिन वह मैं ही हूं :-)। मुझे केवल एक पंक्ति पसंद है अगर मेरे पास एक पुनरासन है, उदाहरण के लिए कुछ टेक्स्ट बॉक्स के सक्षम गुणों को गलत के डिफ़ॉल्ट मान के साथ आरंभ करें: textBox1.Enabled = textBox2.Enabled = false;

— अरुण

यदि आप एक कोडिंग शैली प्रश्न पूछ रहे हैं, तो यदि आप भाषा निर्दिष्ट करेंगे तो यह मदद करेगा।

— कालेब

हालांकि यह दिए गए उदाहरण में उत्पन्न नहीं हो सकता है, आप दूसरे या तीसरे या ... एक बयान पर ब्रेकपॉइंट कैसे डालेंगे यदि आप उन सभी को एक पंक्ति में रख रहे हैं?

— मार्जन वेनमा

और यह भी, मैं स्वचालित स्वरूपण (जावा) के लिए उपयोग किया जाता हूं, जहां कोड को वैसे भी एक समान रूप मिलता है।

— Kwebble

Answer 1

मुझे वास्तव में लगता है कि पठनीयता आपके लिए और निश्चित रूप से कोड पढ़ने वाले किसी अन्य व्यक्ति के लिए बहुत कष्टदायक होगी। यह सब समझ में आता है जब आप इसे पहली बार लिखते हैं क्योंकि यह आपके दिमाग में सक्रिय रूप से है। जब आप कोड को स्कैन कर रहे हैं तो यह अलग है कि यह देखने के लिए कि चर और फ़ंक्शन कहाँ हैं ... आप अपने स्वयं के कोड को स्कैन करने की अपनी क्षमता को नष्ट कर रहे हैं। यह एक बहुत बड़ी संख्या है, और बुरे से परे अगर किसी और को कभी भी आपके कोड को पढ़ना होगा।

इसके अलावा, इस बारे में सोचें कि आपने कोड कैसे पढ़ा। यह हमेशा ऊपर नीचे होता है, नीचे स्क्रॉल होता है। आपकी विधि इसके साथ जाली नहीं है, और यहां तक ​​कि कोड पढ़ने में सबसे खराब संभव मुद्दों में से एक का परिचय देता है; क्षैतिज रूप से स्क्रॉल करना । कभी भी कम न समझें कि रीडिंग कोड कितना कठिन हो सकता है। आप कभी भी क्षैतिज रूप से स्क्रॉल नहीं करते हैं, आप कभी भी लोगों को क्षैतिज रूप से स्क्रॉल नहीं करते हैं, लगभग किसी भी संदर्भ में यह बेहद अप्राकृतिक है।

इसके अलावा, यदि आपका मुद्दा दोहरावदार कोड प्रविष्टि है ... Ctrl-C मत भूलना। आपके उदाहरण कोड से यह टाइप करने के लिए अधिक कुशल हो सकता है कि सभी मैन्युअल रूप से लिखें, लेकिन यदि आपको लाइनों का एक गुच्छा कॉपी करना है तो ऐसा लगता है कि यह लाइन वन प्लस नई लाइन को कॉपी करने के लिए उतना ही कुशल है, इसे पेस्ट करें एक्स बार और परिवर्तन करें, टाइपो भी बनाने की संभावना कम है।

ओह, और टाइपो! अपने कोड की पठनीयता को इस तरह से नुकसान पहुँचाना कि यह एक बुरा सपना हो सकता है कि 50 में से कौन सा परिवर्तनशील घोषणाएँ गलत हैं। अधिकांश संकलक अब पंक्ति और स्तंभ संख्याओं में त्रुटियां देते हैं, लेकिन एक पंक्ति में एक त्रुटि खोजना स्तंभ खोजने से आसान है।

Comments

a) रीडिंग / स्कैनिंग कोड - अधिकांश लोग जब कोड स्कैन करते हैं तो लाइन के पहले कुछ अक्षर पढ़ते हैं, तब तक आगे बढ़ते हैं जब तक कि यह "दिलचस्प" न हो, तब वे एक जोड़े को अधिक पढ़ें। कंपाइलर त्रुटियां: अधिकांश समय मैं कंपाइलर त्रुटि को "लाइन <x> समस्या के साथ" के रूप में व्याख्या करता हूं। केवल अगर मैं कर सकता हूँ, यह तुरंत (दुर्लभ) काम नहीं है, इसलिए मैं वास्तव में त्रुटि पढ़ा है।

— मटनज़

Answer 2

प्रति पंक्ति एक कथन भी यह देखना आसान बनाता है कि साइड-बाय-साइड अंतर में क्या बदल गया है।

Comments

यह शायद सबसे बड़ा कारण है, अगर किसी को उस कोड को मर्ज करना है, तो लगभग सभी मर्ज टूल पंक्तियों के सब्सट्रेटिंग के बजाय लाइनों को अलग करने और स्थानांतरित करने के लिए आसान बनाने जा रहे हैं।

— anon

@anon मर्ज टूल के बारे में अच्छा बिंदु; प्रति पंक्ति एक कथन का मतलब है कि कम मर्ज की सफाई के लिए संघर्ष।

— ह्यूगो

Answer 3

जबकि उदाहरण यह नहीं दिखाता है, एक लाइन पर कई बयानों को समूहीकृत करने के साथ एक और समस्या है। क्या होगा अगर एक सिंगल लाइन पर आपके द्वारा दिए गए पांच कथनों में से कोई एक अपवाद फेंकता है?

आपका स्टैक ट्रेस कहेंगे "ईबाला एट लाइन एन" ... और अब आपको पता नहीं है कि उन पांच बयानों में से किसने अपवाद को फेंक दिया।

(यही बात किसी भी तरह के अत्यधिक लंबे बयान के साथ होती है।)

Comments

एक ही अवधारणा डिबगिंग पर लागू होती है, जहां एक बार फिर ग्रैन्युलैरिटी आमतौर पर एक पंक्ति संख्या होती है।

— डेविड हैमेन

अरे मेरी हाँ, यह एक समस्या हो सकती है। एक "पसंदीदा" तब होता है जब आपको एक शून्य पॉइंटर कुछ ढीला मिलता है जैसे foo.bar[grill.boo].flip.flap[flop].mickey(minnie).marshmallow(जावा / सी # सिंटैक्स)। उस तरह की गंदगी के माध्यम से छंटनी हमेशा अतिरिक्त लाइनों (और अस्थायी चर ... और मूल डेवलपर के लिए एक 2D6 ईंट का सुराग) के साथ बेहतर होती है।

— डोनल फैलो

Answer 4

एक-कथन-प्रति-पंक्ति एक व्यापक रूप से उपयोग की जाने वाली कोडिंग शैली है। नतीजतन, अधिकांश डेवलपर्स जो भविष्य में आपके कोड को देखते हैं, वे संभवतः तब विन्च करेंगे जब वे प्रति पंक्ति कई कथन देखेंगे। जब आप एक तरह से कुछ देखने के आदी हो जाते हैं, तो इसे दूसरे तरीके से देखना भटकाव हो सकता है।

इस कारण से मैं इसके खिलाफ सलाह देता हूं, दुर्लभ परिस्थितियों को छोड़कर।

Answer 5

मैंने आखिरी बार 25 साल पहले कम घड़ी की गति के साथ चलने वाले छोटे माइक्रो पर व्याख्या की गई भाषाओं का उपयोग किया था, जहां हर स्थान या गाड़ी वापसी ने प्रदर्शन में वृद्धि दी।

मैं अब इसके बारे में सोचता हूं (हालांकि यह एक अच्छे कारण के लिए किया गया था)।

दुर्भाग्य से ऐसे कोड को पढ़ना मुश्किल है, और इस प्रकार बनाए रखना मुश्किल है।

Comments

तो आप इसे ठीक से लिखें, फिर अपनी "मशीन कॉपी" के लिए व्हाट्सएप और किसी भी अन्य प्रस्तुतिकरण को पट्टी करें। ठीक वैसे ही जैसे आजकल जावास्क्रिप्ट का उपयोग किया जाता है।

— कैफीक

हाँ - मैंने उस तरह से भी स्रोत कोड को पुन: पेश करने के लिए एक कार्यक्रम लिखा था - 1986 में वापस। एक और बात मुझे आशा है कि फिर कभी करने की आवश्यकता नहीं है।

— जल्दी_अगले

Answer 6

सिंथेटिक, वास्तव में इसके साथ कुछ भी गलत नहीं है। यह वास्तव में आपकी टीम की कोडिंग शैली पर निर्भर करता है।

जैसा कि मैंने देखा है कि अधिकांश कोड (मानक सी ++ हेडर के अंदर कोड सहित) इस तरह से किया जाता है, मैं आपकी पहली विधि के साथ जाऊंगा।

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";

Answer 7

यह वास्तव में असामान्य कोडिंग शैली है।

मैं आपको कोड के तार्किक भागों को परिसीमित करने के लिए खाली लाइनों का उपयोग करने की सलाह दूंगा।

Answer 8

दाईं ओर बहुत दूर जाने से कई लाइनों के रूप में कई समस्याएं पैदा हो सकती हैं।

मुझे दर्जनों क्षेत्रों के साथ कुछ एसक्यूएल कथनों से निपटना पड़ा है। आम तौर पर, मैं प्रति पंक्ति एक डाल सकता हूं, लेकिन कुछ अवसरों पर, मैंने एक पंक्ति में 3 या 4 को समेकित किया है। ऐसा लगता है कि विकास के दौरान एक अच्छा विचार है जब आप कई बार ऊपर और नीचे स्क्रॉल करना चाहते हैं।

मुझे इस कोड पर लौटने का पछतावा है। अतिरिक्त पंक्तियाँ होने से बस इतनी समस्या पैदा नहीं होती है इसलिए मैं आमतौर पर इसे साफ कर देता हूं।

Answer 9

इसके अलावा, क्या आपको लगता है कि जो कोई भी कभी भी मेरे कोड को बनाए रखेगा उसे इस दृष्टिकोण से समस्या होगी?

एक मिनट के लिए उसके सिर पर हाथ रखने के बाद, वह अपने पसंदीदा आईडीई रेगेक्स फंक्शनलिटीज का उपयोग करके स्वचालित रूप से एक पंक्ति में सभी अप्राप्य कोड को अलग कर देगा।

आपके द्वारा दिखाए गए उदाहरण पर एक त्वरित नज़र यह समझने के लिए पर्याप्त है कि दूसरा दृष्टिकोण कितना अधिक पठनीय है।

ऊर्ध्वाधर पृष्ठ प्रवाह का पालन करना बहुत आसान है, बिना आपकी आंखों को क्षैतिज रूप से स्थानांतरित करने के लिए।

अपने उदाहरण को देखें: आप तुरंत जानते हैं कि कोड सभी Textविभिन्न textBoxवस्तुओं की संपत्ति के बारे में है , और वे मान के रूप में स्ट्रिंग होते हैं। बहुत सीधा।

Answer 10

मैं व्यक्तिगत रूप से ऐसी शैली का उपयोग नहीं करूंगा। संक्षेप में

पेशेवरों

• स्क्रॉल करने के लिए कोड की कम पंक्तियाँ
• अभिव्यक्त करने के लिए शब्दार्थ समूह कोड का उपयोग किया जा सकता है: "बहुत सारा असाइनमेंट सामान"। लेकिन आप हमेशा किसी फ़ंक्शन में इस तरह के ब्लॉक को रिफ्लेक्टर कर सकते हैं यदि यह आपको बहुत परेशान करता है।

विपक्ष

• पढ़ना मुश्किल है, यह आमतौर पर कोड को क्षैतिज रूप से पढ़ना आसान है (स्किमिंग, कोई आँख आंदोलन, ...)
• विलय आसानी से एक दुःस्वप्न बन जाता है, जिसमें विलय भी शामिल है
• बदलने के लिए और अधिक कठिन (कॉपी और पेस्ट, टिप्पणी करना, ...)
• डिबगिंग कई आईडीई में एक समस्या हो सकती है क्योंकि वे व्यक्तिगत अभिव्यक्तियों के बजाय लाइनों पर काम करते हैं।

Comments

कुछ "बुरा" समय पर हो सकता है। उदाहरण के लिए, मान लीजिए कि कोड के एक टुकड़े में फार्म के लगातार आठ संचालन हैं if (x > maxX) {x=maxX; peggedAny = true;}। यदि इस तरह का प्रत्येक ऑपरेशन एक ही लाइन पर आसानी से फिट होगा, तो मेरे पास दर्जनों लाइनों की तरह आठ लाइनें होंगी जो बयानों को विभाजित करती हैं। यदि ऐसी तुलनाओं को पर्याप्त स्थानों पर उपयोग किया जाता है, तो फॉर्म के चार कथन peggedAny |= pegValueMinMax(ref x, minX, maxX);बेहतर हो सकते हैं, लेकिन किसी को पढ़ने वाले pegValueMinMaxको यह देखने के लिए पढ़ना होगा कि यह क्या करता है।

— सुपरकैट

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

— सुपरकाट