मुझे आईडीई का उपयोग क्यों करना चाहिए? [बन्द है]


391

एक अन्य प्रश्न में, मार्क ने IDEs के बारे में बहुत कुछ कहा, "कुछ लोग अभी भी नहीं जानते" "क्यों उन्हें एक का उपयोग करना चाहिए ..."। जैसा कि कोई व्यक्ति जो प्रोग्रामिंग के लिए विम का उपयोग करता है, और ऐसे वातावरण में काम करता है जहां मेरे सभी साथी अपने सभी कामों के लिए या तो वीम या एमएसीएस का उपयोग करते हैं, आईडीई के फायदे क्या हैं? मुझे एक का उपयोग क्यों करना चाहिए?

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

अगर आपको लगता है कि आईडीई कुछ प्रकार के काम के लिए उपयुक्त हो सकता है, लेकिन दूसरों के लिए नहीं, तो मुझे यह भी सुनने में दिलचस्पी है कि क्यों।


1
मेरे ब्लॉग से संपर्क करने के लिए धन्यवाद, वास्तव में इस साइट में एक निजी संदेश प्रणाली होनी चाहिए!
मार्क

11
emacs एक बुरा उदाहरण है। आईडीई फीचर को ढूंढना मुश्किल है जिसमें एमएसीएस की कमी है। अंतर यह है कि बाहर उपलब्ध बॉक्स क्या है और क्या एक अनुकूलन की आवश्यकता है।
jfs

8
IDE बेकार हैं, असली प्रोग्रामर vim का उपयोग करते हैं

30
तो क्या आपने टिप्पणियों के कारण आईडीई का उपयोग शुरू कर दिया है?
आफ्टरशॉक

1
कुछ समय के लिए आपके पास आईडीई का उपयोग करने के अलावा कोई विकल्प नहीं है :(
लोरम इप्सम डोलर

जवाबों:


537

यह वास्तव में इस बात पर निर्भर करता है कि आप किस भाषा का उपयोग कर रहे हैं, लेकिन C # और Java में मुझे IDE के लिए फायदेमंद लगता है:

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

ये सभी समय बचाते हैं। वे चीजें हैं जो मैं स्वयं कर सकता था, लेकिन अधिक दर्द के साथ: मैं कोडिंग करना चाहूंगा।


90
मुझे लगता है कि emacs एक IDE है, फिर;)
Svante

97
जब यह उस तरह से अभिनय कर रहा है, तो मैं कहूंगा कि विम एक आईडीई के रूप में गिना जाता है।
जॉन स्कीट

58
मेरे अनुभव में सबसे बड़ी बात यह है कि विम और एमएसीएस "वास्तविक" आईडीई से गायब हैं (हाँ, मुझे पता है कि वे महान विकास पर्यावरण हो सकते हैं) चेतावनी-जैसा-आप-प्रकार का हिस्सा है। यह मूल रूप से संपादक में एक उन्नत संकलक एम्बेड करने का मतलब होगा और मुझे नहीं लगता कि उन्हें एकीकरण का स्तर मिलता है।
जोकिम सॉयर

16
saua: क्या तुमने Flymake, flymake.sourceforge.net को देखा है ? यह कम से कम कुछ चेतावनियाँ प्रदान करता है जैसा कि आप Emacs को टाइप करते हैं
polyglot

62
चेतावनी-जैसा-आप टाइप करते हैं, मुझे लगता है कि जॉन स्कीट को आईडीई को चेतावनी देने के लिए इसकी आवश्यकता है, निम्नलिखित कोड को सही करने की कोशिश करना व्यर्थता है।
सेमीकैजिन्टी

100

कोड पूरा हो रहा है। यह कोड को एक्सप्लोर करने में बहुत मदद करता है।


107
मैं कहूंगा कि
इंटेलीसेंस के

2
फिर, मैं Ctrl + P दबा सकता हूं, मुझे कमांड के एक पूरे समूह की एक ड्रॉपडाउन सूची देता है जो vimसोचता है कि मैं उपयोग कर सकता हूं।
new123456

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

1
यह कैसा उत्तर है? जब आप इसे जोर से पढ़ते हैं तो यह एक बुरा माइक्रोसॉफ्ट स्लोगन की तरह लगता है ...
कोलोब कैनियन

ठीक है ... YouCompleteMe, Deoplete ... यदि आप उस प्रकार का कोड पूरा करना चाहते हैं । मैं Emacs के लिए इसके बारे में नहीं जानता। साथ ही विम में अन्य संपादकों का उपयोग करते समय मेरे द्वारा खोए गए बॉक्स से असाधारण ऑटो-पूर्णता है।
जेकड जूल 29'18

