भाषा X में कुछ लिखना क्यों बुरा है जैसे कि आप एक साझा कोडिंग प्रतिमान का उपयोग करने के संदर्भ में भाषा Y में एक कार्यक्रम लिख रहे हैं [बंद]

Question

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

इसने मुझे आश्चर्यचकित कर दिया कि लोग इस तरह की हार्ड लाइन को क्यों अपनाते हैं "तुम एक नोब हो जाओ, अपने आप को बकवास करो" रवैया। मुझ पर C ++ लिखने का आरोप लगाया जा रहा था मानो यह जावा हो। कुछ ऐसा जो मुझे समझ नहीं आ रहा है, और वह अभी भी मुझे चकित करता है।

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

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

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

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

[संपादित करें] मैं स्पष्ट करना चाहूंगा कि gnat का सुझाव [१] उस खोज में नहीं दिखा, जो मैंने अपना प्रश्न पूछने से पहले किया था। हालाँकि, उनका सुझाव प्रश्न के एक पहलू को कवर करता है, लेकिन वह जिस प्रश्न से जुड़ा है, वह मेरे प्रश्न का उत्तर नहीं देता है, बस इसका हिस्सा है। मेरा प्रश्न मेरी कोडिंग शैली और विभिन्न कोडिंग शैलियों और कौशल के (स्पष्ट) स्तरों को संभालने के पेशेवर पहलुओं को मिली प्रतिक्रिया के बारे में अधिक है। SO पर मेरे पिछले प्रश्न के साथ और यह एक बिंदु के रूप में प्रतिक्रिया है। [/ संपादित करें]

फिर सवाल यह है: किसी ऐसे व्यक्ति का उपहास क्यों करें जो आपकी कोडिंग शैली का उपयोग नहीं करता है?

मेरे लिए मामले / उपखंड निम्नलिखित हैं:

• प्रोटोटाइप स्थितियों में अधिक त्रुटि प्रवण कोड का उपयोग करने के लिए यह एक बुरा प्रोग्रामिंग अभ्यास क्यों होगा, यदि रीफैक्टरिंग इसके बाद अधिक मजबूत बनाता है?
• C ++ में लिखा गया प्रोग्राम कैसा होगा जैसा कि जावा में लिखा गया था? यह एक बुरा कार्यक्रम क्या है, (यह देखते हुए कि मैंने वर्तमान शैली के इरादे और सुधार के लिए नियोजित कार्य का संकेत दिया है?)
• यदि मैं एक निश्चित प्रोग्रामिंग प्रतिमान (जैसे OOP / DP) में उपयोग किए जाने वाले निर्माण का उपयोग करने के लिए चुना तो मैं एक बुरा पेशेवर कैसे होगा?

[१] तेज़ और छोटी गाड़ी विकसित करें, फिर त्रुटियों को ठीक करें या कोड की प्रत्येक पंक्ति के लिए धीमी गति से सावधान रहें?

Comments

आप इस सवाल को C ++ लाउंज में लोगों से पूछना बेहतर समझ सकते हैं। पहले अपने लौ प्रूफ सूट पर रखो।

— रॉबर्ट हार्वे

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

— रॉबर्ट हार्वे

हो सकता है कि यह वही प्रतिक्रिया हो जो आपके पास जावा कोड की होगी जो कि FORTRAN की तरह लिखी गई थी: एक ही वर्ग में सभी कोड, कोई संग्रह नहीं, केवल निश्चित-आकार के सरणियाँ, अलग-अलग intचर के साथ वास्तविक लंबाई का ट्रैक रखने के लिए।

— केविन क्लाइन

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

— रोबोट

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

— जेएफओ

Answer 1

कोड को प्रश्न में देखे बिना, सी ++ में जावा कोड लिखने के कुछ तरीके हैं, कुछ दूसरों की तुलना में खराब हैं।

1. एक चरम पर, जावा जैसे अपने स्रोत को बाहर रखना: एक फ़ाइल में सब कुछ, वर्ग परिभाषा के भीतर सब कुछ, आदि।:

   class HelloWorldApp {
   public:
       void main() {
           cout << "Hello World!" << endl;
       }
   };

   इस तरह से जावा स्रोत को रखा जाएगा। यह C ++ में तकनीकी रूप से कानूनी है, लेकिन हेडर फ़ाइल और सब कुछ इनलाइन में डालकर (वर्ग घोषणा में इसे परिभाषित करके) भयानक शैली है और यह आपके संकलित प्रदर्शन को मार देगा। यह मत करो।
