क्या प्रोग्रामिंग अभ्यास है कि आप एक बार पसंद आया है जब से आप के बारे में अपना मन बदल दिया है? [बन्द है]

Question

जैसा कि हम कार्यक्रम करते हैं, हम सभी अभ्यास और पैटर्न विकसित करते हैं जो हम उपयोग करते हैं और भरोसा करते हैं। हालांकि, समय के साथ, हमारी समझ, परिपक्वता और यहां तक ​​कि तकनीक के उपयोग में परिवर्तन के रूप में, हमें पता चलता है कि कुछ प्रथाएं जो हमने सोचा था कि एक बार महान थीं (या अब लागू नहीं होती हैं)।

एक अभ्यास का एक उदाहरण जो मैंने एक बार काफी बार उपयोग किया था, लेकिन हाल के वर्षों में बदल गया है, सिंगलटन ऑब्जेक्ट पैटर्न का उपयोग है ।

अपने स्वयं के अनुभव और सहकर्मियों के साथ लंबी बहस के माध्यम से, मुझे पता चला है कि सिंगलटन हमेशा वांछनीय नहीं होते हैं - वे परीक्षण को और अधिक कठिन बना सकते हैं (मॉकिंग जैसी तकनीकों को रोककर) और सिस्टम के कुछ हिस्सों के बीच अवांछनीय युग्मन बना सकते हैं। इसके बजाय, मैं अब ऑब्जेक्ट फैक्ट्रियों (आमतौर पर एक IoC कंटेनर के साथ) का उपयोग करता हूं जो सिस्टम के कुछ हिस्सों से सिंगलटन की प्रकृति और अस्तित्व को छिपाते हैं जो परवाह नहीं करते हैं - या जानने की आवश्यकता है। इसके बजाय, वे ऐसी वस्तुओं तक पहुंच प्राप्त करने के लिए एक कारखाने (या सेवा लोकेटर) पर भरोसा करते हैं।

आत्म-सुधार की भावना से समुदाय के लिए मेरे प्रश्न हैं:

• हाल ही में आपने किन प्रोग्रामिंग पैटर्न या प्रथाओं पर पुनर्विचार किया है, और अब बचने की कोशिश करते हैं?
• आपने उन्हें बदलने का फैसला क्या किया?

Answer 1

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

Comments

+1। मैं इसी उत्तर को पोस्ट करने वाला था। मुझे कुछ हफ्तों पहले एक संग्रह डिस्क पर मेरे कुछ पुराने प्रोग्रामिंग असाइनमेंट मिले। यह सब एक जैसा दिखता था। कोड की लाइनों के लिए टिप्पणियों की लाइनों का लगभग 1: 1 अनुपात था।

— माइकल मौसा

लगता है कि आपने गलत टिप्पणी की , बहुत ज्यादा नहीं। कोड खुद के लिए नहीं बोलता है। नहीं। यह वास्तव में नहीं है। इस बारे में अच्छे शेख़ी के लिए नवीनतम एनटी इनसाइडर पढ़ें। अगर आपको लगता है कि टिप्पणियां निरर्थक होंगी तो आप गलत हैं या आप गलत कर रहे हैं। विश्वविद्यालय सही टिप्पणी नहीं सिखाते हैं, ऐसा लगता है (या बग ट्रैकिंग, या संस्करण नियंत्रण ... * आह *)। वहाँ भी कुछ टिप्पणियाँ वहाँ तरह हैं। (और कम अच्छे)

— थॉमस

कोड कम्प्लीट में कमेंट करने के अच्छे टिप्स हैं, और इसे वापस करने के लिए डेटा।

— थॉमस

टिप्पणियों का उपयोग यह बताने के लिए किया जाना चाहिए कि कोड ऐसा क्यों करता है (यदि यह स्पष्ट नहीं है), न कि कोड क्या करता है। कार्मैक के मैजिक नंबर 0x5f3759df की तरह एक संभावित अपवाद एक पागल बिटिंग / लैंग्वेज हैक है।

— क्रिस सीमन्स

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

— डैन ल्यू

Answer 2

एकल वापसी अंक।

मैंने एक बार प्रत्येक विधि के लिए एकल वापसी बिंदु को प्राथमिकता दी, क्योंकि इसके साथ ही मैं यह सुनिश्चित कर सकता था कि दिनचर्या द्वारा आवश्यक किसी भी सफाई की अनदेखी नहीं की गई थी।

तब से, मैं बहुत छोटी दिनचर्या में चला गया हूं - इसलिए सफाई की अनदेखी की संभावना कम हो जाती है और वास्तव में सफाई की आवश्यकता कम हो जाती है - और पाते हैं कि शुरुआती रिटर्न कोड की स्पष्ट जटिलता (नेस्टिंग स्तर) को कम करते हैं। सिंगल रिटर्न पॉइंट की कलाकृतियाँ - "रिजल्ट" वेरिएबल्स को इधर-उधर रखना, फ्लैग वैरिएबल रखना, पहले से नहीं की गई स्थितियों के लिए सशर्त क्लॉज़ - कोड को वास्तव में की तुलना में बहुत अधिक जटिल दिखाई देते हैं, इसे पढ़ना और बनाए रखना कठिन बनाते हैं। शुरुआती निकास, और छोटे तरीके, जाने का रास्ता हैं।