85

क्यों मैं एक आईडीई का उपयोग करने के लिए संक्षिप्त जवाब आलस्य है।

मैं एक आलसी आत्मा हूं जो चीजों को एक कठिन तरीके से करना पसंद नहीं करता है जब इसके बजाय एक आसान तरीका है। आईडीई के जीवन को आसान बनाते हैं और इसलिए हमें आलसी लोगों से अपील करते हैं।

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

आईडीई का उपयोग करने की कोई आवश्यकता नहीं है। यह सिर्फ बहुत कठिन काम नहीं है।


यदि आप Visual Studio .NET का उपयोग कर रहे हैं, तो F12 को "परिभाषा पर जाएं" के लिए मैप किया गया है। (मुझे अभी पता चला है) इसलिए आपको इसे प्राप्त करने के लिए राइट-क्लिक करने की आवश्यकता नहीं है। 8)
नॉबब्लोच

@ Knobloch, मैं VS2008 और ग्रहण दोनों का उपयोग करता हूं। निजी तौर पर मैंने FlashDevelop का बहुत उपयोग किया। "परिभाषा पर जाएं" शॉर्टकट तीनों के लिए अलग-अलग है, इसलिए मैं राइट क्लिक करने पर भरोसा करता हूं :)
डेविड अरनो

और आप मेनू बार पर राइट-क्लिक करने और कस्टमाइज़ / कीबोर्ड शॉर्टकट चुनने के साथ अंतरंग रूप से परिचित हो सकते हैं।
dkretz

19
यह सिर्फ आलस्य की बात नहीं है :) - एक आईडीई मूल्यवान समय बचाता है और इसलिए उत्पादकता बढ़ाता है।
एलेक्स शिम्प

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

56

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

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


9
हाँ, यह एक सुरक्षित सामान्यीकरण नहीं है। मैं इन उत्तरों में वर्णित सभी IDE विशेषताओं के लिए Emacs का उपयोग करता हूं।
jfm3

21
मुझे लगता है कि एक शक्तिशाली टेक्स्ट एडिटर में IDE जैसी सुविधाओं को कॉन्फ़िगर करने में लगने वाला समय बेहतर तरीके से आउट-ऑफ-द-बॉक्स सुविधाओं का उपयोग करके IDE में कोडिंग करना बेहतर हो सकता है।
jfs

6
मैं विम का उपयोग करता हूं जैसे मैं एक आईडीई का उपयोग करता हूं।

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

7
@JFSebastian: मुझे लगता है कि IDE सामान करने के लिए Emacs को कॉन्फ़िगर करने के बजाय IDE सामान करने के लिए नेविगेशन, ट्रैम्प, शेल-मोड, dired ... इत्यादि को कॉन्फ़िगर करना अधिक उत्पादक है।
तिखन जेल्विस

51

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

अपने शुरुआती स्व-शिक्षण, कॉलेज और अब पेशेवर करियर के दौरान, मुझे पता चला है कि आईडीई के भीतर पूरी तरह से किया गया कोई भी बड़ा सॉफ्टवेयर विकास प्रतिशोधात्मक हो जाता है। मैं यह कहता हूं क्योंकि अधिकांश IDE चाहता है कि आप इसमें काम करें उनकेअजीब I-control-how-the-world-works style आपको अपनी परियोजनाओं को उनकी लाइनों के साथ टुकड़ा और पासा करना होगा। आपने अपने प्रोजेक्ट का निर्माण उनके अजीब संवाद बॉक्स का उपयोग करके किया है। अधिकांश IDE खराब प्रोजेक्ट्स के बीच जटिल बिल्ड निर्भरता का प्रबंधन करते हैं, और निर्भरता 100% काम करना मुश्किल हो सकता है। मैं उन स्थितियों में रहा हूँ जहाँ IDE मेरे कोड का एक कार्यशील निर्माण नहीं करेगा जब तक कि मैंने क्लीन / रीबिल्ड ऑल नहीं किया। अंत में, आपके सॉफ्टवेयर को विकास से बाहर निकालने और आईडीए से क्यूए या प्रोडक्शन जैसे अन्य वातावरणों में स्थानांतरित करने का शायद ही कोई साफ तरीका हो। यह आमतौर पर आपके सभी तैनाती इकाइयों को प्राप्त करने के लिए एक क्लिक उत्सव है, या आपको कुछ अजीब उपकरण मिल गए हैं जो आईडीई विक्रेता आपको सामान बांधने के लिए देता है। मगर फिर से,

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

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

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