2. अत्यधिक ओओ - जावा में ओवरसिम्पलीफाई करने के लिए, यह किंगडम ऑफ द नाउन्स है , जहां सब कुछ एक वस्तु है। सब कुछ एक वस्तु में रटना करने की कोशिश करने के बजाय अच्छे (यानी, मुहावरेदार) सी ++ कोड का उपयोग नि: शुल्क कार्यों, टेम्पलेट्स, आदि की अधिक संभावना है।
3. कोई RAII - आपने पहले ही इसका उल्लेख किया है - स्मार्ट पॉइंटर्स के बजाय पॉइंटर्स और मैनुअल क्लीनअप का उपयोग करना। C ++ आपको RAII और स्मार्ट पॉइंटर्स जैसे टूल देता है, इसलिए अच्छा (यानी, मुहावरेदार) C ++ कोड उन टूल्स का उपयोग करता है।
4. कोई उन्नत सी ++ - जावा और सी ++ की मूल बातें समान नहीं हैं, लेकिन एक बार जब आप अधिक उन्नत सुविधाओं (टेम्पलेट, सी ++ के एल्गोरिदम लाइब्रेरी, आदि) में पहुंच जाते हैं, तो वे विचलन करना शुरू कर देते हैं।

# 1 को छोड़कर, इनमें से कोई भी C ++ प्रोग्राम को खराब प्रोग्राम नहीं बनाता है, लेकिन यह उस तरह का कोड भी नहीं है जिसे मैं C ++ प्रोग्रामर के रूप में काम करना पसंद करता हूं। (मुझे गैर-मुहावरेदार या सी-स्टाइल पर्ल, गैर-मुहावरेदार पायथन, आदि के साथ काम करने में भी मज़ा नहीं आएगा) एक भाषा के अपने उपकरण और मुहावरे और दर्शन होते हैं, और अच्छा कोड उन उपकरणों और मुहावरों का उपयोग करने के बजाय उपयोग करने की कोशिश करता है। सबसे कम आम भाजक या किसी अन्य भाषा के दृष्टिकोण को पुन: पेश करने की कोशिश करना। किसी विशेष भाषा / समस्या डोमेन में गैर-मुहावरेदार कोड लिखना / जो किसी को एक बुरा प्रोग्रामर नहीं बनाता है, इसका मतलब सिर्फ इतना है कि उन्हें उस भाषा / समस्या डोमेन / जो कुछ भी सीखना है। और इसमें कुछ भी गलत नहीं है; उन चीजों की एक बहुत लंबी सूची है जिनके बारे में मुझे और सीखना है, और विशेष रूप से C ++ में सीखने के लिए एक पूर्ण टन सामान है।

बाद में इसे साफ करने के इरादे से त्रुटि-प्रवण कोड लिखने के विशेष प्रश्न के बारे में, यह काला और सफेद नहीं है:

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

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

Comments

मुहावरेदार पर्ल है?

— शाफ़्ट फ्राक

@ जब आप पूछते हैं कि "मैं दीवार पर इस पेंच को कैसे झुका सकता हूं बिना इसे झुके ?" हर कोई आपको बताएगा कि हथौड़ा का उपयोग न करें।

— सोज़ेरड

@Onno C ++ में, पॉइंटर्स और पावरटूल माने newजाते हैं। स्वचालित भंडारण हैंडटूल है।

— सोजेरड

@ ओनो: आपको यह महसूस करना होगा कि सी ++ प्रोग्रामिंग पाठ्यक्रम आधुनिक मुहावरों को अपनाने में पिछड़ जाते हैं और जिसे अच्छा माना जाता है सी + + भी काफी विकसित हो गया है क्योंकि सी ++ का आविष्कार किया गया था।

— बार्ट वैन इनगेन शेनॉ

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

— रोबोट

Answer 2

प्रत्येक प्रोग्रामिंग भाषा में मुहावरों और सर्वोत्तम प्रथाओं का एक सेट होता है, जो आमतौर पर सुरुचिपूर्ण, सही और प्रदर्शनकारी कोड का नेतृत्व करेगा। यहां कुछ सबसे खराब प्रथाएं हैं जो किसी अन्य भाषा में पूरी तरह से ठीक हैं:

• यदि आप for ($i = 0; $i < 42; $i++) { … }पर्ल में लिखते हैं , तो मैं चिल्लाऊंगा, लेकिन PHP में नहीं
  (पर्ल में, चर घोषित किए जाने चाहिए, और इस तरह के छोरों को एक सीमा से अधिक चलना चाहिए)