Comments

मैं सहमत हूं, जब डेटा प्रकारों के साथ संयुक्त होता है जो स्वचालित रूप से स्वयं को साफ करते हैं, जैसे कि ऑटोप्ट्र, स्कोप्ड_प्ट्र, सीसीओमप्रोट, आदि

— i_am_jorf

कोड को साफ करना है जो {} अंत में {} के लिए है

— banjollity

@banjollity: अंत में {} का समर्थन नहीं करने वाली भाषाओं को छोड़कर। और ध्यान दें कि भाषाओं में भी जो इसका समर्थन करते हैं, अंत में {} निष्पादन के लिए हमेशा की गारंटी नहीं है।

— क्रिस के

@banjollity, क्रिस: सी ++ में, सफाईकर्त्ता वह है जो विध्वंसक है, और चरम परिस्थितियों (निकास) को छोड़कर, स्टैक के दौरान एक अपवाद को फेंकने वाला एक विध्वंसक, आपकी शक्ति को काटने वाली गिलहरी) इसे चलाने की गारंटी है।

— डेविड थॉर्नले

माना। गार्ड क्लाज ftw के साथ नेस्टेड कंडीशनल बदलें !

— जोनिक

Answer 3

• पहली कोशिश में चीजों को पूरी तरह से कोड करने की कोशिश करना।
• कोडिंग से पहले परफेक्ट OO मॉडल बनाने की कोशिश की जा रही है।
• लचीलापन और भविष्य में सुधार के लिए सब कुछ डिजाइन करना।

एक शब्द में overengineering ।

Comments

रुको, मैं हमेशा इसे पहली कोशिश में सही पाता हूं। :)

— i_am_jorf

पहली बार इसे प्राप्त करने में वास्तविक धन का गलत होना और इसे जंगली में देना। फिर, जब लोगों को जिम्प्ड वर्जन के लिए इस्तेमाल किया जाता है, तो घमंडी दिखावे के साथ झपट्टा मारते हैं और अतिरिक्त शोभा बढ़ाने के लिए बग / अक्षमता को ठीक करते हैं! ;)

— एरिक

@ जेफ्फामफोन - नहीं, केवल जॉन स्कीट को ही यह पहली बार मिला।

— जॉर्डन पार्मर

मुझे "ओवरगिनरिंग" शब्द पसंद है

— नीलवर्ट नोवल

@ जेफामफोन - मैं हमेशा इसे पहले प्रयास में ही प्राप्त कर लेता हूं। लेकिन आगे के प्रयास मुझे क्या चाहिए :)

— umbr

Answer 4

हंगेरियन नोटेशन (फॉर्म और सिस्टम दोनों)। मैं सब कुछ उपसर्ग करता था। strSomeString या txtFoo। अब मैं someString और textBoxFoo का उपयोग करता हूं। किसी भी नए व्यक्ति के साथ आने और उसे लेने के लिए यह अधिक पठनीय और आसान है। एक अतिरिक्त बोनस के रूप में, इसे निरंतर बनाए रखना तुच्छ है - नियंत्रण को व्यवस्थित करना और एक उपयोगी / वर्णनात्मक नाम जोड़ना। प्रपत्र हंगेरियन में हमेशा सुसंगत नहीं होने का दोष है और सिस्टम हंगेरियन वास्तव में आपको अधिक लाभ नहीं देता है। अपने सभी चरों को एक साथ बदलना वास्तव में उतना उपयोगी नहीं है - विशेषकर आधुनिक IDE के साथ।

Comments

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

— डैन ल्यू

मैं छोड़कर समान कार्य करें: fooTextBox और स्ट्रिंग के बस उम्मीद है कि स्पष्ट कर रहे हैं: numberOfEntries => पूर्णांक, isGreat => bool, आदि

— rball

हंगेरियन नोटेशन से छुटकारा पाने के लिए +1। मैं रूबेल से सहमत हूँ; fooTextBox, fooService, fooString जब इसकी वास्तव में आवश्यक हो।

— blu

@ wuub: मेरा तर्क है कि उचित नामकरण के साथ, आपको कुछ भी उपसर्ग करने की आवश्यकता नहीं होनी चाहिए।

— केनी मान

वैसे आपने जो उल्लेख किया है वह वास्तविक मैरी नहीं है।

— एंटनी कैर्थी

Answer 5

"परिपूर्ण" वास्तुकला

मैं के साथ आया था कुछ साल पहले वास्तुकला। खुद को तकनीकी रूप से आगे बढ़ाया जहां तक ​​मैं कर सकता था 100% शिथिल परतों, प्रतिनिधियों का व्यापक उपयोग, और हल्के वस्तुओं थे। यह तकनीकी स्वर्ग था।