2
+1, सामान बनाने के लिए शुरू की गई जटिलताएं (कम से कम आमतौर पर) सबसे बड़ी वजहों में से एक है जो मैं IDEs का पता लगाता हूं
स्कॉट शुलथेस

24

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

उत्पादकता के द्वारा, मेरा मतलब है कि आपके काम को सर्वोत्तम संभव परिणामों के साथ कुशलतापूर्वक करने की क्षमता। IDE कई स्तरों पर इसे सक्षम करते हैं। मैं एक Emacs विशेषज्ञ नहीं हूं, लेकिन मुझे संदेह है कि इसमें प्रमुख IDEs की किसी भी विशेषता का अभाव है।

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

यदि आपके पास विकल्प है तो आप इतने शक्तिशाली का उपयोग क्यों नहीं करेंगे?

एक प्रयोग के रूप में, 30 दिनों के लिए, कहने के लिए आईडीई का उपयोग करने के लिए खुद को प्रतिबद्ध करें और देखें कि आप कैसा महसूस करते हैं। मैं अनुभव पर आपके विचारों को पढ़ना पसंद करूंगा।


10
वहाँ विशेषताएं हैं Emacs कि ग्रहण, कम से कम, या तो बहुत अच्छी तरह से कमी या छुपाता है। उदाहरण के लिए, लाइनों का एक हिस्सा चुनने और उन्हें जगह में छाँटने की क्षमता। टिप्पणी संपादित करते समय Emacs का भरण-पैरा भी हरा करना कठिन है; ग्रहण के प्रकार में एक समान विशेषता है, लेकिन यह तुलना में बेहद कमजोर है।
पोर्कुलस

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

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

20

आईडीई होने के निम्नलिखित फायदे हैं:

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

और भी बहुत कुछ हैं, हो सकता है कि आप इसे आजमाएं।


मैं हर न्यूनतम संपादक के लिए बात नहीं कर सकता, लेकिन विम के पास मैक्रो है जो आप स्क्रिप्ट कर सकते हैं जो संकलन और चलाने जैसी बहुत सारी चीजें कर सकते हैं।

@ इस बिंदु पर है कि आप उन्हें स्क्रिप्ट के लिए है। यह पहले से ही उपलब्ध होना चाहिए।
क्रश करें

20

आईडीई मूल रूप से हैं:

  • संपादक w / कोड पूरा करना, रीफैक्टरिंग और प्रलेखन
  • डीबगर
  • फाइलसिस्टम एक्सप्लोरर
  • SCMS क्लाइंट
  • उपकरण बनाएँ

सभी एक पैकेज में।

आपके पास यह सब (और कुछ और) अलग-अलग टूल या सिर्फ एक शानदार प्रोग्रामेबल एडिटर और एक्स्ट्रा टूल्स का उपयोग करके हो सकता है, जैसे Emacs (Vim के रूप में लेकिन इसमें कम IDEbility IMO है)।

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


12

ग्रहण:

कोड हिगलाइटिंग, पृष्ठभूमि में संकलित करना, मेरी त्रुटियों को इंगित करता है जैसे मैं साथ जाता हूं।

Javadoc के साथ एकीकरण, ctrl-Space के साथ चर नाम सुझाना।

जब मैं संकलित करता हूं, मुझे वहीं त्रुटियां मिलती हैं। मैं एक त्रुटि पर डबल क्लिक कर सकता हूं, और यह उपयुक्त रेखा प्रदर्शित करता है।

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

चींटी के साथ एकीकरण। एप्लिकेशन को बनाने और तैनात करने के लिए एक कमांड।

वेब सर्वर के दूरस्थ डीबगिंग सहित डीबगर्स के साथ एकीकरण।

काल्पनिक रिफैक्टरिंग उपकरण, कोड के एक खंड के संदर्भ में खोज। एक बदलाव के प्रभाव को जानने में मेरी मदद करता है।

सब सब में, यह मुझे और अधिक उत्पादक बनाता है।


बात यह है कि Emacs ग्रहण की तुलना में अधिक भाषाओं के लिए बहुत कुछ करता है।
तिखन जेल्विस

11

