आपके द्वारा उपयोग की जाने वाली आईडीई से C # विकास प्रभावी रूप से अविभाज्य है?


41

मैं एक पायथन प्रोग्रामर हूं, जो C # को सीख रहा है, जो चिंता करना बंद करने की कोशिश कर रहा है और सिर्फ C # से प्यार करता है, बजाय इसके कि वह लगातार पायथन से तुलना कर रहा है।

मैं एक बिंदु पर पकड़ा गया हूं: इस स्टैक ओवरफ्लो प्रश्न में जहां चीजें परिभाषित की गई हैं, वहां के बारे में खोजकर्ता की कमी । संक्षेप में: C # में, आपको using fooयह नहीं बताता कि कौन से नाम fooउपलब्ध कराए जा रहे हैं, जो कि from foo import *Python के अनुरूप है - एक ऐसा रूप जिसे Python कोडिंग कल्चर के भीतर हतोत्साहित करने के बजाय अधिक स्पष्ट दृष्टिकोण के लिए निहित किया गया है from foo import bar

मैं सी # प्रोग्रामरों से इस बिंदु पर स्टैक ओवरफ्लो के जवाबों के बजाय मारा गया था, जो यह था कि व्यवहार में इस गवाह की कमी वास्तव में मायने नहीं रखती है क्योंकि आपके आईडीई (संभवतः विजुअल स्टूडियो) में आप सिर्फ एक नाम पर हॉवर कर सकते हैं और इसके द्वारा कहा जा सकता है सिस्टम जहां से नाम आ रहा है। उदाहरण के लिए:

अब, सिद्धांत रूप में मुझे इसका मतलब यह है कि जब आप एक टेक्स्ट एडिटर के साथ देख रहे हैं, तो आप यह नहीं बता सकते कि C # ... में टाइप कहां से आते हैं, लेकिन व्यवहार में, मुझे यह समस्या नहीं लगती। आप वास्तव में कितनी बार कोड देख रहे हैं और विज़ुअल स्टूडियो का उपयोग नहीं कर सकते हैं?

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

जो मुझे यहाँ मेरे प्रश्न की ओर ले जाता है: C # विकास आपके द्वारा उपयोग की जाने वाली IDE से प्रभावी रूप से अविभाज्य है?


7
पायथन एक गतिशील भाषा है, C # स्टेटिकली टाइप (जावा की तरह), इसलिए आप या तो कोड में बहुत भिन्न हैं।
ओड

6
@Oded using MyType = MyNamespace.MyType;:?
पीडीआर

4
मुझे नहीं पता कि यह पायथन में कैसा है, लेकिन C # में आप हमेशा शुरुआत कर सकते हैं global::और वहां से अपना काम कर सकते हैं । usingऐसा कुछ भी उपलब्ध नहीं करता जो पहले नहीं था; यह केवल उपयोग करना आसान बनाता है (जैसा कि किसी विशेष वर्ग का उपयोग करने के लिए आवश्यक कम टाइपिंग में)।
बजे एक CVn

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

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

जवाबों:


26

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

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

आपके द्वारा उपयोग किए गए आईडीई से C # विकास प्रभावी रूप से अविभाज्य है?

सैद्धांतिक रूप से नहीं, लेकिन व्यावहारिक रूप से हाँ। पाठ संपादक और कमांड लाइन का उपयोग करके C # में लिखना संभव है, लेकिन यदि आपके पास Visual Studio है, तो आप ऐसा कभी नहीं करेंगे। वास्तव में बहुत कम प्रोग्रामर ने कभी कमांड लाइन से C # कोड निष्पादित किया है।

BTW यदि आप के साथ असुविधाजनक महसूस करते हैं using foo, तो आप एक प्रकार का उपयोग करते समय पूरे पथ का उपयोग कर सकते हैं।


9
SharpDevelop और MonoDevelop विज़ुअल स्टूडियो के लिए वैकल्पिक IDE हैं।
Oded

@ ठीक है, मैंने कभी भी उनका उपयोग नहीं किया है लेकिन एक नज़र रखना दिलचस्प है। धन्यवाद))
सुपर

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

