Discussion :

[xelab]

Je développais beaucoup sur IDE avant, mais depuis que j'ai découvert SublimeText, je m'en sers beaucoup plus qu'Eclipse ou Visual. Le fait de pouvoir éditer plusieurs lignes à la fois permet de gagner un temps gigantesque par rapport à un éditeur classique. Pour les langages de script tels que JS ou Ruby, c'est une grosse tuerie qui a du multiplier ma productivité par 5.

Si on regarde l'article initial de ce thread, Sublime Text fait ce que les IDE font, donc pour moi Sublime text est un IDE.

[tiresias54]

codeblocks pour C++

Pour le reste vim.

[esperanto]

@esperanto :
Pour mes applications bases de données, c'est Delphi (XE2) sous Windows et Lazarus sous LINUX. Et mon langage préféré, c'est Pascal.

Pourquoi pas lazarus sous windows aussi? Au moins tu serais sûr que le même code compile sur les deux plateformes, alors qu'avec Delphi, tu risques d'ajouter des extensions propriétaires donc non portables...

[esperanto]

Je ne comprend pas comment des gens peuvent dire qu'ils sont plus productif sans IDE qu'avec. Quand en 3 clics, on a notre classe qui se génère toute seule avec toutes ses dépendances et tout, on est forcement plus productif. Je peux comprendre qu'on peut être plus à l'aise sur Notepad++ mais on ne sera pas plus productif.
(Je parle en Java, c'est sans doute moins vrai en Php)

Tiens, il s'est fait attendre l'argument économique. T'es payé à la ligne de code?

Moi j'ai encore plus efficace : des templates de projets en fonction des 3-4 situations rencontrées chez le client, pour chaque objet de la base de données en un clic je te génère les 4 classes create read update delete. Qui dit mieux?

[SurferIX]

... depuis que j'ai découvert SublimeText, ... le fait de pouvoir éditer plusieurs lignes à la fois permet de gagner un temps gigantesque par rapport à un éditeur classique. Pour les langages de script tels que JS ou Ruby, c'est une grosse tuerie qui a du multiplier ma productivité par 5.

Vim fait ça depuis bientôt plus de dix ans... comme l'autocomplétion d'ailleurs...

Moi j'ai encore plus efficace : des templates de projets en fonction des 3-4 situations rencontrées chez le client, pour chaque objet de la base de données en un clic je te génère les 4 classes create read update delete. Qui dit mieux?

Moi : je ne clique pas, je n'enlève même pas les mains du clavier : j'appuie sur tab et vim fait ce que tu dis tout en s'adaptant au besoin (= tu tape un truc à un endroit, ça le met automatiquement partout à tous les endroits que tu as prédéfini).

[Zuthos]

Pour ma part, j'utilise VIM, sauf pour LATEX. Je n'ai pas encore réussis a me passer de TEXMAKER

[buse974]

J'ai aussi utilisé la console pendant très longtemps pour GIT (d'ailleurs je l'utilise encore quand je code sous Sublime Text). Mais sincèrement, teste une fois dans un IDE, c'est le pied. Ne serait-ce que pour sélectionner/dé-selectionner facilement des fichiers dans le commit, voir facilement les différences, ....

Effectivement plusieurs personnes de mon équipe utilisent GIT dans leur IDE (Eclipse ou Netbeans), et certaine opération sont très conviviale.
C'est pour cela que même si je ne l'utilise pas, je pense que le choix d'utiliser un plugin est justifié et à du sens.
Ensuite, je pars toujours du principe que ces plugins restent des aides et que l'on doit savoir utiliser GIT de façon basique en console.

Sinon petite question comme je vois que certains utilisent Eclipse pour coder sous ZF2. Au boulot, nous avons une licence Zend Studio (que je trouve assez cher pour ce qu'il fait). Est-ce qu'il apporte vraiment quelque chose par rapport à un Eclipse classique ? N'ayant jamais testé Eclipse pour faire du PHP, je me demande quels sont les fonctionnalités supplémentaires.

Dans mon premier taf j'utilisai Zend Studio (basé sur Eclipse), Actuellement on a fait le choix de ne pas l'utiliser.
Les raisons sont que notre utilité de l'IDE resté assez classique et que Eclipse ou Netbeans satisfait largement nos besoins et de plus gratuitement.
Après le choix est rapidement fait, si tu fais une liste de toutes les fonctionnalités que tu utilises dans ZStudio, peut-être te rendras-tu compte que finalement éclipse (avec quelques plugins) fait la même chose.

Pour eclipse j'utilise au minimum :
PDT https://www.eclipse.org/pdt/
Générer les accesseurs http://pdt.plugins.e-surf.pl/index.php

Ensuite tu as toujours EGit pour git http://www.eclipse.org/egit/

[nchal]

Tiens, il s'est fait attendre l'argument économique. T'es payé à la ligne de code?

Moi j'ai encore plus efficace : des templates de projets en fonction des 3-4 situations rencontrées chez le client, pour chaque objet de la base de données en un clic je te génère les 4 classes create read update delete. Qui dit mieux?

J'appelle ça l'industrialisation du code, et oui, ce serait excellent d'avoir qqchose comme ça qui marche bien. Pourquoi s’embêter à coder les parties barbantes du code alors qu'on pourrait passer du temps à coder les parties intéressantes ?

Et je suis payé à la satisfaction client. Si j'arrive chez le client et je lui dit : "je peux faire ça en 2 mois pour X euros" au lieu de "je peux faire ça en 1 ans pour X euros", alors oui, je gagne plus d'argent.

[Logan Mauzaize]

Je te l'accorde une machine ne sera pas d'aussi bon conseil qu'un autre codeur. Cependant je voudrai souligner que l'EDI ne décide pas seul comment faire ces suggestions. Paramétrer son EDI en fonction de ses propres standards/règles ou celles de son équipe permet de voir pendant sa rédaction du code si l'on fait des choses de travers. Nous somme développeurs et nous savons a quel point un code écrit reste souvent in-touché par la suite. Surtout si ce sont d'autres développeurs qui ont affaire a celui-ci. Je pense qu'il est donc primordial de rédiger un code qui, dès le départ s'accorde sur des conventions.

Déjà faudrait définir les limites entre un EDI et un éditeur de texte.
Parce que si je regarde le texte d'introduction de ce débat, la plupart des fonctions citées (navigation dans le code, accès à des outils externes...) existent dans Notepad++, soit directement soit sous forme de plugin. Pourtant je suis sûr que la majorité d'entre vous l'ont classé dans la catégorie des "simples éditeurs de texte".

Avec un IDE, je n'ai pas besoin de définir ses macros. Et à mon sens c'est cela la grande différence. Autrement la console est aussi un IDE, je peux écrire du code, le compiler, etc.
La notion d'intégrer est importante. A ce titre (X)Emacs et (G)Vim avec leurs systèmes d'extensions sont beaucoup plus proches d'un IDE que Notepad++ qui malgré ses macros ne pourra pas se connecter à une base de données, exécuter une requête de sélection et afficher le résultat. Vérifier le code et surligner les erreurs, puis ensuite déclencher uniquement la compilation des dépendances tout en gérant un historique locale des sources. Le principe restera toujours d'afficher le contenu texte d'un fichier.

Les "bonnes pratiques" appliquées sans discernement, automatiquement, je m'en méfie comme de la peste. Exemple vécu il y a quelques années: un programme externe de contrôle des "bonnes pratiques" considérait qu'une fonction retournant un tableau ne devait jamais renvoyer null, donc le logiciel remplaçait systématiquement par new Object[0]. Sauf qu'une de nos méthodes surchargeait son homonyme provenant d'un framework, où justement la valeur null avait une signification très précise : modif automatique, plus de deux jours pour trouver la cause du bug...

Une bonne pratique appliquée sans discernement et automatiquement aurait été d'écrire un test auto (unitaire et/ou d'intégration) suite à l'introdution du framework ;-)
Concernant le fond, je pense sincèrement que les outils de vérifications (statiques ou dynamiques) sont effectivement à prendre avec discernement :

• Un avertissement d'un analyseur statique de code, c'est un avertissement ou une indication. Rien de plus. D'ailleurs la plupart des outils permettent d'indiquer que tu "assumes" cette indication. Généralement, tu remercieras l'outil (ou ce sera ceux qui passeront derrière toi).
• Une couverture de code à 70% ne veut pas dire que tes tests sont pourris. Ca te dit juste va voir ce qui n'est pas couvert. D'ailleurs je m'intérresse plus à ce qui n'est pas couvert qu'à ce qui l'est.
• Un test qui passe, ne veut pas dire que ton code marche. Sinon les bugs ca n'existerait pas.
• Un test qui passe pas, ca ne veut pas dire non plus que ton code ne marche pas. Le test est peut-être tout simplement en cause.
• ...

Un autre problème avec les EDI, c'est que le code peut en devenir dépendant, même de façon involontaire. En ce moment je travaille sur des adaptations d'un logiciel libre en Java; projet écrit avec Netbeans mais il y a un beau build.xml donc je peux me passer de Netbeans si je veux... sauf qu'ils ont utilisé le générateur de code pour les fenêtres, donc même si je peux modifier les .java à la main, je dois aller regarder l'équivalent dans le .form sinon incohérence entre le .java et le .form; or les deux sont dans le git (n'ai-je pas toujours dit qu'on ne met JAMAIS une source et son résultat dans le gestionnaire de version?) donc je dois m'assurer à chaque fois que les deux disent la même chose sinon au prochain git rebase c'est la désychro assurée! Du coup mieux vaut utiliser Netbeans au moins pour la partie graphique : on a ici créé une dépendance, on impose involontairement l'EDI à tous les développeurs (alors que pour la partie non-graphique, le build.xml assure justement une certaine indépendance, dommage)

C'est un choix qui se justifie, peut-être pas pour toi ; Mais tu n'es pas le seul intervenant. Le discernement s'impose ;-)

D'accord pour utiliser un EDI quand j'ai à faire une grosse modif qui implique 15 fichiers - ça me permet de modifier une méthode et de tout de suite switcher vers ses utilisations pour faire les adaptations idoines par exemple. Mais il faut absolument que, dans le même projet, on ait la possibilité de se passer de l'EDI - d'une part parce qu'à l'inverse, pour une modif urgente de trois lignes je ne veux pas avoir à attendre qu'il ait fini de se charger, et aussi parce que si le projet est dans un gestionnaire de version, je pourrais avoir à le modifier depuis un autre ordinateur où l'EDI n'est pas installé!

Si tu n'as pas 5 minutes de patience alors abstiens-toi de faire le moindre code. Tu dois faire preuve de discernement et ne pas faire dans l'urgence. Sauf à vouloir que les choses soient mal faites ?

Ah oui encore une chose, les EDI qui génèrent du code favorisent la standardisation, mais à l'inverse, ils favorisent aussi l'application à la lettre de paradigmes mal compris et sans réflexion. Le cas le plus flagrant étant pour moi l'utilisation des accesseurs (get et set). A l'école on nous dit qu'il ne faut pas laisser les variables publiques mais toujours les protéger par des accesseurs. L'ennui, c'est que j'ai l'impression que la plupart des gens ont oublié pourquoi: ça permet de changer l'implémentation sans changer l'interface. Seulement voila: les EDI génèrent le plus souvent des POJO (beans ayant uniquement des accesseurs) ce qui fait que quand on change une variable, ni une ni deux on supprime ses accesseurs et on recrée ceux de la nouvelle variable - et l'interface n'est plus conforme à l'analyse de départ, justement ce que les accesseurs étaient supposés nous éviter!

La "standardisation" des méthodes get/set est surtout dû à tous les composants qui dépendent du standard POJO/bean. Et rien ne t'empêche alors de rajouter les méthodes get/set manquantes mais qui exploiteraient tes nouveaux attributs.

Concernant la génération de code, cela peut également être un gain de temps considérable. A titre d'exemple, j'ai une dizaine de concept et une cinquantaine de bean. Pour la plupart des beans, j'ai créé deux-trois entités (classes) mappés à des bases de données différentes et un "fluent builder". J'aurais bien aimé pouvoir générer tout ca et qu'à chaque fois que je touche mon concept (ou l'un de ses beans), ca se répercute sur toutes les classes.
Même problème avec Java FX, où tu dois générer le getter/setter et l'accès à la propriété.