और यह बकवास था। वास्तुकला की तकनीकी शुद्धता ने परिणामों के आधार पर पूर्णता के लक्ष्य के लिए मेरी देव टीम को धीमा कर दिया और मैंने लगभग पूरी विफलता हासिल की।

अब हमारे पास तकनीकी रूप से परिपूर्ण वास्तुकला कम सरल है और हमारी वितरण दर आसमान छू गई है।

Answer 6

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

Comments

आपको और भी अधिक कॉफी पीने की जरूरत है। यदि वह काम नहीं करता है, तो धूम्रपान करें।

— मुशीनेसिस जूल

ब्रैड: आपको उन लोगों की आवश्यकता नहीं है जब आपके पास पायथन है: xkcd.com/353

— पीटर

अच्छा क्रिसमस कहानी संदर्भ! :-)

— स्टीव इकोल्स

मैंने आदत को तोड़ दिया और फिर इसे कई बार उठाया (यह अब मेरा तीसरा चक्र है)। वहाँ कॉफी की एक गर्म मग के साथ ठंड सुबह में कोडिंग की तरह कुछ भी नहीं है!

— मैथ्यू इसेलिन

"ऐसा लगता है कि मैंने एम्फ़ैटेमिन छोड़ने के लिए गलत सप्ताह चुना।"

— श्रीवत्सआर

Answer 7

कोड बाहर टिप्पणी करना। मुझे लगता है कि कोड कीमती था और आप उन सुंदर रत्नों को हटा नहीं सकते जिन्हें आपने तैयार किया था। मैं अब तक कोई भी टिप्पणी-रहित कोड हटा देता हूं, जब तक कि TODO या NOTE संलग्न न हो, क्योंकि इसे छोड़ने के लिए बहुत खतरनाक है। बुद्धि के लिए, मैं पुरानी टिप्पणी वाले पुराने वर्गों के साथ पुरानी कक्षाओं में आया हूं और यह वास्तव में मुझे भ्रमित करता है कि वे क्यों। वहाँ थे: वे हाल ही में टिप्पणी की थी? क्या यह एक देव परिवेश है? यह यह असंबंधित ब्लॉक क्यों करता है?

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

Comments

मैं रीफैक्टरिंग के दौरान पुराने कोड को टिप्पणी करता हूं, लेकिन केवल जब तक मैं यह सत्यापित नहीं करता कि प्रतिस्थापन कोड काम करता है। एक बार नया संस्करण पूरी तरह कार्यात्मक हो जाने के बाद, मैं पुरानी टिप्पणी की गई लाइनों को हटा देता हूं।

— मूसबुल्ला

वास्तव में - मैं कोड भी टिप्पणी करता हूं, लेकिन केवल कुछ दिनों के लिए। अगर मैं वापस आता हूं और मुझे महसूस हुआ है कि थोड़ा सा चूक गया है, तो नए कोड पर काम करने से पहले इसे हटा दिया जाएगा।

— कॉलिन मैके

मैं कहता हूं कि एक बार टिप्पणी कोड में जांच करें, इसे हटा दें। कई बार जब आप कोड के विभिन्न बिट्स का परीक्षण करते हैं, और आप टूटे हुए कोड में जांच नहीं करना चाहते ...

— DisgruntledGoat

यह उल्लेख करने के लिए नहीं कि संस्करण नियंत्रण आपका मित्र है।

— डेविड थॉर्नले

+1 मैंने एक प्रोग्रामर के साथ काम किया जो उस कोड के सभी पर टिप्पणी करने पर जोर देता था जिसे उसने फिर से लिखा या फिर से लिखा था। यह मुझे पागल कर देगा क्योंकि कभी-कभी मुझे जो काम कर रहा था उसे खोजने के लिए मुझे 1k + लाइनों के माध्यम से स्क्रॉल करना होगा।

— इवान प्लाइस

Answer 8

# भाग निर्देश का अति प्रयोग / दुरुपयोग। यह सिर्फ एक छोटी सी बात है, लेकिन C # में, मैं पहले अपनी कक्षाओं को व्यवस्थित करने के लिए, पूरे स्थान पर #region निर्देशों का उपयोग करूंगा। उदाहरण के लिए, मैं एक क्षेत्र में सभी वर्ग गुणों को एक साथ समूहीकृत करूँगा।

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

Comments

मुझे इस क्षेत्र से नफरत है। मेरी टीम के लोग उनका जमकर इस्तेमाल करते हैं। मैं उन्हें "खराब कोड के हूडर्स" कहता हूं।

— रॉ जूल 6'09

वे निश्चित रूप से एक कोड गंध हैं।

— फ्रैंक श्वेतेरमैन

मैं क्षेत्रों से नफरत है मैं वर्तमान में कोड बना रहा हूं जहां फ़ंक्शन लगभग 500 लाइनें हैं और इसे प्रबंधित करने के लिए, स्मार्ट डेवलपर ने 10 से 15 क्षेत्रों में कोड का हिस्सा रखा है।