2
@ Ghopper21: मैं यह सुझाव दूंगा कि यह एक्सेलीज की तुलना ग्रहण से अधिक है (विशेषकर जब आप रेस्पर को शामिल करते हैं), इसके अलावा, .NET की दुनिया में, आम तौर पर विजुअल स्टूडियो के लिए कम्युनिटी प्लगइन्स लिखे जाते हैं।
पीडीआर

5
+1: मैं सहमत हूं, जब आप नोटपैड के साथ कमांड लाइन पर कोड लिख सकते हैं, तो आप उस टूलिंग को अनदेखा करने के लिए एक बेवकूफ होंगे जो वीएस या तीव्र विकास तालिका में लाता है।
बाइनरी वॉरियर

33

इस तरह के बुनियादी स्तर पर कोड को समझने के लिए एक IDE पर निर्भर होने का विचार ही बहुत अच्छा लगता है।

यह आपके कोड को समझने का सवाल नहीं है : पर्याप्त समय दिए जाने पर, आप हमेशा मूल पाठ संपादक के साथ या यहां तक ​​कि प्रिंटआउट में भी सही चर का पता लगा सकते हैं। जहां तक ​​कोड को समझने की बात है, आईडीई निर्भरता बिल्कुल मौजूद नहीं है।

आपके संदर्भों को कुशलतापूर्वक पता लगाना एक पूरी तरह से अलग विषय है: मुझे ग्रहण में जावा चर के usages को खोजने की क्षमता से उतना ही प्यार है, जितना कि मुझे C # और C ++ दोनों के लिए Visual Studio में घोषणा अंक मिलना पसंद है। मैं मैन्युअल रूप से घोषणा बिंदुओं की तलाश करने के बजाय अपना समय कोडिंग खर्च करना पसंद करता हूं। यह गणित करने के समान है: मैं कागज के एक टुकड़े पर संख्याओं को गुणा कर सकता हूं, लेकिन मैं अपने आप को एक या दो मिनट बचाने के लिए कैलकुलेटर का उपयोग करना पसंद करता हूं।

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

चालें आपको उस महत्वपूर्ण आकार को बढ़ाने देती हैं जहां आईडीई उपयोगी हो जाता है। उदाहरण के लिए, आप एक नामकरण सम्मेलन का अनुसरण कर सकते हैं (कुछ बिंदुओं पर विशेष रूप से विंडोज चिकित्सकों के बीच हंगेरियन नाम सी ++ दुनिया में बड़े थे)। एक और आम चाल है this.संदर्भ उदाहरण चर के साथ भी संदर्भों में जहां ऐसी योग्यता की आवश्यकता नहीं है।

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


1
मुझे शायद "जल्दी से पढ़ा कोड" कहा जाना चाहिए था ... यह मेरे लिए काफी मानसिक बदलाव है कि सभी संदर्भ एक ही स्रोत फ़ाइल में नहीं हैं, और इसके बजाय उन संदर्भों का पता लगाने के लिए उपकरणों का उपयोग करें।
गॉपर

5
ऐसा नहीं है कि मैं thisidiosyncratically का उपयोग करने का चयन नहीं कर सकता - लेकिन कोडिंग एक अलग कला नहीं है और मुझे लगता है कि कोडिंग संस्कृति के मानदंडों का पालन करना (या कम से कम शुरू करना) सबसे अच्छा है - अर्थात पायथन के साथ "पायथन" और जो भी समतुल्य "C # तरीका" C # के साथ है। और यह यहाँ के उत्तरों और टिप्पणियों से स्पष्ट है कि विज़ुअल स्टूडियो की तरह एक अच्छी IDE का उपयोग करना "C # रास्ता" के लिए केंद्रीय है (यदि इसे लगाने का सही तरीका है)।
गॉपर

3
@ Ghopper21 थिंग आप C # के साथ चलेंगे, ऐसा नहीं है कि आप इसे बिना IDE के नहीं लिख सकते, लेकिन यह कि C # कोड का अधिकांश भाग एक IDE में लिखा गया था और सभी डेवलपर उस IDE का उपयोग करते हैं। इस तथ्य को इंटेलीसेन्स के साथ जोड़कर डेवलपर्स गूगल मेमोरी के जाल में पड़ जाते हैं क्योंकि अध्ययनों ने huffingtonpost.com/2011/07/15/… के बारे में बात की है "अध्ययन के निष्कर्षों के अनुसार, Google के बड़े वेब इंडेक्स तक पहुंच वाले लोगों की संभावना कम है एक तथ्य को याद रखें जब संकेत दिया जाता है, हालांकि, उन्हें याद है कि उस तथ्य को ऑनलाइन कहां और कैसे पता लगाया जाए "
जिमी हॉफ