Le dernier Linux mag 172 m'a encore appris des choses même après deux ans de pratique !

C'est une blague ?

Par ailleurs, l’utilisation des IDE encourage le style « type and compile », chose qui n’est souvent pas envisageable sur de gros projet. Je préfère la philosophie « diviser pour régner » et donc utiliser plusieurs « petits » outils pour arriver à mes fins

Il sera judicieux de noter que les concepteurs de compilateurs ont une la même idée via la compilation "modulaire" et incrémentale

Je ne comprend pas comment des gens peuvent dire qu'ils sont plus productif sans IDE qu'avec. Quand en 3 clics, on a notre classe qui se génère toute seule avec toutes ses dépendances et tout, on est forcement plus productif. Je peux comprendre qu'on peut être plus à l'aise sur Notepad++ mais on ne sera pas plus productif.
(Je parle en Java, c'est sans doute moins vrai en Php)

Justement parce qu'ils ne font pas de Java (ou équivalent).

Tiens, il s'est fait attendre l'argument économique. T'es payé à la ligne de code?

Personnellement je suis rémunuré à l'heure (~1700h/an). Après je suis tantôt en AT (donc je suis facturé à l'heure), soit au forfait et dans ce cas ma rentabilité dépend de mon taux de production. Et comme j'aime que ma boîte touche plein de sous pour pouvoir me payer mon salaire et mes augmentations ; oui je fais attention à ce que je coûte.
Bref, voilà l'argument financier mais ce n'est pas le seul.