• अगर आप new Foo()बिना अच्छे कारण के C ++ में लिखते हैं , तो मैं रोऊंगा , लेकिन जावा में नहीं
  (C ++ में कचरा संग्रह नहीं है, इसलिए RAII का उपयोग किया जाना चाहिए। Noobs मेमोरी को लीक कर देगा अन्यथा)
• यदि आप C89, पास्कल, या जावास्क्रिप्ट को छोड़कर, अपने फ़ंक्शन के शीर्ष पर अपने सभी चर घोषित करते हैं, तो मैं उखड़ जाऊंगा।
• यदि आप अपने सभी कार्यों को पायथन में एक कक्षा में रखते हैं, तो मैं सामना करूंगा, लेकिन जावा में नहीं
  (पायथन "OOP" और शीर्ष स्तर पर कार्यों का समर्थन करने के बजाय एक बहु-प्रतिमान भाषा है)
• मैं रोऊंगा अगर तुम return null स्काला में हैं , लेकिन सी-
  लाइक भाषा में नहीं (क्योंकि स्काला का एक Optionप्रकार है)
• यदि आप जावा में एक पुनरावर्ती एल्गोरिथ्म लिखते हैं, तो मैं शिकायत करूंगा, लेकिन ओकेएमएल में नहीं
  (क्योंकि जावा का स्टैक ओवरफ्लो होता है, जबकि ओकेमेल में टेल कॉल ऑप्टिमाइज़ेशन है)
• ...

एक नई भाषा का उपयोग करना आसान है जैसे कि यह कुछ ऐसा था जिसे आप जानते हैं, और भाग्य के साथ भी काम करेगा। "आप किसी भी भाषा में फोरट्रान लिख सकते हैं"। लेकिन आप वास्तव में विशिष्ट सुविधाओं भाषा X ऑफ़र को अनदेखा नहीं करना चाहते हैं, क्योंकि संभावना अच्छी है कि X, U पर कुछ लाभ प्रदान करता है।

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

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

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

यह कहना बहुत सस्ता है कि "मैं इसे बाद में ठीक करूँगा", इसे ठीक करते समय अब ​​आपकी समस्या हल हो जाएगी (यह भी, कि "क्लीन-अप फेज़" कभी नहीं आ सकता है, इसलिए इसे करने का एकमात्र जिम्मेदार विकल्प है पहली बार)। बहुत कम से कम, दूसरों से मदद मांगने से पहले अपने कोड को यथासंभव बेहतर बनाने की कोशिश करना उनके लिए आपके कोड के बारे में तर्क करना आसान बनाता है, इसलिए विनम्र बात करना है।

Comments

आपके द्वारा किए गए कुछ बिंदुओं पर आप काफी सही हैं, लेकिन अंत में मुझे नहीं लगता कि आप निशान मार रहे हैं। आप अनुभव प्राप्त करने से पहले ज्ञान की प्राप्ति मान रहे हैं जो ज्ञान प्राप्त करेगा।

— ओनो

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

— आमोन

लेकिन जिस सवाल पर आप इशारा कर रहे हैं, उसके बारे में: jm666 के जवाब में एक महत्वपूर्ण बिंदु शामिल है: गुरु को लगता है कि "आप एक्स के बारे में क्यों पूछेंगे यदि आप खुद एक्स-गुरु नहीं बनना चाहते हैं?" । डिफ्यूज करने का एक संभावित तरीका यह है कि आप अभी भी लर्निंग कर्व की शुरुआत में हैं और बाद में उस पर गौर करेंगे, लेकिन अभी के लिए यह तत्काल प्रश्न है। हालाँकि, यह एक संचार समस्या है, प्रोग्रामिंग समस्या नहीं है।

— आमोन

दोनों सी ++ और सी # है optional<T>और Nullable<T>क्रमशः। इसके अलावा, व्यावहारिक रूप से हर कोई C ++ में मेमोरी को RAII, noob या नहीं के बिना लीक करता है।

— डेडएमजी

मुझे लगता है कि एक ब्लॉक की शुरुआत में चर घोषित करना आमतौर पर आपके कोड को अधिकांश भाषाओं में पढ़ने में आसान बनाता है। इस तरह से आपको पता है कि आपको कहाँ देखना है जब आपको यह याद रखने में सहायता की आवश्यकता होती है कि आपके सभी प्रकार कौन से हैं और ऐसे हैं।

— स्वाद

Answer 3

मैं कट्टर C ++ डेवलपर नहीं हूं, लेकिन ...

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