2
@ Ghopper21 मैं यह नहीं कह रहा हूं कि यह मेमोरी ट्रैप खराब है , यह अधिकांश के लिए बेहद बढ़ी हुई उत्पादकता का एक स्रोत है, यही वजह है कि केवल उन दिनों की लंबी यादों के साथ जब वे पूरे एपीआई को याद कर सकते थे, जिनके बारे में उन्होंने वास्तव में शिकायत की थी। मैं इसे केवल इसलिए इंगित कर रहा हूं क्योंकि यह तथ्य सीधे आपके द्वारा पढ़े जाने वाले C # कोड और C # विकास की शैली और संस्कृति को प्रभावित करता है।
जिमी होफा

1
मैं कभी भी बायोस / लो लेवल डॉस एपीआई पर नहीं गया; लेकिन मेरी पहली भाषा / वातावरण बोरलैंड टर्बोपास्कल था; और मैं शायद एक बिंदु पर याद किया गया भाषा / मानक पुस्तकालय का ~ 90% था। ओओ के बारे में क्या होना चाहिए यह पता लगाने में प्राथमिक अपवाद पूरी तरह से विफल हो रहे थे।
डैन नीली

8

कई पायथन प्रोग्रामर्स कोडिंग के लिए एक टेक्स्ट एडिटर के दृष्टिकोण को पसंद करते हैं, कुछ उदात्त पाठ 2 या विम का उपयोग करके, जहां यह कोड, प्लस कमांड लाइन टूल और फ़ोल्डर्स और फ़ाइलों के प्रत्यक्ष उपयोग और हेरफेर के बारे में है।

यह बहुत अच्छा है, लेकिन यह वीएस आईडीई की बात को याद करता है। वीएस जैसे आईडीई का बिंदु रीफैक्टरिंग और इंटेलीसेंस जैसे मजबूत कोड टूल के माध्यम से तेजी से विकास का समर्थन है। वी.एस. एक बहुत है बहुत सी # कोड के लिए अच्छा संपादक।

अब C # आपको एक ऐसी शैली में कोड देता है जो उसकी IDE पर अधिक सीमा तक निर्भर करता है (आप बहुत सारे varकीवर्ड और जैसे उपयोग कर सकते हैं )। उदाहरण के लिए कुछ लोग अधिक स्पष्ट होना पसंद करते हैं, उदाहरण के लिए नेमस्पेस उपनामों का उपयोग करके स्पष्ट किया जाना चाहिए कि किस नाम स्थान पर एक वर्ग है (जैसे importजावा या पायथन में)। यह भाषा की विशेषता की तुलना में एक कोडिंग शैली का विकल्प है।

जैसा कि C # वैधानिक रूप से टाइप किया गया है (हालाँकि कुछ डायनेमिक एक्सटेंशन के साथ, v4 के रूप में) यह पता लगाना हमेशा काफी आसान होता है कि किस प्रकार का उल्लेख किया जा रहा है - यदि वे गलत हैं तो कोड संकलित नहीं होगा, और VS केवल IDE नहीं है C # intellisense के समर्थन के साथ। यह शायद सबसे अच्छा है, हालांकि।

एक शक्तिशाली आईडीई के बिना सी # विकसित करना (वीएस की तरह) बल्कि हाथों से नाखूनों पर हाथ फेरने जैसा है, जब आपके पास पहले से ही रेंज नेलगन का शीर्ष होता है - ऐसा करने के लिए आपको आवश्यक विषम समय हो सकता है, लेकिन पेशेवर नौकरी के लिए सही उपकरण का उपयोग करते हैं ।

मैं कहता हूं कि शायद जावा का भी यही सच है। अगर वहाँ एक शक्तिशाली IDE intellisense और कोड रिफ्लेक्टर उपकरण के साथ वहाँ आप शायद इसे इस्तेमाल किया जाना चाहिए।

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