Le confort et l'épanouissment en sont d'autres. Par exemple, pisser de la ligne de code ce n'est pas mon tripe. Ensuite je préfère soit travailler sur de l'architecture, de la conception, de la méthode ou du code complexe. Voir faire de la veille techno ou venir discuter sur DVP ;-)

[Pierre GIRARD]

Pourquoi pas lazarus sous windows aussi? Au moins tu serais sûr que le même code compile sur les deux plateformes, alors qu'avec Delphi, tu risques d'ajouter des extensions propriétaires donc non portables...

Pourquoi pas Lazarus sous Windows aussi ?

1. J'ai Delphi depuis la version 1 jusqu'à XE2 (avant, j'avais TurboPascal) et donc ... j'y suis habitué
2. Je n'utilise pas Windows et Linux pour les mêmes raisons ni usages, donc la portabilité Windows-Linux ne me préoccupe pas (pour le moment).
3. Je n'ai pas encore réussi à retrouver toutes mes marques avec Lazarus (pour quelqu'un qui fait de la programmation occasionnellement, c'est pas si évident) et je ne retrouve pas non plus certains composants tiers (gratuits ou pas) de Delphi qui n'ont pas (je ne les ai pas trouvés) leur équivalent sous Lazarus.
4. Le jour où je passerais à 100% Lazarus sera probablement le jour où je passerais à 100% Linux.

[GuillaumeJ]

Tiens, il s'est fait attendre l'argument économique. T'es payé à la ligne de code?

Moi j'ai encore plus efficace : des templates de projets en fonction des 3-4 situations rencontrées chez le client, pour chaque objet de la base de données en un clic je te génère les 4 classes create read update delete. Qui dit mieux?

Personne n'est payé a la ligne de code - sinon, ca m'interesse comme poste je pense , mais on est payé pour être efficace, ce qui veut dire
- rapide (nous)
- fiable (notre code)
- maintenable (idem )

Pour au moins les deux premiers points, un IDE de qualité entre les mains de quelqu'un qui sait raisonnablement s'en servir, c'est incomparable vis a vis d'un éditeur de texte, au moins pour ce qui est des langages "lourds" ( comme .Net ou Java) ( et encore, le support du Javascript par Visual studio devient first-class )

Je peux pas me prononcer sur les IDE javas, mais je serai curieux de voir si quelqu'un peut me justifier qu'il est plus efficace pour faire du .Net (ou du C++ / Windows) sous un éditeur de texte que dans Visual Studio...

[abriotde]

Les EDI ont 2 défauts principaux :
1) Complexe a mettre en place (Installer, configurer, démarrer un projet avec...)
2) Gourmands en ressources