एक बात का ध्यान रखें कि C ++ में त्रुटि का मतलब आमतौर पर "अपरिभाषित व्यवहार" होता है। एक सुरक्षित भाषा में जो सबसे खराब हो सकता है वह है आपके कार्यक्रम को तुरंत समाप्त करना एक अपवाद। C ++ में, यदि आप एक segfault प्राप्त करते हैं तो आप भाग्यशाली हैं। यह पूरी तरह से संभव है कि आपका कार्यक्रम सूक्ष्म रूप से कुछ गलत करता रहे। यह समय की अवधि के लिए सही ढंग से व्यवहार कर सकता है और बग्स को बहुत बाद में प्रकट कर सकता है, या यह हर समय सही ढंग से व्यवहार कर सकता है, लेकिन अंततः सभी मेमोरी को खा सकता है।

किसी भी मामले में, केवल रेल निष्पादन को पूरी तरह से रेल से और अनचाहे क्षेत्र में ले जाने के लिए एक ही गलती होती है। यह संभावना है कि पूर्णकालिक सी ++ डेवलपर के लिए, "बेस केस" का अर्थ है "अपरिभाषित व्यवहार या मेमोरी डिस्क की कोई संभावना नहीं।"

C ++ में लिखा गया प्रोग्राम कैसा होगा जैसा कि जावा में लिखा गया था? क्या यह एक बुरा कार्यक्रम बनाता है?

मुझे नहीं लगता कि इसका कोई जवाब है जो मोटे तौर पर अटकलबाजी और राय नहीं होगी। यदि आप चाहते हैं कि मेरा इस पर कब्जा हो जाए, तो जावा में एंटीपैर्टर्न के एक जोड़े को इस तथ्य से जोड़ा जाता है कि सब कुछ एक वस्तु होना चाहिए। कहाँ अन्य भाषाओं में आप एक सूचक, functor, या समारोह दे देते हैं, जावा में आप आमतौर पर असार और सूक्ष्म रूप से उपयोगी टन पाते हैं ThingDoers, FooFactoriesऔर IFrobnicatorsजो भेष में सिर्फ कार्य हैं।

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

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

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

Comments

इसमें से अधिकांश जावा 8 के साथ समाप्त हो गया है - लम्बदास सवारी करने के लिए ज्यादातर दिन बचाते हैं :-)

— मार्टिजेन वेरबर्ग

@MartijnVerburg सहमत है, वहाँ बहुत बड़ा कदम है। लेकिन तकनीकी समस्याओं को ठीक करने के लिए आसान कर रहे हैं! पुरानी आदतें कठिन हो जाती हैं और कलंक भी कठिन हो जाते हैं। हेक, कुछ लोग इतनी दूर तक जाएंगे कि शिकायत करने के लिए जावा को इन "नई" विशेषताओं में से किसी की आवश्यकता नहीं है, और यह कि अगले सी ++ बनने का मार्ग है।

— डोभाल

हाँ, मैं हमेशा उस पर अपना सिर हिलाता हूँ - जावा जानबूझकर हमेशा अन्य भाषाओं की तुलना में अधिक धीरे-धीरे विकसित होगा क्योंकि यह एक दीर्घकालिक वर्कहॉर्स है। जेवीएम हालांकि कुछ हद तक तेजी से आगे बढ़ सकता है, जो लैम्बडा जैसी चीजों को अंततः भाषा में आने में सक्षम बनाता है।

— मार्टिनेज वर्बर्ग

Answer 4

विषय उत्तर से थोड़ा हटकर ...

चिंता न करें - यह किसी भी विशेषज्ञ समुदाय में एक सामान्य "व्यवहार" है। और ईमानदार रहें, यदि आप किसी भी भाषा में अच्छे हैं, और आपको एक कोड मिलेगा जो "अजीब" है, तो शायद आप भी इसकी आलोचना करेंगे। (क्योंकि, TEACH चाहते हैं)।

मैं पर्ल-वर्ल्ड में हूँ - जब कुछ ऐसा देखूंगा:

$imax=$#array;
$str=""
for($i=0; $i<$imax; $i++) {
    $str = "$str" . $array[$i];
}

के बजाय:

my $str = join '', @array;

यकीन है कि यह टिप्पणी करेंगे - (पढ़ें: लेखक को पढ़िए) joinफ़ंक्शन के बारे में ।