कई प्रोग्रामर जो कोडिंग के लिए एक टेक्स्ट एडिटर के दृष्टिकोण को पसंद करते हैं, वे वैधानिक रूप से टाइप की गई भाषाओं (जैसे कि C # और Java) से अधिक लाभ प्राप्त नहीं करते हैं और इसलिए यदि पायथन और जावास्क्रिप्ट जैसे डायनेमिक लोगों से चिपके रहते हैं तो यह बेहतर हो सकता है।

मुझे लगता है:

  • डायनेमिक भाषाएं हल्के उपकरणों के लिए उपयुक्त हैं (हैवीवेट आईडीई यहां कम लाभ प्रदान करते हैं)
  • स्टेटिक भाषाएं शक्तिशाली आईडीई के लिए उपयुक्त हैं (उपकरण लचीलेपन की कीमत पर कोड के साथ मदद कर सकते हैं)

उलटे भाव के लिए +1।
fbmd

5

आपके प्रश्न का उत्तर देने के लिए: यद्यपि यह धीरे-धीरे बदल रहा है, Microsoft विकास का वातावरण काफी हद तक एक मोनोकल्चर रहा है

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


वैसे, यह तर्क दिया जा सकता है कि पायथन भी अपना स्वयं का मोनोकल्चर है, जिसे देखते हुए "पाइथोनिक" को कोडिंग शैली और दृष्टिकोण में मजबूत पालन माना जाता है, और चीजों को करने का एक स्पष्ट तरीका होने का भाषा का मुख्य डिजाइन सिद्धांत है। मुझे लगता है कि इस अर्थ में प्रोग्रामिंग मोनोकल्चर बहुत अच्छे हो सकते हैं, क्योंकि यह एक सुसंगत समुदाय और साझा करने योग्य कोड बनाता है। यह सिर्फ (बहुत बुरा है? और / या मेरे दिमाग का विस्तार करने का अवसर?) कि पायथन और सी # संस्कृतियाँ इतनी अलग हैं ... अलग हैं!
Ghopper21

2
@ Ghopper21 पायथन के बारे में बहुत अच्छी बात है। मुझे लगता है कि MS का "वहाँ एक एकल, स्पष्ट तरीका होना चाहिए" का संस्करण IDE की पसंद तक फैला हुआ है :)
डैनियल बी

4

एक के लिए, C # पायथन नहीं है .. अलग-अलग डिज़ाइन के तरीके हैं।

अब, आपके प्रश्न का उत्तर देने के लिए, बयानों का उपयोग करके अपने पायथन-एस्के का उपयोग करना पूरी तरह से संभव है।

using FooBar=MyName.Foo.FooBar; 

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

और साथ ही, C # एक ऐसी भाषा है जो आईडीई का उपयोग करने के लिए खुद को बहुत आसान बनाता है। इंटेलीजेंस को लागू करने के लिए आश्चर्यजनक रूप से सरल है, खासकर रूबी और पायथन जैसी गतिशील भाषाओं की तुलना में। हालाँकि, आपको अपने IDE से अटके नहीं रहना है। मैंने लोगों को ग्रहण का उपयोग करते हुए सुना है। वहाँ भी निश्चित रूप से MonoDevelop है (जो मैं काफी उपयोग करता हूं), और आप कमांड लाइन से भी काम कर सकते हैं। मेरे सर्वर पर कभी-कभी, मैं C # फ़ाइलों को संपादित कर रहा हूँ viऔर फिर xbuildइसका पुनर्निर्माण करने के लिए उपयोग कर रहा हूँ ... यह सिर्फ इतना है कि IDE का उपयोग करने से सामान्य मामलों के लिए कमांड लाइन की तुलना में चीजें बहुत आसान हो जाती हैं।


4

किसी को यहाँ नीचे पढ़ने के लिए परेशान ??

मैं यह कहकर संक्षेप में कहता हूं कि व्यापक रूप से जटिल आईडीई कार्यक्षमता अपरिहार्य है और यह (किसी दिन) उदात्त विमनेस के ज़ेन में विकसित होना चाहिए।

हमारा सॉफ्टवेयर लगभग 2 एम एलओसी की 129 परियोजनाएं हैं। .NET फ्रेमवर्क की व्यापकता में जोड़ें और यह सब मैं कह सकता हूं कि आईडीई महत्वपूर्ण है, इस धागे के सवाल की प्रेरणाओं को पार कर रहा है।