C'est pourquoi on ne peut se passer d'un éditeur de texte pour tout ce qui est développement rapide (petit projet, retouche chez sur un PC squatté, debug sur un serveur, ouverture d'un vieux projet...)
Personnellement j'utilise VIM sur le réseau et Gedit (sous Linux, il a inspiré Notepad++) et Notepad++ sous Windows.

J'utilise parfois Eclipse ou Netbeans pour de gros projet Java / C.

Il y a aussi un gain de temps a travailler avec VIM+terminal+makefile au lieu d'un Netbeans en cross-compilation. Mais c'est plus "hard".

L'avantages principal des EDI c'est qu'une partie de la complexité est caché / auto-généré (Makefile, dépendances en Java, auto-complétion... ) d'ou parfois un gain de temps important.

[katze]

- Eclipse pour presque tout.
- Notepad++ pour html/JS.

[rubmo]

Je vois que l'IDE apporte un grand nombre d'avantages, mais si on arrête d'utiliser des éditeurs de texte, notre connaissance du langage peut se limiter facilement, non?

[Pierre GIRARD]

Je vois que l'IDE apporte un grand nombre d'avantages, mais si on arrête d'utiliser des éditeurs de texte, notre connaissance du langage peut se limiter facilement, non?

Non, l'IDE permet de s'affranchir de certaines choses, mais dans tous les IDE, il y a AUSSI un éditeur qui permet d'aller beaucoup plus loin. Par exemple (comme dans mon exemple précédent) on peut ajouter un bouton, avec tout l'environnement qui va avec. Mais sans code spécifique écrit pour ce bouton, le clic sur ce bouton ... ne fait strictement rien.

[GuillaumeJ]

Je vois que l'IDE apporte un grand nombre d'avantages, mais si on arrête d'utiliser des éditeurs de texte, notre connaissance du langage peut se limiter facilement, non?

Bah.. c'est sur que par exemple avec l'Intellisence (le truc qui fait apparaitre en popup la syntaxe d'une fonction), j'ai plus besoin de retenir cette syntaxe.. D'un autre côté, est ce que ma valeur ajoutée c'est vraiment de connaitre par coeur la syntaxe de toutes les fonctions du framework officiel ? Savoir déjà que les fonctions existent, c'est suffisant. Effectivement, le jour ou je me retrouve sans mon IDE, je suis emmerdé (enfin, faut que je consulte la doc ) , mais c'est assez peu probable de se retrouver dans cette situation..

[Nekkro]

Ça varie selon le langage utilisé, mais presque pour tous j'utilise Sublime Text 3, que je conseille vivement. Rapide et efficace.

[Invité]

Tout dépend de la taille et la complexité d'un projet. Et du du contexte : travail personnel ou en entreprise ?
jEdit est pas mal avec tous ses plugins et comme il est écrit en Java, il peut tourner sous différents systèmes d'exploitation.
NetBeans et Eclipse aussi, mais faut voir les ressources consommées. De toute manière, vue l'ampleur des logiciels en terme de fonctionnalité, de complexité technique, que les
entreprises conçoivent, développent, et finissent par mettre en production, un IDE me semble vital.
Regardez sur quel type d’environnement je bosse : http://www.mainframes360.com/2010/10...-commands.html
C'est pas l'envie de changer qui me manque, c'est certain...

[esperanto]

• Un avertissement d'un analyseur statique de code, c'est un avertissement ou une indication. Rien de plus. D'ailleurs la plupart des outils permettent d'indiquer que tu "assumes" cette indication. Généralement, tu remercieras l'outil (ou ce sera ceux qui passeront derrière toi).

On est bien d'accord. Là je te parle d'un outil qui faisait la correction à notre place!

C'est un choix qui se justifie, peut-être pas pour toi ; Mais tu n'es pas le seul intervenant. Le discernement s'impose ;-)

Quand tu écris un logiciel libre tu souhaites à priori que n'importe qui puisse le modifier, pas seulement ceux qui utilisent le même EDI que toi.
Donc, laisser du code fortement lié à l'EDI, c'est restreindre le nombre de développeurs potentiels.

La "standardisation" des méthodes get/set est surtout dû à tous les composants qui dépendent du standard POJO/bean. Et rien ne t'empêche alors de rajouter les méthodes get/set manquantes mais qui exploiteraient tes nouveaux attributs.

En écrivant cela, tu viens de prouver ce que je disais: on a complètement oublié à quoi servaient les get et les set.
Le but n'est justement pas de refléter les nouveaux attributs, mais au contraire, de permettre, même en changeant les attributs, de maintenir ta classe compatible avec l'ancien code qui était habitué aux anciens attributs (que les get et set rendent donc transparents pour lui).
Avec un EDI, bien sûr que tu vas t'empresser de rajouter les get et set qui manquent, mais tu vas aussi t'empresser de supprimer les anciens et de modifier toutes les classes qui les utilisent. Rappelle-moi maintenant pourquoi on n'accède jamais directement aux attributs?

Personnellement je suis rémunuré à l'heure (~1700h/an). Après je suis tantôt en AT (donc je suis facturé à l'heure), soit au forfait et dans ce cas ma rentabilité dépend de mon taux de production. Et comme j'aime que ma boîte touche plein de sous pour pouvoir me payer mon salaire et mes augmentations ; oui je fais attention à ce que je coûte.
Bref, voilà l'argument financier mais ce n'est pas le seul.

La question était de savoir comment qualifier (ou quantifier) ce que tu appelles le taux de production. Parce qu'utiliser un EDI génial qui pour chaque clic de souris te génère une centaine de lignes de code pas du tout optimisé, c'est bien si tu mesures ton taux de production en volume de code, mais c'est très probablement un non-sens pour le client qui n'utilisera probablement que tes binaires.

[esperanto]

Pourquoi s’embêter à coder les parties barbantes du code alors qu'on pourrait passer du temps à coder les parties intéressantes ?.

Peut-être parce que si on réfléchissait un peu on se rendrait compte que sur ces parties barbantes générées automatiquement, plus de la moitié ne seront jamais utilisées?
Je prenais pour exemple le schéma create-read-update-delete, que je rencontre de plus en plus souvent dans les frameworks et où je vois donc plein de code répété à des centaines d'exemplaires, y compris le delete sur des tables où des contraintes d'intégrité l'interdisent...