मैंने Emacs को विकास और मेल / समाचार दोनों के लिए अपने प्राथमिक वातावरण के रूप में लगभग 10 वर्ष (1994-2004) के लिए उपयोग किया है। मुझे आईडीई की शक्ति का पता चला जब मैंने 2004 में खुद को जावा सीखने के लिए मजबूर किया, और मुझे आश्चर्य हुआ कि मुझे वास्तव में आईडीई ( IntelliJ IDEA ) पसंद आया ।

मैं विशिष्ट कारणों में नहीं जाऊंगा क्योंकि उनमें से बहुत पहले ही यहां बताए गए हैं - बस याद रखें कि अलग-अलग लोगों को अलग-अलग विशेषताएं पसंद हैं। मैंने और एक सहयोगी ने एक ही IDE का उपयोग किया, हम दोनों ने उपलब्ध सुविधाओं का सिर्फ एक हिस्सा इस्तेमाल किया, और हमने IDE का उपयोग करते हुए एक दूसरे को नापसंद किया (लेकिन हम दोनों को ही IDE पसंद था)।

लेकिन Emacs / Vim से संबंधित वातावरण पर IDEs के साथ एक फ़ायदा है, जिस पर मैं ध्यान केंद्रित करना चाहता हूं: आप कम समय बिताते हैं, जो आप चाहते हैं, उन सुविधाओं को स्थापित / कॉन्फ़िगर करना।

साथ विंग आईडीई (अजगर के लिए) मैं स्थापना के बाद 15-20 मिनट के विकास शुरू करने के लिए तैयार हूँ। पता नहीं कितने घंटे मुझे Emacs / Vim के साथ चलने और चलने वाली सुविधाओं को प्राप्त करने की आवश्यकता होगी। :)


2
इसे शुरू होने में अधिक समय लगता है, लेकिन यह बाद में बेहतर 'अनुरूप' है।
जुज

3
Emacs / Vim को कॉन्फ़िगर करना उचित फाइलों को किसी ऐसे स्थान पर कॉपी करने का मामला है जहां प्रोग्राम उन्हें ढूंढ सकता है। यह वास्तव में मुश्किल नहीं है यदि आप अपनी कॉन्फ़िगरेशन फ़ाइलों को अच्छी तरह से एक निर्देशिका में व्यवस्थित रखते हैं, जिसके बाद आप उन्हें फ्लैश ड्राइव, इंटरनेट स्टोरेज या रिपॉजिटरी में रख सकते हैं, ताकि cloneजब भी आपको अपना काम सेट करने की आवश्यकता हो, आप उन्हें कर सकें वातावरण। :)
गॉर्डन गुस्ताफसन

10

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

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

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


8

अलग-अलग लोगों के अलग-अलग कारण हो सकते हैं। मेरे लिए ये फायदे हैं।

  1. परियोजना के लिए एक एकीकृत महसूस प्रदान करता है। उदाहरण के लिए, मैं सभी संबंधित परियोजनाओं को एकल दृश्य में देखूंगा।
  2. बढ़ी हुई कोड उत्पादकता प्रदान करता है
    1. वाक्य - विन्यास पर प्रकाश डालना
    2. विधानसभाओं का जिक्र
    3. IntelliSense
    4. डेटाबेस और संबंधित UI फ़ाइलों का केंद्रीकृत दृश्य।
    5. डिबगिंग सुविधाएँ

दिन के अंत में, यह मुझे नोटपैड या वर्डपैड की तुलना में तेजी से कोड करने में मदद करता है। यह मेरे लिए एक आईडीई पसंद करने का एक बहुत अच्छा कारण है।


8

एक आईडीई कर सकते हैं एक 'बेहतर' विकल्प सकता है जो इस बात पर निर्भर करता है कि एक डेवलपर क्या हासिल करना चाहता है।

एक पाठ संपादक कर सकते हैं 'श्रेष्ठ' सकता है क्योंकि आईडीई आमतौर पर भाषाओं के एक (या एक छोटे से चयन) की ओर तैयार होते हैं।