वैसे भी, बहुत अधिक आलोचना बिल्कुल उल्टा है, और सबसे अच्छा उदाहरण में से एक अगला है: (से पकड़ा गया: http://perl-begin.org/humour/#How_can_I_switch_off_the_T.V..3F )

(इस बिट को 23 मार्च, 2011 को एक पेस्टबोट में गुमनाम रूप से पोस्ट किया गया था। इसे कुछ संपादन के बाद पोस्टरिटी के लिए यहां रखा गया है।) - थोड़ा संपादित भी किया गया।

प्रश्न: मैं अपने टीवी पर कैसे स्विच कर सकता हूं?

ओपी क्या सुनना चाहता है?

उदाहरण के लिए: अपने टीवी रिमोट को एक बटन दबाकर ऑन / ऑफ करें। बटन आमतौर पर लाल होता है और रिमोट पर सबसे ऊपरी रेखा पर स्थित होता है।

# विशेषज्ञ का जवाब: पहला, "स्विच ऑन" से आपका क्या मतलब है? इसे पहले परिभाषित करें। अपने टीवी, टीवी के रिमोट और लिविंग रूम को भी नस्ट करें।

... एक नृप के बाद:

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

http://experts.blog/how_to_design_a_future_3D_TV.html http://experts.blog/the_basics_of_tv_repairing.html http: //experts.blog_viruses_in_living_room_short_essay.html http://experts.blog/chlobal/chlobal/

IRC अतिथि: लेकिन, मैं टीवी विशेषज्ञ नहीं बनना चाहता।

उत्तर: फिर आप टीवी को क्यों स्विच करना चाहते हैं ?!

Comments

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

— ट्राइकोप्लेक्स

Answer 5

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

फिक्सिंग के दिमाग के साथ जल्दी और गंदे लिखने पर बाद में कुछ ऐसा भूलने का खतरा होता है जिसे आपको ठीक करने की आवश्यकता होती है।

C ++ में लिखा गया प्रोग्राम कैसा होगा जैसा कि जावा में लिखा गया था? यह एक बुरा कार्यक्रम क्या है, (यह देखते हुए कि मैंने वर्तमान शैली के इरादे और सुधार के लिए नियोजित कार्य का संकेत दिया है?)

जावा में आपको यह सोचने की ज़रूरत नहीं है कि एक निश्चित वस्तु का मालिक कौन है, आप बस संदर्भ को पास करते हैं और इसके बारे में भूल जाते हैं जैसे कि यह कुछ भी नहीं है। हालांकि C ++ में इस बात की स्पष्ट परिभाषा होनी चाहिए कि कौन वस्तु का मालिक है और कौन इसे साफ करने के लिए जिम्मेदार है।

यदि मैं एक निश्चित प्रोग्रामिंग प्रतिमान (जैसे OOP / DP) में उपयोग किए जाने वाले निर्माण का उपयोग करने के लिए चुना तो मैं एक बुरा पेशेवर कैसे होऊंगा

आप नहीं करेंगे; C ++ एक बहु-प्रतिमान भाषा है, यह OOP को अच्छी तरह से समर्थन करने के लिए होता है, लेकिन यह बहुत सारे अन्य काम भी कर सकता है। हालाँकि, इसमें से अधिकांश को हर बार जब आप किसी लकड़ी में नुकीले कील को चलाने की आवश्यकता होती है, तो हथौड़े को बाहर निकालने के बजाय काम के लिए सही उपकरण का उपयोग करने के लिए उबलते हैं।

आपके द्वारा गलत प्रतिक्रिया दिए जाने का कारण यह है कि SO पर अधिकांश लोग कौशल को आंकते हैं कि आप जिस भाषा के बारे में पूछ रहे हैं उस भाषा में कैसे मुहावरेदार हो सकते हैं। C ++ से परिचित लोग घुटने मोड़ने की प्रवृत्ति रखते हैं, जब उन्हें बुरा कोड दिखाई देता है जो कुछ ऐसा दिखता है जो उन्हें अतीत में काट चुका होता है।

Comments

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

— ओन्नो

@ ओनो: सच में, किसी को भी नहीं पता या परवाह नहीं है कि आप व्यक्तिगत रूप से उस सामान को ट्रैक करने में कितने अच्छे हैं। अधिकांश लोग जो C ++ लिखते हैं, जो जावा या सी की तरह दिखता है, लगभग इतने सावधानीपूर्वक भी नहीं हैं। उनके लिए यह बेहतर है कि वे पहली बार सामान बनाना सीखें, खुद को वापस लिखने और बाद में इसे ठीक करने के लिए नोट करें, क्योंकि अनुभव से पता चलता है कि वे वास्तव में कभी ऐसा नहीं करते हैं।

— cHao