कोड बेस में अंतर्दृष्टि

अवधि। आप जानते हैं कि हम किस प्रकार की सुविधाओं के बारे में बात कर रहे हैं; सिवाय इसके कि मैं जिस तरह के कोड बेस से निपटता हूं, उससे इसकी सुविधा अपरिहार्य और आवश्यक हो जाती है।

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

लेकिन यह स्मार्टनेस कई बार बहुत ज्यादा है। मैं अक्सर अच्छे-पुराने "फाइल्स इन फाइल्स" टेक्स्ट सर्चिंग का उपयोग करता हूं।

कोडिंग सहायता

यहाँ है जहाँ मैं "पर्याप्त" रोना। ज्यादातर अस्पष्ट, दर्जन भर रंगों के साथ एक स्क्रीन-फुल की कल्पना करें, हर जगह पर विशेष रूप से हाइलाइट किए गए कुछ ब्रेस, अस्पष्ट रूप से ब्रेस को हाइलाइट करते हुए, जो कि वास्तव में ब्रेस है, हर जगह मुख्य रूप से रेखांकित होते हैं क्योंकि "यह" चाहता है कि मैं साहित्य कोड लिखूं, रेस्परर संदर्भ मेनू के लिए आइकन (आप बस इसे क्लिक करें! तब इसे ज्यादातर समय अनदेखा करें), एक सिग्नेचर पॉपअप स्क्रीन के 2/3 भाग को क्षैतिज, लंबवत रूप से कई अतिभारों को प्रदर्शित करने में मदद करता है, पॉपअप के कारण जहां आप माउस कर्सर को छोड़ने के लिए गए थे ... खिचड़ी भाषा में भी & ^!% लाइन * s * का कोड देखा है जिस पर मैं काम कर रहा हूँ!

Vis.Stud। अतिसूक्ष्मवाद को गले लगाने की जरूरत है, इसलिए मैं कोडिंग पर ध्यान केंद्रित कर सकता हूं और सैकड़ों के माध्यम से नहीं जा सकता (हजारों यदि आप हर रंग कोडिंग सेटिंग और उन सभी प्लगइन्स की गणना करते हैं) एक खो लड़ाई में सेटिंग्स को पुनः प्राप्त करने के लिए। एक " परेतो " कुंजी महान होगी।


1
वास्तव में यहां आपके विचारों की सराहना की गई है, जैसा कि आप दोनों IDE और "उदात्त विमनेस" चीजों के दृष्टिकोण के संदर्भ में "इसे वास्तव में" पाते हैं। मैं आपके साथ यहां हूं। यहाँ उम्मीद है कि यह पारित होने के लिए आता है।
घोप्पेर 21

3

आपके द्वारा उपयोग किए गए आईडीई से C # विकास प्रभावी रूप से अविभाज्य है?

बिलकूल नही। आप पूरे नाम स्थान का आयात क्यों नहीं करेंगे? एक एकीकृत आईडीई या एक पाठ संपादक का उपयोग करने के विकल्प का इससे कोई लेना-देना नहीं है। संपूर्ण नामस्थान को आयात करने से कोड पढ़ने या उसका उपयोग करने में कठिनाई नहीं होती है।

याद रखें, C # एक टाइप की गई भाषा है। यदि आप कई नामस्थानों को आयात करते हैं जिसमें एक ही वर्ग है तो आपको संकलन त्रुटि मिलेगी।

मैं व्यक्तिगत रूप से उस तरह की घोषणाओं का उपयोग नहीं करता हूं। इसके बजाय मैं varयहां बताए गए कारणों के बजाय कीवर्ड का उपयोग करता हूं: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/


1
मुद्दा कोड नहीं लिख रहा है। (स्टैक ओवरफ्लो प्रश्न मैं ऊपर से लिंक करता हूं एक उदाहरण देता है।) कोड पढ़ते समय, आप कैसे जानते हैं कि कुछ कहां से आता है? पायथन के साथ, आप एक स्पष्ट आयात की तलाश कर सकते हैं (यह मानते हुए कि कोड इस तरह के आयात का उपयोग करने के लिए मजबूत पायथन सम्मेलनों का अनुसरण करता है)। C # के साथ, यह सर्वसम्मति प्रतीत होती है कि व्यवहार में आप VS जैसे IDE का उपयोग करते हैं।
गॉपर

