Pourquoi devrais-je utiliser un IDE? [fermé]

Dans une autre question, Mark parle hautement des IDE, disant que "certaines personnes ne savent toujours pas" pourquoi "ils devraient en utiliser un ...". En tant que personne qui utilise vim pour la programmation et travaille dans un environnement où la plupart / tous mes collègues utilisent vim ou emacs pour tout leur travail, quels sont les avantages des IDE? Pourquoi devrais-je en utiliser un?

Je suis sûr que c'est un problème important pour certaines personnes, et je ne suis pas intéressé à déclencher une guerre des flammes, alors veuillez répondre uniquement avec les raisons pour lesquelles vous pensez qu'une approche basée sur l'IDE est supérieure . Je ne suis pas intéressé à savoir pourquoi je ne devrais pas utiliser un IDE; Je n'en utilise déjà pas. Je suis intéressé à entendre "l'autre côté de la clôture", pour ainsi dire.

Si vous pensez que les IDE peuvent convenir à certains types de travaux mais pas à d'autres, je suis également intéressé de savoir pourquoi.

Cela dépend vraiment du langage que vous utilisez, mais en C # et Java, je trouve les IDE bénéfiques pour:

• Naviguez rapidement vers un type sans avoir à vous soucier de l'espace de noms, du projet, etc.
• Navigation vers les membres en les traitant comme des hyperliens
• Saisie semi-automatique lorsque vous ne vous souvenez pas des noms de tous les membres par cœur
• Génération automatique de code
• Refactoring (massif)
• Organiser les importations (ajout automatique des importations appropriées en Java, à l'aide de directives en C #)
• Avertissement en cours de frappe (c'est-à-dire que certaines erreurs ne nécessitent même pas de cycle de compilation)
• Survoler quelque chose pour voir les documents
• Garder une vue des fichiers, des erreurs / avertissements / console / tests unitaires, etc. et du code source tous sur l'écran en même temps d'une manière utile
• Facilité d'exécution des tests unitaires à partir de la même fenêtre
• Débogage intégré
• Contrôle de source intégré
• Navigation vers l'endroit où une erreur de compilation ou une exception d'exécution s'est produite directement à partir des détails de l'erreur.
• Etc!

Tout cela fait gagner du temps. Ce sont des choses que je pourrais faire manuellement, mais avec plus de douleur: je préfère coder.

Achèvement du code. Cela aide beaucoup à explorer le code.

La réponse courte à la raison pour laquelle j'utilise un IDE est la paresse.

Je suis une âme paresseuse qui n'aime pas faire les choses de manière difficile quand il y a un moyen facile de le faire à la place. Les IDE rendent la vie facile et nous plaisent donc aux gens paresseux.

Au fur et à mesure que je tape du code, l'EDI vérifie automatiquement la validité du code, je peux mettre en surbrillance une méthode et appuyer sur F1 pour obtenir de l'aide, cliquer avec le bouton droit et sélectionner "aller à la définition" pour aller directement à l'endroit où il est défini. J'ai appuyé sur un bouton et l'application, avec le débogueur automatiquement attaché, est lancée pour moi. Et donc la liste continue. Tout ce qu'un développeur fait au quotidien est regroupé sous un même toit.

Il n'est pas nécessaire d'utiliser un IDE. C'est tout simplement beaucoup plus difficile de ne pas le faire.

Je ne pense pas qu'il soit juste de faire le classique "éditeur de texte et fenêtre de console vs IDE" quand "éditeur de texte" est vraiment emacs. La plupart des fonctionnalités typiques d'IDE: s se trouvent également dans emacs. Ou peut-être même qu'ils sont originaires de là-bas, et les IDE modernes sont principalement des améliorations / simplifications d'interface.

Cela signifie que pour la question d'origine, la réponse n'est pas aussi claire. Cela dépend de la façon dont les utilisateurs du site en question utilisent emacs, s'ils l'utilisent principalement comme éditeur de texte, ou s'ils se mettent à fond et utilisent des scripts personnalisés, apprennent les commandes des modes appropriés, connaissent le balisage de code, etc.

J'en viens à cette question dans la direction opposée. J'ai grandi dans la programmation avec très peu d'arrêts au pays Makefile + Emacs. Depuis mon tout premier compilateur sous DOS, Microsoft Quick C, j'avais un IDE pour automatiser les choses. J'ai passé de nombreuses années à travailler dans Visual C ++ 6.0, et après avoir obtenu mon diplôme en Enterprise Java, j'ai travaillé avec Borland JBuilder, puis j'ai opté pour Eclipse, qui est devenu très productif pour moi.

Tout au long de mon auto-apprentissage initial, de mes études collégiales et maintenant de ma carrière professionnelle, j'ai appris que tout développement logiciel majeur effectué uniquement dans l'IDE devient contre-productif. Je dis cela parce que la plupart des IDE veulent que vous travailliez dans leurstyle particulier de I-control-how-the-world-works. Vous devez découper et découper vos projets en fonction de leurs lignes. Vous avez géré vos builds de projet en utilisant leurs boîtes de dialogue étranges. La plupart des IDE gèrent mal les dépendances de construction complexes entre les projets, et les dépendances peuvent être difficiles à obtenir à 100%. J'ai été dans des situations où les IDE ne produiraient pas de build fonctionnel de mon code à moins que je fasse un Clean / Rebuild All. Enfin, il existe rarement un moyen propre de déplacer votre logiciel hors du développement et vers d'autres environnements comme le contrôle qualité ou la production à partir d'un IDE. C'est généralement une fête cliquable pour construire toutes vos unités de déploiement, ou vous avez un outil maladroit que le vendeur IDE vous donne pour regrouper des trucs. Mais,

J'ai appris que, pour faire du développement à grande échelle avec une équipe, nous pouvons être les plus productifs si nous développons notre code à l'aide d'un IDE et faisons toutes nos builds à l'aide de scripts de ligne de commande écrits manuellement. (Nous aimons Apache Ant pour le développement Java.) Nous avons constaté que l'exécution de nos scripts à partir de l'EDI n'est qu'un simple clic ou un cauchemar d'automatisation pour les builds complexes, il est beaucoup plus facile (et moins perturbateur) d'alt + tabuler vers un shell et exécutez les scripts là-bas.

Les constructions manuelles nous obligent à passer à côté de certaines des subtilités de l'IDE moderne comme la compilation en arrière-plan, mais ce que nous gagnons est beaucoup plus critique: des constructions propres et faciles qui peuvent vivre dans plusieurs environnements. La "construction en un clic" dont tous ces gars agiles parlent? Nous l'avons. Nos scripts de construction peuvent également être directement appelés par des systèmes d'intégration continue. La gestion des builds via une intégration continue nous permet de planifier et de migrer de manière plus formelle vos déploiements de code vers différents environnements, et nous permet de savoir presque immédiatement quand quelqu'un vérifie un code incorrect qui rompt les tests de build ou unitaires.

En vérité, mon rôle de construire loin de l'IDE ne nous a pas trop fait de mal. Les outils d'intellisense et de refactoring dans Eclipse sont toujours complètement utiles et valides - la compilation en arrière-plan sert simplement à prendre en charge ces outils. Et, le découpage particulier des projets d'Eclipse a été un très bon moyen de décomposer mentalement nos ensembles de problèmes d'une manière que tout le monde peut comprendre (encore un peu verbeux à mes goûts cependant). Je pense que l'une des choses les plus importantes à propos d'Eclipse est l'excellente intégration SCM, c'est ce qui rend le développement d'équipe si agréable. Nous utilisons Subversion + Eclipse, et cela a été très productif et très facile de former nos employés à devenir des experts.

En tant qu'auteur de la réponse que vous mettez en évidence dans votre question, et il est vrai que j'y arrive un peu tard, je dois dire que parmi les nombreuses raisons qui ont été énumérées, la productivité d'un développeur professionnel est l'une des plus compétences hautement considérées.

Par productivité, je veux dire la capacité de faire votre travail efficacement avec les meilleurs résultats possibles. Les IDE permettent cela à plusieurs niveaux. Je ne suis pas un expert Emacs, mais je doute qu'il ne manque aucune des fonctionnalités des principaux IDE.

La conception, la documentation, le suivi, le développement, la construction, l'analyse, le déploiement et la maintenance, les étapes clés d'une application d'entreprise, peuvent tous être effectués au sein d'un IDE.

Pourquoi n'utiliseriez-vous pas quelque chose d'aussi puissant si vous avez le choix?

À titre expérimental, engagez-vous à utiliser un IDE pendant, disons, 30 jours et voyez comment vous vous sentez. J'aimerais lire vos réflexions sur l'expérience.

Avoir un IDE présente les avantages suivants:

• La compilation est généralement "à la volée", ce qui signifie qu'il n'est plus nécessaire de passer à la ligne de commande pour compiler
• Le débogage est intégré, et l'avoir dans un IDE signifie que le débogueur d'étape utilise réellement votre éditeur sur place pour vous montrer visuellement quel code est exécuté
• Les IDE ont généralement une connaissance plus sémantique de la langue dans laquelle vous travaillez et peuvent vous montrer des problèmes possibles lors de la frappe. La refactorisation est beaucoup plus puissante que la «recherche de remplacement».

Il y a beaucoup plus, vous devriez peut-être essayer.

Les IDE sont essentiellement:

• Editeur avec complétion de code, refactoring et documentation
• Débogueur
• Explorateur de système de fichiers
• Client SCMS
• Outil de construction

le tout dans un seul paquet.

Vous pouvez avoir tout cela (et quelques autres) en utilisant des outils séparés ou tout simplement un grand éditeur programmable et des outils supplémentaires, comme Emacs (Vim aussi mais avec un peu moins d'IDE IMO).

Si vous vous retrouvez à basculer beaucoup entre un utilitaire et le suivant qui pourraient être intégrés dans l'environnement ou si vous manquez certaines des capacités répertoriées ici (et plus complètement dans d'autres articles), il est peut-être temps de passer à un IDE (ou pour améliorer l'IDEabilité de votre environnement en ajoutant des macros ou autre). Si vous vous êtes construit un «IDE» (dans le sens que je mentionne ci-dessus) en utilisant plus d'un programme, il n'est pas nécessaire de passer à un IDE réel.

Éclipse:

Avoir du code en surbrillance, compiler en arrière-plan, signaler mes erreurs au fur et à mesure.

Intégration avec javadoc, suggérant des noms de variables avec ctrl-Space.

Lorsque je compile, j'obtiens des erreurs juste là. Je peux double-cliquer sur une erreur et elle affiche la ligne appropriée.

Vraiment bien intégré à JUnit, ctrl-F11 exécute le test, me dit que les tests ont échoué. S'il y a une exception dans la fenêtre de sortie, je peux double-cliquer sur une ligne et m'amène à la ligne qui a échoué. Non seulement cela, mais ctrl-F11 s'assure que tout est compilé avant d'exécuter les tests (ce qui signifie que je n'oublie jamais de le faire).

Intégration avec ant. Une seule commande pour créer et déployer l'application.

Intégration avec les débogueurs, y compris le débogage à distance des serveurs Web.

Outils de refactorisation FANTASTIQUE, recherche de références à une section de code. M'aide à connaître l'impact d'un changement.

Dans l'ensemble, cela me rend plus productif.

J'ai utilisé Emacs comme environnement principal pour le développement et le courrier / actualités pendant environ 10 ans (1994-2004). J'ai découvert le pouvoir des IDE lorsque je me suis forcé à apprendre Java en 2004, et à ma grande surprise, j'ai vraiment aimé l'IDE ( IntelliJ IDEA ).

Je n'entrerai pas dans des raisons spécifiques car beaucoup d'entre elles ont déjà été mentionnées ici - rappelez-vous simplement que les différentes personnes aiment différentes fonctionnalités. Un collègue et moi avons utilisé le même IDE, nous n'avons utilisé qu'une fraction des fonctionnalités disponibles, et nous ne nous aimions pas mutuellement d'utiliser l'IDE (mais nous aimions tous les deux l'IDE lui-même).

Mais il y a un avantage avec les IDE par rapport aux environnements liés à Emacs / Vim sur lesquels je veux me concentrer: vous passez moins de temps à installer / configurer les fonctionnalités que vous souhaitez.

Avec Wing IDE (pour Python), je suis prêt à commencer à développer 15-20 minutes après l'installation. Je ne sais pas combien d'heures il me faudrait pour que les fonctionnalités que j'utilise soient opérationnelles avec Emacs / Vim. :)

Cela conduit définitivement à une amélioration de la productivité pour moi. Au point où je code même des applications Linux dans Visual Studio sur Vista, puis j'utilise une machine virtuelle Linux pour les construire.

Vous n'avez pas à mémoriser tous les arguments d'un appel de fonction ou de méthode, une fois que vous commencez à le taper, l'EDI vous montrera quels arguments sont nécessaires. Vous obtenez des assistants pour définir les propriétés du projet, les options du compilateur, etc. Vous pouvez rechercher des éléments dans l'ensemble du projet au lieu de simplement le document ou les fichiers actuels dans un dossier. Si vous obtenez une erreur du compilateur, double-cliquez dessus et vous accédez directement à la ligne incriminée.

Intégration d'outils tels que les éditeurs de modèles, la connexion et la navigation dans des bases de données externes, la gestion de collections de "snippets" de code, des outils de modélisation GUI, etc. temps et maintient le processus de développement plus efficace.

Il peut y avoir différentes raisons pour différentes personnes. Pour moi, ce sont les avantages.

1. Fournit une sensation intégrée au projet. Par exemple, j'aurai tous les fichiers de projets associés en vue unique.
2. Fournit une productivité de code accrue comme
   1. Mise en évidence de la syntaxe
   2. Renvoi d'assemblages
   3. Intellisense
   4. Vue centralisée de la base de données et des fichiers d'interface utilisateur associés.
   5. Fonctionnalités de débogage

À la fin de la journée, cela m'aide à coder plus rapidement que je ne peux le faire dans un bloc-notes ou un clavier. C'est une assez bonne raison pour moi de préférer un IDE.

Un IDE peut être un choix «supérieur» en fonction de ce qu'un développeur essaie d'accomplir.

Un éditeur de texte peut être «supérieur» car les IDE sont généralement orientés vers une (ou une petite sélection) de langues.

Si un développeur passe la plupart de son temps dans une seule langue ou un `` cluster '' de langages associés (comme C # et T-SQL), dans un système d'exploitation, les outils de conception d'interface graphique, de débogage, d'intellisense, de refactorisation, etc. proposés par un bon IDE peut être très convaincant. Si, par exemple, vous passez la plupart de votre temps à travailler dans VB.NET, avec peut-être un peu de T-SQL de temps en temps, dans un environnement Windows, alors vous seriez assez idiot de ne pas regarder Visual Studio ou un IDE comparable .

Je n'ai aucun préjugé envers ceux qui préfèrent les IDE ou les éditeurs de texte, les deux peuvent être très productifs et utiles s'ils sont bien appris !

Je pense que cela a principalement à voir avec la portée de la sensibilisation du développeur. L'IDE fournit une vue macroscopique du contexte de travail du développeur. Vous pouvez voir simultanément les hiérarchies de classes, les ressources référencées, les schémas de base de données, les références d'aide du SDK, etc. Et avec tant de choses affectées et affectant vos frappes de touches et le volume croissant d'architectures et d'intersections architecturales, il devient de plus en plus difficile à travailler uniquement à partir d'un îlot de code à la fois.

OTOH, "juste moi et vim et les pages de manuel" me donne une vue microscopique beaucoup plus fine - mais intense et précise - de mon travail. C'est correct si j'ai une base de code très cohérente, bien partitionnée et bien couplée, construite dans une seule langue avec un ensemble de bibliothèques statiques à partir desquelles travailler - ce n'est pas votre situation typique, d'autant plus que la taille des équipes de développement augmente et remodèle la structure du code au fil du temps, de la distance et des préférences personnelles.

Je travaille actuellement sur des projets dans Flex et .NET. L'une des choses les plus intéressantes à propos de Flex est le peu de façons différentes de réaliser une chose standard - extraire des données d'une base de données, ouvrir / fermer / lire / écrire un fichier, etc. (Pourtant, j'utilise Flex Builder / Eclipse IDE - un exemple typique de poids lourd comme VS, parce que j'apprends toujours les bases et j'ai besoin des roues d'entraînement. Je m'attends à évoluer de nouveau vers vim une fois que je serai confiant dans mes modèles.) Dans cette vue, je peux faire ce que Je dois faire professionnellement en sachant très bien certaines choses.

OTOH, je ne peux pas imaginer arriver à ce point avec .NET parce que la vue que je dois maintenir continue de s'étendre et de changer. Il y a beaucoup moins d'intégrité conceptuelle, et sur plusieurs développeurs sur un projet sur plusieurs mois, beaucoup moins de cohérence - mais l'IDE le supporte, peut-être l'encourage. Le développeur a donc vraiment besoin (et peut plus facilement) de connaître bien plus de choses de manière adéquate. Ce qui a également l'avantage de les aider à répondre (ou même à comprendre) un pourcentage beaucoup plus élevé des questions sur StackOverflow. C'est-à-dire que nous pouvons avoir une pile de connaissances plus approfondie. Et nous pouvons répondre à une plus grande variété d'annonces recherchées.

Les choses peuvent aller trop loin dans les deux sens. Peut-être qu'avec la portée "éditeur uniquement", c'est comme "si vous n'avez qu'un marteau, tout ressemble à un clou". Avec l'approche IDE, pour tout ce que vous souhaitez fixer ensemble, vous avez un large choix de fixations et de gammes d'outils associées au choix - naux / marteaux, vis / tournevis, boulons / clés, adhésifs / pistolets à colle / pinces, aimants , et ainsi de suite - le tout à portée de main (avec un assistant pour vous aider à démarrer).

Ne le considérez pas comme exclusif. Utilisez l'IDE pour les avantages qu'il offre et passez à l'éditeur de texte vim / préféré lorsque vous avez besoin d'une attention particulière.

Je trouve l'EDI meilleur pour refactoriser et parcourir et déboguer et pour savoir quoi faire. De petites choses sont ensuite faites directement dans l'IDE, de grandes choses que je retourne à vim pour terminer le travail.

En plus des autres réponses, j'aime combiner la puissance de développement d'un IDE avec la puissance d' édition de Vim en utilisant quelque chose comme ViPlugin pour Eclipse .

IntelliSense , le débogueur intégré et la fenêtre immédiate me rendent énormément plus productif ( Visual Studio 2008 ). Avec tout à portée de main, je peux garder la grande majorité d'un énorme projet à l'intérieur de ma tête tout en écrivant du code. Microsoft peut continuer à laisser tomber la balle sur leurs systèmes d'exploitation, mais Visual Studio est l'un des meilleurs produits jamais développés.

Je ne comprends pas ce que vous demandez. Vous demandez "Dois-je utiliser un IDE au lieu de ...", mais je ne comprends pas quelle est l'alternative - Vim et Emacs remplissent de nombreuses fonctions que n'importe quel IDE vous donnera. Le seul aspect qu'ils ne gèrent pas qu'un IDE plus grand peut être des choses comme les concepteurs d'interface utilisateur. Ensuite, votre question se résume simplement à "quel IDE dois-je utiliser" avec des arguments à faire pour le domaine plus simple de Vim et Emacs.

Pour moi, un IDE est meilleur car il permet une navigation plus rapide dans le code, ce qui est important si vous avez quelque chose en tête à implémenter. Supposons que vous n'utilisiez pas d'IDE, il faut plus de temps pour arriver à destination. Vos pensées peuvent être interrompues plus souvent. Cela signifie qu'il faut appuyer sur plus de clics / plus de touches. Il faut se concentrer davantage sur la façon de mettre en œuvre les choses. Bien sûr, vous pouvez également écrire des choses, mais il faut ensuite basculer entre la conception et la mise en œuvre. En outre, un concepteur d'interface graphique fait une grande différence. Si vous le faites à la main, cela peut prendre plus de temps.

Les IDE basés sur GUI comme Visual Studio et Eclipse ont plusieurs avantages par rapport aux IDE basés sur du texte comme Emacs ou vim en raison de leurs capacités d'affichage:

• Aperçu WYSIWYG et édition en direct pour la conception de l'interface graphique
• Éditeurs de propriétés efficaces (par exemple, sélection des couleurs à l'aide d'une palette graphique, y compris le positionnement des arrêts de dégradé, etc.)
• Représentation graphique des contours de code, des interrelations de fichiers, etc.
• Utilisation plus efficace de l'espace d'écran pour afficher les points d'arrêt, les signets, les erreurs, etc.
• Meilleure prise en charge du glisser-déposer avec le système d'exploitation et d'autres applications
• Édition intégrée de dessins, d'images, de modèles 3D, etc.
• Affichage et modification des modèles de base de données

Fondamentalement, avec un IDE basé sur une interface graphique, vous pouvez obtenir des informations plus utiles à l'écran à la fois et vous pouvez afficher / modifier des parties graphiques de votre application aussi facilement que des parties de texte.

L'une des choses les plus intéressantes à vivre en tant que développeur consiste à modifier une méthode qui calcule certaines données et à voir la sortie en direct de votre code affichée graphiquement dans une autre fenêtre, tout comme votre utilisateur le verra lorsque vous exécuterez l'application. Maintenant, c'est l'édition WYSIWYG!

Les IDE basés sur du texte comme Emacs et vim peuvent ajouter des fonctionnalités telles que la complétion de code et la refactorisation au fil du temps, donc à long terme leur principale limitation est leur modèle d'affichage basé sur du texte.

J'utilise aussi presque exclusivement Vim (presque parce que j'essaie d'apprendre emacs maintenant) pour tous mes trucs de développement. Je pense que la seule intuition (de l'interface graphique bien sûr) est la principale raison pour laquelle les gens aiment utiliser les IDE. En étant intuitif, peu ou pas de surcharge d'apprentissage de l'outil est requise. Moins les frais généraux d'apprentissage sont importants, plus ils peuvent faire le travail.

Un IDE permet de travailler plus rapidement et plus facilement ... J'ai remarqué que je passais beaucoup de temps à naviguer dans le code dans un simple éditeur de texte ...

Dans un bon IDE, ce temps diminue si l'IDE prend en charge le saut aux fonctions, à la position d'édition précédente, aux variables ... De plus, un bon IDE réduit le temps d'expérimentation avec différentes fonctionnalités et projets de langage, comme le temps de démarrage peut être petit.

Quelques raisons auxquelles je peux penser pour utiliser un IDE:

• L'aide intégrée est un favori.
• Le Refactor intégré avec aperçu de Visual Studio
• IntelliSense , mise en évidence de la syntaxe, facilité de navigation pour les grands projets, débogage intégré, etc. (même si je sais qu'avec les compléments, vous pouvez probablement obtenir beaucoup de cela avec Emacs et Vim ).
• De plus, je pense que les IDE ont de nos jours une base d'utilisateurs plus large et probablement plus de personnes développant des compléments pour eux, mais je peux me tromper.

Et franchement, j'aime bien ma souris. Lorsque j'utilise des éditeurs basés uniquement sur du texte, cela devient solitaire.

Gain de temps pour développer
Facilite la vie en fournissant des fonctionnalités telles que le débogage intégré, intellisense.

Il y en a beaucoup, mais je recommanderai d'en utiliser un, ils sont plus qu'évidents.

Je ne suis pas sûr qu'il existe une ligne de démarcation claire entre un éditeur de texte et un IDE. Vous avez le bloc-notes à une extrémité de l'échelle et les meilleurs IDE modernes à l'autre, mais il y a beaucoup de choses entre les deux. La plupart des éditeurs de texte ont une coloration syntaxique; les éditeurs destinés aux programmeurs ont souvent diverses autres fonctionnalités telles que la navigation facile dans le code et la saisie automatique. Emacs vous permet même d'intégrer un débogueur. Les IDE d'il y a même dix ans avaient beaucoup moins de fonctionnalités pour aider les programmeurs que ce à quoi on pourrait s'attendre d'un éditeur de texte sérieux de nos jours.

Ma principale raison d'en utiliser un est lorsque le code dépasse 100 fichiers.

Bien que les ctags puissent faire le travail, certains IDE ont un assez bon moyen de parcourir les fichiers facilement et très rapidement.

Cela vous fait gagner du temps lorsque vous avez beaucoup de travail à faire.

Pour moi, c'est juste la version GUI de tout ce que nous faisions au bon vieux temps du terminal. Je conviendrai toujours que les IDE ne sont pas très supérieurs car ils cachent beaucoup de choses, en particulier en ce qui concerne les liens, mais ils ont un avantage notable dans certains cas, par exemple avec certaines plates-formes de développement comme Qt.

Certains IDE, comme les visuels des autres, semblent même analyser votre code lorsque vous le tapez et détecter les erreurs avant même de compiler: il semble logique que seul un IDE puisse travailler en étroite collaboration avec un compilateur pour détecter immédiatement le problème dans la source tapée.

Ma réponse folle que la guerre de flamme IDE / ligne de commande existe est simplement parce que le bâtiment exécutable C / C ++ n'est pas très bien géré d'un point de vue standard, contrairement au langage D; chaque plate-forme gère la compilation / liaison / etc à sa manière, donc pour le rendre moins compliqué, ils font un IDE.

De votre point de vue, il pourrait être plus simple d'utiliser la ligne de commande, s'il n'y avait eu qu'un seul compilateur avec des options standard, cela aurait été facile, mais la vérité est que C / C ++ est flexible, donc au final, toutes les plateformes faites-le à leur façon, d'où l'IDE pour ne pas gaspiller à expliquer comment le faire.

Si vous pouvez apprendre comment un exécutable parle au noyau ou si vous savez quelque chose sur la conception du compilateur, il y a peut-être un moyen de travailler avec une ligne de commande appropriée, mais je doute que vous l'ayez.

Microsoft ou Apple, tous mauvais qu'ils soient, doivent proposer un moyen simple de créer une application sans entrer dans les détails, et puisque la construction d'une application dépend directement de l'architecture du système d'exploitation, elle ne sera guère "standard" comme la ligne de commande est.

Pour mettre les applications simples, grandes et complexes où vous ne voulez pas creuser trop profondément dans ce qu'il fait -> IDE, petits morceaux de logiciel ou conception logicielle de système simple -> ligne de commande. Sauf bien sûr ces bibliothèques astucieuses qui intègrent un Makefile, mais c'est une autre histoire.

Je pense aussi que les IDE sont utilisés lorsque l'application livrée a quelque chose à voir avec, ironiquement, une interface graphique ou quelque chose qui a une interface ou est directement lié à un système d'exploitation, donc encore une fois, c'est aussi pour les personnes qui utiliseront une interface utilisateur / interface graphique sans le savoir comment cela fonctionne, tandis que les personnes qui programmeront les systèmes n'auront pas besoin de tout.

L'IDE n'est que de la merde moderne, mais je pense que dans 100 ans, la ligne de commande existera toujours.

J'aime un IDE car il met beaucoup de fonctionnalités à portée de main. L'édition / la compilation / la visibilité des fichiers dans le projet sont toutes des choses que j'apprécie dans un IDE. J'utilise Visual Studio maintenant, mais dans une ancienne vie, j'utilisais SlickEdit et j'ai constaté que cela rendait mon processus de développement plus rationalisé que lorsque je ne l'utilisais pas.

Il n'y a qu'une seule chose à considérer lorsque vous décidez d'utiliser ou non un IDE, et c'est si cela vous rend plus productif ou non.

Question courte donc réponse courte :)

Cela dépend fortement de ce que vous faites et de la langue dans laquelle vous le faites. Personnellement, j'ai tendance à ne pas utiliser d'IDE (ou "mon IDE se compose de 3 xterms exécutant vim, un exécutant un client de base de données et un avec un bash prompt or tailing logs ", selon la façon dont vous définissez largement" IDE ") pour la plupart de mon travail, mais, si je devais me retrouver à développer une interface graphique native de plate-forme, j'atteindrais alors un IDE adapté à la langue dans un instant - IMO, IDE et édition de formulaire graphique sont clairement faits l'un pour l'autre.