— समाधानयोगी

@ विकास योगी: मुझे नहीं लगता कि आपके मामले में क्षेत्र वास्तविक समस्या हैं :-)

— एड एस।

मुझे लगता है कि अगर संयम से इस्तेमाल किया जाए तो क्षेत्र ठीक हो सकते हैं।

— ग्रेगरी हिगली

Answer 9

सामान्य रूप से झरना विकास, और विशिष्ट में, पूर्ण और व्यापक कार्यात्मक और डिजाइन विनिर्देशों को लिखने का अभ्यास जो किसी भी तरह से विहित होने की उम्मीद कर रहे हैं और फिर उन लोगों के कार्यान्वयन को सही और स्वीकार्य होने की उम्मीद करते हैं। मैंने देखा है कि इसे स्क्रैम के साथ बदल दिया गया है, और इसके लिए अच्छी रिडांस है, मैं कहता हूं। साधारण तथ्य यह है कि ग्राहकों की बदलती जरूरतों और इच्छाओं को कोई भी निश्चित विनिर्देश प्रभावी रूप से बेकार बनाता है; वास्तव में ठीक से दृष्टिकोण करने का एकमात्र तरीका एक पुनरावृत्ति दृष्टिकोण के साथ है। ऐसा नहीं है कि स्क्रम एक चांदी की गोली है, ज़ाहिर है; मैंने कई बार इसका दुरुपयोग और दुरुपयोग किया है। लेकिन यह जलप्रपात को हरा देता है।

Comments

मेरे ग्राहक को बताएं ... मैं कुछ बेकार लिखने के बीच में हूं "मैं एक क्रिस्टल बॉल के साथ एक प्रोग्रामर हूं, इसलिए मुझे ठीक से पता है कि 6 महीने में मेरा निम्न-स्तरीय डिज़ाइन कैसा दिखेगा" विनिर्देश दस्तावेज़ :)

— इगोर ब्रजक जूल 27'09

Answer 10

कभी दुर्घटनाग्रस्त नहीं हुआ।

ऐसा लगता है कि यह एक अच्छा विचार है, है ना? उपयोगकर्ता प्रोग्राम को पसंद नहीं करते जो क्रैश करते हैं, इसलिए आइए उन प्रोग्रामों को लिखें जो क्रैश नहीं करते हैं, और उपयोगकर्ताओं को प्रोग्राम को पसंद करना चाहिए, है ना? इसी तरह मैंने शुरुआत की।

आजकल, मुझे लगता है कि अगर यह काम नहीं करता है, तो मुझे लगता है कि यह काम नहीं करना चाहिए। जैसे ही आप कर सकते हैं, एक अच्छा त्रुटि संदेश के साथ विफल। यदि आप नहीं करते हैं, तो आपका कार्यक्रम कुछ ही निर्देशों के बाद और भी कठिन क्रैश करने जा रहा है, लेकिन कुछ नॉन्डस्क्रिप्ट नाफ्ट-पॉइंटर एरर के साथ जो आपको डीबग करने में एक घंटा लगेगा।

मेरा पसंदीदा "क्रैश न करें" पैटर्न यह है:

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

अब, अपने उपयोगकर्ताओं को त्रुटि संदेश को कॉपी / पेस्ट करने और आपको भेजने के लिए कहने के बजाय, आपको लॉग प्रविष्टि खोजने की कोशिश कर लॉग में गोता लगाना होगा। (और जब से वे एक अमान्य उपयोगकर्ता आईडी दर्ज करते हैं, कोई लॉग प्रविष्टि नहीं होगी।)

Comments

उपयोगकर्ता द्वारा आपको वास्तविक त्रुटि संदेश देने की संभावना क्या है, बनाम आपके लॉग इस मुद्दे का उत्पादन कर रहे हैं? (इस विशेष मामले में बहुत कम है, लेकिन उपयोगकर्ता लगभग त्रुटि संदेशों को कभी उद्धृत नहीं करते हैं!) क्या वे उन्हें पढ़ते हैं?

— अराफंगियन

मैं मानता हूं कि मौका कम है कि एक यादृच्छिक उपयोगकर्ता आपको त्रुटि संदेश भेजता है, लेकिन मौका गैर-शून्य (तुच्छ उदाहरण: कभी-कभी आप अपने खुद के ऐप का उपयोग करते हैं), और कुछ उपयोगकर्ता समय के साथ सीखते हैं कि कॉपी / पेस्ट क्या करना है। मैं यह नहीं कह रहा हूं कि आपको लॉग इन नहीं करना चाहिए (आपको चाहिए), लेकिन जब ऐप टूट जाता है तो वह टूट जाता है। त्रुटि संदेश दिखाना बेहतर है, उपयोगकर्ता को यह दिखावा करने की तुलना में कहीं अधिक ईमानदार है कि उपयोगकर्ता का पहला नाम "डेटाबेस के साथ संचार करने में त्रुटि" (या इससे भी बदतर, nullया खाली स्ट्रिंग है)।