यदि आपको नहीं पता कि कक्षा कहाँ से आती है, तो आपको यह जानने का तरीका होगा कि यह कैसे काम कर रहा है। बस google msdn <classname>और पहले लिंक पर क्लिक करें। वहां आपको नाम स्थान भी मिलता है।
jgauffin

यह दृष्टिकोण सांस्कृतिक अंतर का उदाहरण देता है। ऐसा नहीं है कि पायथन प्रोग्रामर Google सामान नहीं करते हैं - बेशक वे करते हैं - यह सिर्फ इसके बारे में सोचने का तरीका अलग है।
घोप्पेर

एक अलग नोट पर, C # में var अच्छा सिंटैटिक शुगर / कंपाइलर शॉर्टकट है जो मुझे कोड कम वर्बोज़ और दोहराव बनाने के लिए पसंद है। बस इच्छा है कि आप इसे हर जगह उपयोग कर सकते हैं, न कि केवल तरीकों के अंदर।
गॉपर

@ Ghopper21: हाँ, मुझे पता है। मेरा कहना है कि Google ने MSDN को बहुत अच्छी तरह से अनुक्रमित किया है और आप सीधे ऐसा करके प्रलेखन प्राप्त करेंगे। इसलिए आपको वास्तव में उस हर वर्ग को दस्तावेज करने की आवश्यकता नहीं है जिसे आप पूरे पथ को शामिल करके उपयोग करते हैं।
जिगौफिन

1

मेरी समझ यह थी कि पायथन में, "सब कुछ जनता" या उस प्रभाव के लिए कुछ है। C # में, मॉड्यूल डिज़ाइनर यह तय करता है कि सार्वजनिक क्या है और क्या नहीं है, इसलिए जब आप ऐसा करते हैं तो importआपको केवल सार्वजनिक API प्राप्त होता है। यह उस अंतर का एक कारण हो सकता है जिसका आप वर्णन कर रहे हैं।


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

5
@ Ghopper21 - जावा (और उदाहरण के लिए C ++) में स्पष्ट आयात को प्राथमिकता देने का एकमात्र कारण नाम टकरावों को रोकना है। सी # ने आयात / प्रकार के उपनामों के माध्यम से इस समस्या से निपटने के लिए डिजाइन निर्णय लिया, क्योंकि वे बेहतर तरीके से संभालते हैं जब आपके पास वास्तव में एक नाम टकराव होता है, जिसमें बायलरप्लेट आयात का एक गुच्छा आपके स्रोत को अव्यवस्थित करने का लाभ नहीं होता है।
तेलस्टिन

1

आपके द्वारा उपयोग किए गए आईडीई से C # विकास प्रभावी रूप से अविभाज्य है?

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

उस ने कहा, अधिकांश सी # डेवलपर्स बहुत छोटी परियोजनाओं से निपटते हैं और वीएस का उपयोग करने के लिए काफी खुश हैं।


0

यह सी # विकास पर एक दिलचस्प दृष्टिकोण है। आप जो पूछ रहे हैं, वह C # से परे है, यदि आप IDE के बारे में पूछ रहे हैं।

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

जब आप सी # में "उपयोग" कथन के बारे में बात करते हैं और इसकी तुलना पायथन से करते हैं, तो यह वास्तव में हुड के नीचे चल रही एक ही बात नहीं है। उपयोग करने वाले कथनों का उपयोग कंपाइलर द्वारा C # कोड को MSIL में बदलने के लिए किया जाता है। MSIL में, इन सभी वर्गों को "इस नाम स्थान से आयात" निर्देश नहीं है। जब तक कोड एमएसआईएल के स्तर पर है, तब तक सभी वर्गों को उनके पूरी तरह से योग्य नामों के साथ टैग किया गया है। ये "उपयोग" और "आयात" बयान मानव पठनीयता की सहायता के लिए हैं। वे कंपाइलर ऑप्टिमाइज़ेशन कमांड नहीं हैं। यह सब आरंभिक "पूरी तरह से योग्य नामों का टैगिंग" हो जाने के बाद, FQNs के लिए एक प्रकार का निम्न-स्तरीय "मिनिइज़" हो सकता है, लेकिन यह कंपाइलर / दुभाषिया को तेज़ी से निष्पादित करने में सहायता करता है।

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