यदि कोई डेवलपर अपना अधिकांश समय एक ही ओएस में या एक ओएस में संबंधित भाषाओं (जैसे सी # और टी-एसक्यूएल) के 'क्लस्टर' में खर्च करता है, तो जीयूआई डिजाइन, डिबग, इन्टेलिसेंस, रीफैक्टरिंग आदि द्वारा प्रस्तुत किया जाता है। एक अच्छी IDE बहुत सम्मोहक हो सकती है। यदि, उदाहरण के लिए, आप अपना अधिकांश समय VB.NET में काम करते हैं, तो शायद थोड़ी-सी T-SQL, Windows वातावरण में, तब आप विजुअल स्टूडियो या तुलनीय IDE को न देखें तो आप मूर्खतापूर्ण होंगे। ।

मेरे पास उन लोगों के प्रति कोई पूर्वाग्रह नहीं है जो आईडीई या पाठ संपादकों को पसंद करते हैं, अगर अच्छी तरह से सीखा जाए तो दोनों बहुत उत्पादक और उपयोगी हो सकते हैं !


7

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

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

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

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

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


5

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

मैं आईडीई को रिफैक्टिंग और ब्राउजिंग और डिबगिंग के लिए बेहतर समझता हूं और यह पता लगाने के लिए कि क्या करना है। छोटी चीजें तब IDE में सही की जाती हैं, बड़ी चीजें जो मैं काम खत्म करने के लिए फ्लिप करता हूं।


5

अन्य उत्तरों के अलावा, मुझे एक IDE की विकासशील शक्ति का संयोजन करना पसंद है जिसमें Vim की संपादन शक्ति कुछ इस तरह का उपयोग कर रही है विले ग्रहण के लिए ViPlugin की


5

इंटेलीजेंसी , एकीकृत डिबगर, और तत्काल विंडो मुझे बहुत अधिक उत्पादक बनाती है ( विजुअल स्टूडियो 2008 )। अपनी उंगलियों पर सब कुछ के साथ, मैं कोड लिखते समय अपने सिर के अंदर एक विशाल परियोजना के विशाल बहुमत को रख सकता हूं। Microsoft अपने OS पर गेंद को गिराना जारी रख सकता है, लेकिन Visual Studio अब तक विकसित किए गए बेहतरीन उत्पादों में से एक है।


4

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


3

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


3

दृश्य-आधारित स्टूडियो और ग्रहण जैसे GUI- आधारित IDE में पाठ-आधारित IDE पर कई फायदे हैं जैसे Emacs या vim उनकी प्रदर्शन क्षमताओं के कारण:

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

मूल रूप से GUI- आधारित IDE से आप एक ही बार में स्क्रीन पर अधिक उपयोगी जानकारी प्राप्त कर सकते हैं और आप अपने एप्लिकेशन के ग्राफ़िकल भाग को आसानी से टेक्स्ट भागों के रूप में देख / संपादित कर सकते हैं।

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

Emacs और vim जैसे टेक्स्ट-आधारित IDE, समय के साथ कोड पूरा होने और रिफैक्ट करने जैसी सुविधाओं को जोड़ सकते हैं, इसलिए लंबे समय में उनकी मुख्य सीमा उनका टेक्स्ट-आधारित डिस्प्ले मॉडल है।


3

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


3

एक आईडीई तेजी से और अधिक आसानी से काम करने की अनुमति देता है ... मैंने देखा कि मैंने एक साधारण पाठ में कोड में नेविगेट करने में बहुत समय बिताया है ...

एक अच्छी IDE में, वह समय कम हो जाता है जब IDE फ़ंक्शन, पिछली संपादन स्थिति में, चर में कूदने का समर्थन करता है ... साथ ही, एक अच्छा IDE विभिन्न भाषा सुविधाओं और परियोजनाओं के साथ प्रयोग करने का समय कम कर देता है, जैसा कि स्टार्ट-अप समय छोटा हो सकता है।


3

कुछ कारणों से मैं एक आईडीई का उपयोग करने के लिए सोच सकता हूं:

  • एकीकृत मदद एक पसंदीदा है।
  • विजुअल स्टूडियो के पूर्वावलोकन के साथ अंतर्निहित रिफ्लेक्टर
  • IntelliSense , वाक्यविन्यास hightlighting, बड़ी परियोजनाओं के लिए नेविगेशन में आसानी, एकीकृत डिबगिंग, आदि (हालांकि मैं नशे के साथ जानता हूँ कि आप शायद Emacs और Vim के साथ यह बहुत कुछ प्राप्त कर सकते हैं )।
  • इसके अलावा, मुझे लगता है कि इन दिनों आईडीई के पास एक व्यापक उपयोगकर्ता-आधार है, और शायद अधिक लोग उनके लिए ऐड-इन्स विकसित कर रहे हैं, लेकिन मैं गलत हो सकता हूं।

और काफी स्पष्ट रूप से, मुझे अपना माउस पसंद है। जब मैं शुद्ध पाठ-आधारित संपादकों का उपयोग करता हूं तो यह एकाकी हो जाता है।


2


एकीकृत डिबगिंग, इंटैलिजेंस जैसी सुविधाएँ प्रदान करके जीवन को आसान बनाने का समय बचाता है ।

बहुत सारे हैं, लेकिन एक का उपयोग करने की सिफारिश करेंगे, वे स्पष्ट से अधिक हैं।


2
उत्तर के लिए धन्यवाद, लेकिन अगर मुझे लगा कि वे स्पष्ट हैं, तो मैंने पहली जगह में सवाल नहीं पूछा होगा!
साइमन हॉवर्ड

2

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


+1 के लिए ध्यान दें कि आज के "संपादकों" में कल की "आईडी" की तुलना में अधिक विशेषताएं हैं।
शॉन मैकमिलन

2

एक का उपयोग करने का मेरा मुख्य कारण यह है कि जब कोड 100 फाइलों से आगे निकल जाता है।

हालांकि ctags काम कर सकते हैं, कुछ IDEs पास फ़ाइलों को आसानी से सुपर फास्ट करने के लिए नेविगेट करने का एक अच्छा तरीका है।

यह समय बचाता है जब आपके पास बहुत काम करना है।


2

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

कुछ आईडीई जैसे दूसरों के दृश्य भी आपके कोड को पार्स करने के लिए प्रतीत होते हैं, और टाइप करने से पहले आप त्रुटियों का पता लगा सकते हैं: ऐसा लगता है कि लॉजिक ऐसा है कि केवल एक आईडीई ही संकलक के साथ मिलकर काम कर सकता है ताकि टाइप किए गए स्रोत में समस्या का तुरंत पता लगाया जा सके।

मेरा जंगली जवाब है कि आईडीई / कमांड-लाइन लौ युद्ध मौजूद है, क्योंकि सी / सी ++ निष्पादन योग्य इमारत डी भाषा के विपरीत, मानकीकृत दृष्टिकोण से बहुत अच्छी तरह से नियंत्रित नहीं होती है; हर मंच अपने तरीके से संकलन / लिंकिंग / आदि को संभालता है, इसलिए इसे कम गन्दा बनाने के लिए वे एक आईडीई बनाते हैं।

आपके दृष्टिकोण से, कमांड-लाइन का उपयोग करना अधिक सरल हो सकता है, अगर मानक विकल्पों के साथ केवल एक कंपाइलर होता, तो यह आसान होता, लेकिन सच यह है कि C / C ++ लचीला है, इसलिए अंत में, सभी प्लेटफ़ॉर्म इसे अपने तरीके से करें, इसलिए आईडीई यह नहीं समझाता कि इसे कैसे करना है।

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

Microsoft या Apple, वे सभी बुरे होंगे, जिन्हें विवरण में दर्ज किए बिना आवेदन के निर्माण के लिए सीधे-सीधे तरीके का प्रस्ताव करना होगा, और चूंकि एक आवेदन का निर्माण सीधे ओएस की वास्तुकला पर निर्भर करता है, यह शायद ही "मानक" होगा। कमांड-लाइन है

इसे सरल, बड़े और जटिल अनुप्रयोगों में रखने के लिए, जहाँ आप बहुत गहरी खुदाई नहीं करना चाहते हैं -> IDE, सॉफ़्टवेयर के छोटे टुकड़े या सरल सिस्टम सॉफ़्टवेयर-डिज़ाइन -> कमांड-लाइन। सिवाय उन निफ्टी लाइब्रेरियों के जो एक मेकफाइल को एम्बेड करते हैं, लेकिन यह एक और कहानी है।

मुझे यह भी लगता है कि आईडीई का उपयोग तब किया जाता है जब वितरित किए गए एप्लिकेशन में विडंबना, एक जीयूआई या कुछ ऐसा होता है जिसका एक इंटरफ़ेस होता है या सीधे एक ओएस से जुड़ा होता है, इसलिए फिर से, यह उन लोगों के लिए भी है जो बिना यूआई / जीयूआई का उपयोग करेंगे। यह कैसे काम करता है, जबकि सिस्टम प्रोग्राम करने वाले लोगों को इसकी आवश्यकता नहीं होगी।

आईडीई सिर्फ आधुनिक बकवास है, लेकिन मुझे लगता है कि 100 वर्षों में कमांड-लाइन अभी भी मौजूद रहेगी।


1

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


1

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

लघु प्रश्न इतना छोटा उत्तर :)


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

1

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.