— gustafc

वहाँ दो लाइन पर एक NullReferenceException है

— '

धन्यवाद, ओ, मैंने इसे ठीक किया। (हालांकि इसके साथ यह थोड़ा सुस्त था: अपवादों और अन्य "दुर्घटनाओं" से बचने के लिए यह सब परेशानी, और फिर भी यह बिना शर्त दुर्घटनाग्रस्त हो गया।)

— gustafc

Answer 11

मुझे लगा कि जब भी मैंने उन्हें पहचाना डिजाइन पैटर्न लागू करने के लिए यह समझ में आया।

थोड़ा मुझे पता था कि मैं वास्तव में विदेशी प्रोग्रामिंग भाषाओं से शैलियों की नकल कर रहा था, जबकि मैं जिस भाषा में काम कर रहा था वह कहीं अधिक सुरुचिपूर्ण या आसान समाधान के लिए अनुमति दी गई थी।

कई (बहुत) अलग-अलग भाषाओं का उपयोग करने से मेरी आँखें खुली और मुझे एहसास हुआ कि मुझे उन लोगों के लिए अन्य समस्याओं के समाधान को गलत तरीके से लागू नहीं करना है जो मेरी नहीं हैं। अब जब मैं रूबी जैसी भाषा में लागू फैक्ट्री पैटर्न देखता हूं तो मैं कांप जाता हूं ।

Comments

कृपया माणिक की मेरी अज्ञानता का बहाना करें, लेकिन हमें इसके साथ कारखाने के पैटर्न का उपयोग क्यों नहीं करना चाहिए?

— माइक चेम्बरलेन

यहाँ एक माणिक नहीं है, लेकिन कारखाना कार्यान्वयन के आधार पर बचने का है, लेकिन माणिक गतिशील है, और आप कुछ भी मॉक या स्टब कर सकते हैं। इसलिए आप वास्तव में कार्यान्वयन पर निर्भर नहीं होते हैं।

— स्टीफन

Answer 12

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

वास्तव में, किसी भी चीज़ का धीरे-धीरे पालन करना हानिकारक हो सकता है।

Comments

यह बार्नकल के लिए बहुत अच्छा काम करता है।

— मुशीनेसिस जूल

टेस्ट कवरेज लाभ के लिए आनुपातिक होना चाहिए। जो कुछ भी आप वास्तव में करते हैं उसे एक लाभ दिखाना होगा। 100% कवरेज आपको इतना सब कुछ नहीं देने वाला है। life० या ९ ० रूप से अंतर जो जीवन समर्थन / मिसाइल लॉन्च परिदृश्य में नहीं है।

— स्पैन

परीक्षण के विपरीत इकाई परीक्षण पर +1 निर्भरता।

— प्रीत संघ

Answer 13

यह एक छोटी सी बात है, लेकिन: ब्रेसिज़ कहाँ जाता है (उसी लाइन या अगली पंक्ति पर?) के बारे में परवाह करते हुए, कोड की अधिकतम लाइन लंबाई, चर के लिए नामकरण सम्मेलनों और शैली के अन्य तत्वों का सुझाव दिया। मैंने पाया है कि हर कोई इस बात से ज्यादा परवाह करता है कि मैं ऐसा करता हूं, इसलिए मैं सिर्फ इस बात का ध्यान रखता हूं कि जो भी मैं आजकल काम कर रहा हूं।

संपादित करें: इसके अपवाद, निश्चित रूप से, जब मैं वह होता हूं जो सबसे अधिक परवाह करता है (या समूह के लिए शैली सेट करने की स्थिति में एक है)। उस मामले में, मैं वही करता हूं जो मैं चाहता हूं!

(ध्यान दें कि यह कोई सुसंगत शैली नहीं है। मुझे लगता है कि कोडबेस में एक सुसंगत शैली पठनीयता के लिए बहुत महत्वपूर्ण है।)

Comments

किसी ने इसे कम कर दिया, लेकिन मुझे लगता है कि यह एक व्यावहारिक दृष्टिकोण है। सबसे अच्छा कोड स्टाइल क्या है? महत्वपूर्ण नहीं। एक ही फ़ाइल में ऊपर और नीचे देखो और डुप्लिकेट।

— फ्रैंक श्वेतेरमैन

सबसे अच्छा कोड स्टाइलिंग उस दुकान के लिए जो भी मानक है।

— डेविड थॉर्नले

यही कारण है कि मैं दृश्य स्टूडियो में ऑटो प्रारूप विकल्पों से प्यार करता हूं। इससे कोई फर्क नहीं पड़ता कि अन्य डेवलपर्स ने कैसे लिखा कोड मैंने सिर्फ एक त्वरित प्रारूप किया है और इसके बिल्कुल मैं इसे कैसे पसंद करता हूं ... अधिकांश समय।

— corymathews

@ संस्करण: क्या आपके संस्करण नियंत्रण सॉफ़्टवेयर की क्षमता को गड़बड़ नहीं करता है ताकि आप उस फ़ाइल के संस्करणों के बीच अंतर दिखा सकें जिसे आपने अभी-अभी सुधार किया है?