HTH।


"ये '' और 'आयात' बयानों का उपयोग मानव पठनीयता में सहायता के लिए है।" - हाँ, यह यहाँ काम पर एक महत्वपूर्ण दार्शनिक अंतर है। पाठ स्तर पर पठनीयता एक प्रमुख प्रथम-क्रम पायथन डिजाइन सिद्धांत है। C # की सख्त आवश्यकता नहीं है, लेकिन व्यावहारिक रूप से एक अच्छे IDE पर निर्भर है जैसे VS "पठनीय" हो। संयोग से, पायथन में "आयात" भी सी # में "उपयोग" के विपरीत, पठनीयता से अधिक है।
गॉपर 21

0

मुझे लगता है कि ऐतिहासिक रूप से इसका उत्तर बहुत अधिक है, हाँ - सी # विकास हो रहा है और विजुअल स्टूडियो, ज़मरीन, या शार्पडेवल के बाहर किसी भी चीज़ में प्रभावी रूप से चल रहा है, बस एक बहुत ही अप्रिय अनुभव था।

लेकिन हाल ही में बहुत सारी परियोजनाएँ सामने आई हैं जो इसे आसान बनाती हैं, जैसे:

OmniSharp , विम, emacs, परमाणु, और उदात्त प्लगइन्स के साथ-साथ इंटैलिजेंस और रीफैक्टरिंग के लिए एक आधार प्रदान करता है। मैंने वास्तव में इसका उपयोग नहीं किया है, इसलिए मुझे नहीं पता कि यह कितना अच्छा काम करता है, लेकिन यह आशाजनक लगता है।

येमन ASP.NET MVC जनरेटर , एक नए MVC प्रोजेक्ट को बूटस्ट्रैप करने में मदद करता है (शायद अन्य जनरेटर मौजूद हैं)।

paket , NuGet का एक विकल्प जहां आप वास्तव में कमांड लाइन से अपनी परियोजना में NuGet पैकेज जोड़ सकते हैं, और आपकी .csproj फाइलें अपडेट की जा सकती हैं (हालांकि एक NuGet कमांड लाइन टूल था, वास्तव में पैकेज का उपयोग करने के लिए प्रोजेक्ट को अपडेट करना IDE का हिस्सा था। एकीकरण, कमांड लाइन उपकरण नहीं)।

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

इसलिए आपको उठने और दौड़ने में सक्षम होना चाहिए, लेकिन अपने टूलकिन को ठीक से चलाने और कुशलता से चलाने के लिए तुलनात्मक रूप से अधिक काम करना होगा।


-1

अब और नहीं:

http://www.omnisharp.net/

OmniSharp ओपन सोर्स प्रोजेक्ट्स का एक परिवार है, प्रत्येक एक लक्ष्य के साथ - अपनी पसंद के संपादक में महान .NET विकास को सक्षम करने के लिए।

क्रॉस प्लेटफ़ॉर्म .NET कहना मज़ेदार है। लेकिन क्या किसी के लिए विजुअल स्टूडियो और विंडोज के बिना .NET विकसित करना उचित है?

क्या यह मज़ेदार है। .NET को Mac में उप-क्रम में करना मज़ेदार है? उबंटू और Emacs? विंडोज और एटम? आप अपने संपादक का उपयोग कर सकते हैं Intellisense (न केवल स्वतः पूर्ण) जैसी महान सुविधाओं का उपयोग करें, संदर्भ जोड़ें, स्वरूप दस्तावेज़, और बहुत कुछ। कहीं भी विकसित करें, कहीं भी तैनात करें (और Azure के लिए!)

मैंने इसे सबइम 3 और ओएक्सएक्स के साथ परीक्षण किया है

पर अधिक नमूने

http://blog.jonathanchannon.com/2014/11/12/csharp-first-class-citizen-sublime-text/


ओमनिषर्प पाठ संपादकों के साथ सी # का उपयोग करना संभव बनाता है, उदात्त और emacs की तरह। तो नीचे क्यों उतारा गया है?
mamcx
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.