— स्टीव मेलनिकॉफ

यही कारण है कि मैं अजगर सीखने के प्रति आकर्षित हूं ... यह सोचने के लिए कि मुझे बस इस बात की चिंता करनी होगी कि मेरे टैस्टॉप्स स्टाइल के लिए क्या सेट हैं, और नहीं। यह सम्मोहक की तरह है।

— क्रिस के

Answer 14

शायद सबसे महत्वपूर्ण "प्रोग्रामिंग अभ्यास" मैंने तब से अपना मन बदल दिया है, यह विचार है कि मेरा कोड बाकी सभी की तुलना में बेहतर है। यह प्रोग्रामर (विशेषकर newbies) के लिए आम है।

Answer 15

उपयोगिता पुस्तकालय। मैं एक असेंबली के आसपास कई तरह की सहायक विधियों और कक्षाओं के साथ इस सिद्धांत के साथ जाता था कि मैं किसी दिन उनका उपयोग कर सकता हूं।

हकीकत में, मैंने सिर्फ कार्यक्षमता के बहुत खराब संगठित बिट्स के साथ एक विशाल नाम स्थान बनाया है।

अब, मैं उन्हें केवल उस परियोजना में छोड़ देता हूं जिसे मैंने उन्हें बनाया था। सभी संभाव्यता में मुझे इसकी आवश्यकता नहीं है, और यदि मैं करता हूं, तो मैं उन्हें बाद में पुन: प्रयोज्य कुछ में बदल सकता हूं। कभी-कभी मैं उन्हें एक आम सभा में संभावित निकासी के लिए // TODO के साथ ध्वजांकित करूंगा।

Comments

। एक अच्छा उद्धरण (मैं पल में मूल नहीं मिल सकता है), जो "का भी एक सामान्य दिनचर्या बनाने जब तक आप एक ही समस्या को हल करने के लिए 3 बार की जरूरत है, उसके बारे में नहीं सोचता पंक्तियों के साथ कुछ ऐसा था नहीं है

— DaveR

"तीन हमले और आप प्रतिक्षेपक" - मार्टिन फाउलर द्वारा Refactoring । द रूल ऑफ थ्री , पृष्ठ 58.

— निक डंडौलकिस

Answer 16

मैं कोडित से अधिक डिजाइनिंग। थोड़ी देर के बाद, यह विश्लेषण पक्षाघात में बदल जाता है।

Comments

मैं कभी-कभी वाक्यांश को लागू करता हूं "यदि आप पाते हैं कि आप बहुत अधिक सोच रहे हैं, तो रुकें और करें। यदि आप पाते हैं कि आप बहुत अधिक कर रहे हैं, तो रुकें और सोचें।"

— नील एन

यह अच्छा है, लेकिन कितना बहुत अधिक है?

— हामिश ग्रुबीजन

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

— इवान प्लाइस

Answer 17

डेटासेट का उपयोग व्यावसायिक तर्क करने के लिए। यह कोड को डेटाबेस में बहुत कसकर बांधता है, साथ ही डेटासेट आमतौर पर SQL से बनाया जाता है जो चीजों को और भी नाजुक बना देता है। यदि SQL या डेटाबेस इसे बदल देता है तो DataSet स्पर्श करने वाली हर चीज़ से छेड़छाड़ करता है।

ऑब्जेक्ट कंस्ट्रक्टर के अंदर किसी भी व्यावसायिक तर्क का प्रदर्शन करना। वंशानुक्रम के साथ और अतिभारित निर्माणकर्ताओं को बनाने की क्षमता रखरखाव को कठिन बना देती है।

Answer 18

संक्षिप्त चर / विधि / तालिका / ... नाम

मैं यह सब उस समय करता था, तब भी जब नाम की लंबाई पर कोई लागू सीमा वाली भाषाओं में काम करना (अच्छी तरह से वे शायद 255 या कुछ और थे)। साइड-इफेक्ट्स में से एक कोड (गैर-मानक) संक्षिप्ताक्षरों को समझाने वाले कोड में बहुत सारी टिप्पणियां थीं। और हां, अगर किन्हीं कारणों से नाम बदल दिए गए ...

अब मैं उन चीजों को कॉल करना पसंद करता हूं जो वे वास्तव में हैं, अच्छे वर्णनात्मक नामों के साथ। केवल मानक संक्षिप्तीकरण सहित । बेकार टिप्पणियों को शामिल करने की आवश्यकता नहीं है, और कोड कहीं अधिक पठनीय और समझने योग्य है।

Comments

हाँ, इन प्रकार की घोषणाओं को पसंद करेंगे: शून्य फू (X1, y, x2, y2, p, r, j) ... WTF ?!

— एड एस।

या इससे भी बदतर (और हाँ, मैंने वास्तव में इसे देखा है), Foo(int arg0, String arg1, float arg2)आदि

— मैक 3

Answer 19

सहायक डेटा लाइब्रेरी की तरह मौजूदा डेटा एक्सेस घटकों को रैप करना, सहायक विधियों की एक कस्टम परत के साथ।

• यह किसी के जीवन को आसान नहीं बनाता है
• इसका अधिक कोड जिसमें बग हो सकते हैं
• बहुत सारे लोग EntLib डेटा एक्सेस घटकों का उपयोग करना जानते हैं। कोई भी नहीं, लेकिन स्थानीय टीम हाउस डेटा एक्सेस समाधान का उपयोग करना जानती है

Answer 20

मैंने पहली बार 1984 में स्मॉलटाक के बारे में पढ़ते हुए ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के बारे में सुना था, लेकिन जब तक मैंने 1992 में cfront C ++ कंपाइलर का उपयोग नहीं किया, तब तक मेरे पास एक ओओ भाषा तक पहुंच नहीं थी। मुझे अंततः 1995 में स्मॉलटाक का उपयोग करने के लिए मिला। मुझे बहुत उम्मीद थी कि ओओ प्रौद्योगिकी, और इस विचार में खरीदा गया कि यह सॉफ्टवेयर विकास को बचाएगा।

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

मैं वास्तव में क्लोजर में कुछ काम करने में दिलचस्पी रखता हूं जब मुझे समय मिलता है, जो ओओ सुविधाएं प्रदान नहीं करता है, हालांकि अगर मैं सही ढंग से समझता हूं तो यह जावा ऑब्जेक्ट का उपयोग कर सकता है। मैं ऐसा कुछ भी कहने के लिए तैयार नहीं हूं, जैसे कि oo मर चुका है, लेकिन व्यक्तिगत रूप से मैं वह प्रशंसक नहीं हूं जो मैं हुआ करता था।

Answer 21

C # में, _notationनिजी सदस्यों के लिए उपयोग करना। मुझे अब लगता है कि यह बदसूरत है।

मैं फिर this.notationनिजी सदस्यों के लिए बदल गया , लेकिन मैंने पाया कि मैं इसका उपयोग करने में असंगत था, इसलिए मैंने उसे भी छोड़ दिया।

Comments

मैं अभी भी _notation का उपयोग कर रहा हूं और लगता है कि यह बहुत अच्छा है।

— अर्निस लैप्सा

मुझे _notation से नफ़रत है; मैं सार्वजनिक सदस्यों के लिए इस निजीकरण का उपयोग करता हूं और निजी सदस्यों के लिए यह नामांकन।

— कैलम रोजर्स

मुझे इससे भी नफरत है। यह मुझे भ्रमित करता है :(

— Broken_Window

मैं असहमत हूं। इससे नामों को प्रबंधित करना इतना आसान हो जाता है। गुण या सार्वजनिक / आंतरिक सदस्यों के लिए PascalCase का उपयोग करें, एक संपत्ति के माध्यम से उजागर होने वाले सदस्यों के लिए _UnderscorePascalCase, और विधियों / निर्माणकर्ताओं और निजी सदस्यों में पैरामीटर नामों के लिए CamelCase। 'यह' कीवर्ड केवल तभी आवश्यक है जब आपको कक्षा के बाहर वर्तमान कक्षा के संदर्भ को पास करने की आवश्यकता होती है या आपको कक्षा के भीतर एक ऑटो-जनरेट किए गए सदस्य तक पहुंचने की आवश्यकता होती है (जैसे नाम, नियंत्रण, आदि ...)।

— इवान प्लाइस

@ इवान: मैं वही कर रहा हूं जो आप अंतिम भाग को छोड़कर वर्णन कर रहे हैं। मैं का उपयोग करते हैं thisया Meजब तरीकों और गुण बुला (सी # और VB.NET क्रमशः)। IMO, यह मेरे कोड को बाद में पढ़ने और समझने में आसान बनाता है, खासकर जब उस विशेष दायरे में चार या अधिक ऑब्जेक्ट होते हैं।

— एलेक्स Essilfie

Answer 22

मैंने कार्यान्वयन से पहले डिजाइन की अनुशंसित विधि विश्वविद्यालय द्वारा जाना बंद कर दिया। एक अराजक और जटिल प्रणाली में काम करने से मुझे रवैया बदलने के लिए मजबूर होना पड़ा।

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

कोड आपको वह नहीं लगेगा जो आपने पहले सोचा था कि यह कैसा दिखेगा। हर बार होता है :)

Answer 23

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

Comments

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

— एलेक्स

Answer 24

मैं कई तरीकों / कक्षाओं में स्थैतिक का उपयोग करूंगा क्योंकि यह अधिक संक्षिप्त था। जब मैंने परीक्षण लिखना शुरू किया तो अभ्यास बहुत जल्दी बदल गया।

Answer 25

अपवादों की जाँच की

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

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

Answer 26

इस लायक कुछ भी केवल एक विशेष भाषा में कोडित किया गया था। मेरे मामले में मेरा मानना ​​था कि सी अब तक की सबसे अच्छी भाषा थी और मेरे पास कभी भी किसी भी अन्य भाषा में कुछ भी कोड करने का कोई कारण नहीं था ... कभी भी।

मैं तब से कई अलग-अलग भाषाओं और उनके द्वारा प्रदान किए जाने वाले लाभों / कार्यक्षमता की सराहना करता आया हूं। अगर मैं कुछ छोटा - जल्दी - जल्दी करना चाहता हूं - तो मैं पायथन का उपयोग करूंगा। अगर मैं किसी बड़े प्रोजेक्ट पर काम करना चाहता हूं तो मैं C ++ या C # में कोड करूंगा। अगर मुझे ब्रेन ट्यूमर विकसित करना है तो मैं पर्ल में कोड करूंगा ।

Answer 27

जब मुझे कुछ रीफैक्टरिंग करने की जरूरत पड़ी, तो मुझे लगा कि सीधे काम शुरू करने और नए डिजाइन को लागू करने के लिए कनेक्शन को ठीक करने तक यह तेज और क्लीनर है। तब मैंने महसूस किया कि नए डिजाइन की दिशा में धीरे-धीरे लेकिन मज़बूती से आगे बढ़ने के लिए छोटे रिफ्लेक्टरिंग की एक श्रृंखला करना बेहतर है।

Comments

याद कर सकते हैं कि यह कितनी बार मेरे पास है ....

— प्रीत संघ

Answer 28

शायद सबसे बड़ी बात जो मेरी कोडिंग प्रथाओं में बदल गई है, साथ ही साथ दूसरों में, अनुप्रयोगों से व्यवहार और कार्यक्षमता के आधार के रूप में इंटरनेट से डाउनलोड की गई बाहरी कक्षाओं और पुस्तकालयों की स्वीकृति है। जिस समय मैंने कॉलेज में भाग लिया उस समय स्कूल में हमें यह पता लगाने के लिए प्रोत्साहित किया गया था कि कैसे अपने कोड के माध्यम से चीजों को बेहतर बनाया जाए और हमारी समस्याओं को हल करने के लिए भाषा पर भरोसा किया जाए। उपयोगकर्ता इंटरफ़ेस और सेवा / डेटा खपत के सभी पहलुओं में प्रगति के साथ यह अब एक यथार्थवादी धारणा नहीं है।

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

Answer 29

सभी वर्ग के सदस्यों को प्रारंभ करना।

मैं हर वर्ग के सदस्य को स्पष्ट रूप से कुछ के साथ प्रारंभिक रूप से शुरू करने के लिए इस्तेमाल करता था, आमतौर पर NULL। मुझे पता चला है कि यह:

• आम तौर पर इसका मतलब है कि हर चर को पढ़ने से पहले दो बार प्रारंभिक किया जाता है
• मूर्खतापूर्ण है क्योंकि अधिकांश भाषाओं में स्वचालित रूप से NULL के लिए चर को इनिशियलाइज़ किया जाता है।
• वास्तव में अधिकांश भाषाओं में एक मामूली प्रदर्शन को लागू करता है
• बड़ी परियोजनाओं पर कोड ब्लोट कर सकते हैं

Comments

कभी-कभी सभी वर्ग के सदस्यों को शुरू न करने के परिणाम वास्तव में आपको $ $ में काट सकते हैं।

— मूसबुल्ला

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

— वोज्श बेडरस्की

Answer 30

आपकी तरह, मैंने भी अपने ऐप्स के विभिन्न घटकों के बीच युग्मन को कम करने में IoC पैटर्न अपनाया है। यह रखरखाव और पार्ट्स-स्वैपिंग को बहुत सरल बनाता है, जब तक मैं प्रत्येक घटक को यथासंभव स्वतंत्र रख सकता हूं। मैं डेटाबेस प्रबंधन कार्यों को आसान बनाने के लिए NHibernate जैसे अधिक ऑब्जेक्ट-रिलेशनल फ्रेमवर्क का उपयोग कर रहा हूं।

संक्षेप में, मैं "मिनी" फ्रेमवर्क का उपयोग कर रहा हूं ताकि सॉफ्टवेयर का निर्माण जल्दी और कुशलता से किया जा सके। ये मिनी फ्रेमवर्क बहुत समय बचाते हैं, और यदि सही किया जाता है तो सड़क को बनाए रखने के लिए एक आवेदन को सुपर सरल बना सकते हैं। जीत के लिए प्लग एन खेलें!

Comments

-1 मैं IoC और चौखटे के प्रसार को बर्दाश्त नहीं कर सकता। घटिया, IoC और चौखटे = अनावश्यक जटिलता

— पॉल होलिंग्सवर्थ

आप डिकॉकिंग की प्रशंसा कैसे कर सकते हैं और अभी भी आईओसी और अन्य रूपरेखाओं से नफरत करते हैं? यही कारण है कि कई IoC चौखटे और डिजाइन पैटर्न के साथ शुरू करने के लिए करते हैं।

— अंजड़ 987