Discussion :

[dragonjoker59]

Pour mes projets web (PHP, CSS, JavaScript, HTML), j'utilise essentiellement Notepad++. Je commence à essayer de me tourner vers un IDE mais pas encore trouvé chaussure à mon pied.
Pour les projets C++, sous Windows pas d'hésitation, Visual Studio (2010, 2012, 2013), sous Linux j'utiolis Code::Blocks, QtCreator me débecte (na !)

[Zefling]

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.

L'intégration de PHP est mieux foutu sous Zend Studio qu'Elipse avec le plug-in PHP, mais une fois en place, je me suis rapidement passé de Zend Studio, et finalement ça marche assez bien. Mon plus gros soucis, c'est que parfois, je ne sais pas pourquoi, sur certaines installes, il ne veut pas générer l'autocomplession. Je réinstalle et ça fonctionne. Ce n'est pas l'outil idéal, mais pour ce que j'en fais, c'est bien plus que suffisant. Il ne me maque le support de PHP 5.5 (toujours pas géré il me semble), mais comme je suis sur un serveur avec du 5.3, ça ne dérange pas.

[buxbux]

Certe le sujet de l'article peu paraître un peu de l'ordre du troll ! Cependant j'ai essayé de soulever la question suivante: "L'EDI peut-il nous accompagner dans la rédaction d'un code de meilleur qualité ?"

Hors de question. Je préfère qu'un être humain vienne m'expliquer que j'ai de "mauvaises pratiques" de codage, parce qu'on moins, l'être humain, je peux le remettre à sa place en lui prouvant que c'est lui qui a tort et qu'il ferait mieux de se mêler de ce qui le regarde, parce que si je veux moi aussi je peux aller analyser son code pour lui casser les lucioles. Mais avec un programme informatique, je ne peux pas faire cela, donc hors de question que j'utilise un logiciel, c'est à dire un truc qui n'a même pas de cerveau (faut-il le rappeler), qui prétendrait mieux savoir que moi comment je dois coder. Non mais de quoi je me mêle ?

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.

Un bon exemple de convention qui peut être prise par une équipe de dev PHP:

Après, je pense que ça dépend grandement du langage que l'on utilise.

Tout a fait. Je dirais même, comme tu et d'autres l'on fait remarquer: du langage et de la dimension du projet (complexités, nombre de classes, etc).

Mais bon... cela étant dit, les vrais programmeurs programme en assembleur... non?

[Carhiboux]

Je vais surement faire bondir pas mal de monde ne disant cela, mais je pense qu'un IDE bien configuré* est l'outil quasi indispensable du développeur moyen.

Alors certes, je connais quelques personnes qui sont capable de faire du C++ complexe avec vi... Clairement, ce n'est pas mon cas, et j'apprécie grandement le confort qu'offre un IDE pour écrire du code. Peut être effectivement que le contrecoup de ce confort est qu'on retient moins bien la structure du projet, peut être...

De plus, travaillant souvent, pour ne pas dire tout le temps, en équipe, les IDE bien configurés* offrent des avantages non négligeables tels qu'une gestion intégrée de SVN/GIT/CVS, des formateurs et vérificateurs de bonnes pratiques PMD/checkstyle/...

De même, faisant souvent de la revue de code, et repassant souvent derrière le code des autres, il est fort appréciable de pouvoir renommer une méthode et de changer tous les appels à cette méthode dans le projet en un raccourci clavier...

Bref, toutes ces taches, relativement simples en soi, mais qui détournent un développeur de ce qu'il devrait vraiment faire (une fois qu'il a sa conception!) : coder.

De même, les IDE gèrent les serveurs (tomcat, jetty, ...) sans devoir changer d'appli ou le faire manuellement. C'est un luxe et un confort qui me font gagner un temps précieux.

Pour répondre à ceux qui se demandent pourquoi certains n'aiment pas NetBeans, je peut peut être vous donner un début de réponse. Pour ma part, je n'ai pas aimé le NetBeans d'il y a 10 ans. Oui, ça peut paraitre con, mais à ce moment là, il y avait un tel fossé entre NetBeans et Eclipse que je n'ai jamais quitté Eclipse depuis. Par exemple, il y a dix ans, Netbeans ne faisait pas d'auto-compil du projet... Alors qu'Eclipse, j'avais à peine écrit la ligne de code que ça se mettait en rouge. C'est tout bête, mais lorsqu'on débute, c'est un confort appréciable. Je pense que pas mal de gens sont restés sur cette image un peu dépassée de cet IDE.

Il parait que maintenant NetBeans est au moins aussi bien que Eclipse, je n'ai jamais eu l'occasion de réessayer depuis 10 ans je l'avoue, et je veux bien le croire. Mais j'ai mes petites habitudes sur Eclipse, et cela me convient tout à fait.

Autre point qui me chiffone, c'est quand je lit que les EDI seraient trop lourds... ou trop lents. J'avoue ne pas bien comprendre. Je n'ai jamais eu des foudres de guerres comme machines, mais j'ai toujours pu faire tourner Eclipse très convenablement. Je concède qu'au démmarage, il faut parfois attendre une petite minute... mais pour une utilisation continue toute la journée... ça me gène pas vraiment.

* EDI bien configuré : Je reviens sur ce concept parce que c'est vrai que ca peut souvent être un point qui freine les utilisateurs novices, ou qui rebutent ceux qui ont toujours preféré un éditeur de texte plus simple. La configuration d'un EDI prends un peu de temps, surtout quand on découvre l'EDI en question. Mais une fois bien configuré, je n'y trouve quasiment que des avantages.

[Carhiboux]

Hors de question. Je préfère qu'un être humain vienne m'expliquer que j'ai de "mauvaises pratiques" de codage, parce qu'on moins, l'être humain, je peux le remettre à sa place en lui prouvant que c'est lui qui a tort et qu'il ferait mieux de se mêler de ce qui le regarde, parce que si je veux moi aussi je peux aller analyser son code pour lui casser les lucioles. Mais avec un programme informatique, je ne peux pas faire cela, donc hors de question que j'utilise un logiciel, c'est à dire un truc qui n'a même pas de cerveau (faut-il le rappeler), qui prétendrait mieux savoir que moi comment je dois coder. Non mais de quoi je me mêle ?

C'est une blague?

Sans vouloir être désobligeant, il me vient tout de même quelques remarques à l'esprit :

Le logiciel, lui, ne sera jamais de mauvaise foi. Soit c'est bon, soit c'est pas bon (soit c'est un bug! mais mantenant la plupart des plugins de mise en forme sont bien rodés quand même... ).

La non application de pratiques communes de codage sont une plaie sur un projet lorsque plusieurs dev n'en font qu'à leur tête. J'ai même vu un projet ou deux des devs n'ont jamais réussi à se mettre d'accord sur les normes à appliquer, chacun voulant imposer sa vue à l'autre et où ils passaient tous les deux plus de temps à remettre le code de l'autre à leur sauce qu'à avancer, l'un restait plus tard le soir pour mettre à sa sauce, l'autre arrivait tot le matin pour remettre à la sienne... Les deux ont été virés du projet, le projet s'en est beaucoup mieux porté!

L'utilisation de tels outils ne doit pas empêcher une revue de code humaine. Mais là encore, la revue de code s'en trouve simplifiée sur la mise en forme est celle que l'autre dev à lui aussi l'habitude d'avoir.

Enfin, je crois que la critique peut être constructive, et qu'elle devrait l'être plus souvent. Malheureusement, certains voulant à tout prix soit casser des lucioles soit croire qu'on veut casser les leurs...

[tralloc]

Je ne vais pas être original d'après ce que j'ai déjà lu.

Pour travailler sur un projet en Java, un IDE est nécessaire.

Pour du C un EDI léger genre CodeBlocks
Pour faire du web (html,JS,CSS) un éditeur de texte un peu avancé ou un EDI léger (genre SublimeText ou Brackets)

Pour quelques scripts pythons, un peu de xsl... Un éditeur de texte avec un peu de coloration comme gedit (mais il y a probablement des plugins pour SublimeText, ça pourrait être intéressant).

Pour éditer de gros fichiers de données, gedit ou TextPad ou notepad++ sous windows, ou Scite (le problème est la place que ça prend en mémoire, donc il faut parfois choisir un éditeur n'ayant pas les meilleures fonctionnalités mais très peu gourmand)

[air-dex]

Plus ou moins pareil que les autres :

• Un éditeur de texte pour le Quick (& Dirty) et un IDE pour des choses plus importantes. Pour l'éditeur de texte, il n'y en a qu'un seul qui vaille la peine sur Windows et c'est Notepad++ et sa robustesse légendaire. N++ est tellement robuste qu'il surpasse même certains éditeurs natifs de Linux malgré WINE qui pourrait lui poser des problèmes. Du coup sous Linux j'évite désormais gedit qui se fait surpasser par N++. J'aimerais utiliser Kate mais comme il a une fâcheuse tendance à couper les lignes, je lui préfère Geany.
• Quand je fait du C++/Qt, j'utilise Qt Creator, excellent IDE de référence qui se bonifie avec le temps.
• Pour le PHP j'utilise Netbeans ou Komodo Edit pour de plus petites choses.
• Pour le Java c'est aussi Netbeans mais Eclipse ne me dérange pas du tout. À voir ce que vaut IntelliJ IDEA.
• Quand je fais du Python, c'est Eclipse avec l'extension PyDev.

Dans tous les cas j'ai toujours un Eclipse pas loin de par son statut de "tour de Babel du développement" : quand tu veux coder dans une techno particulière, il y aura toujours un plugin Eclipse pour ça. Le pire c'est que c'est vrai.

komodo edit !

c'est un ide (léger) ou un editeur de texte au choix, stable,multi plateforme avec accès sftp intégré.

il suffit de paramétrer si oui ou non, il doit tester la syntaxe (avec même un temps de latence paramétrable pour les contrôles)

je l'utilise pour du dev html,javascript,php et rien à redire (je l'ai juste configuré avec les couleurs de type sublime text)

J'utilise un peu Komodo Edit et c'est vrai qu'il a l'air bien. Cependant, je trouve la version gratuite plutôt limitée et je me demande si la version complète vaut son prix un peu élevé. Et quid des langages autres que les autres langages Web (PHP, Ruby, HTML, CSS, JS...) ? Si Komodo Edit y excelle cela peut valoir le coup.

[Pierre GIRARD]

Réponse de Normand : Ça dépend.
- IDE pour Delphi (ou Lazarus) et aussi pour le SQL.
- Notepad++ pour du HTML.
- VI pour les scripts shell UNIX/LINUX (oui, je sais, c'est pas de la vrai programmation )

[Laurent Simon]

Perso j'utilise un peut tout, mais principalement Netbeans pour le développement et vim pour l'admin. Le seul outil que j'ai banni c'est Eclipse (pas du tout intuitif et pas stable pour moi).

[esperanto]

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".

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...

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)

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é!

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!

Donc, avant de se poser la question de l'usage ou non d'un EDI, il faut se poser la question de ce qu'est le code générique. La plupart des langages récents sont conçus pour que le code soit réutilisable, mais les EDI favorisent plutôt le code copié-collé avec ensuite une modification mineure. C'est peut-être en cela que certains peuvent juger qu'on rend les programmeurs incompétents.

[GuillaumeJ]

Autant je fais en général mon PHP du classic ASP dans NotePad++, autant pour .Net, je ne peux pas faire autrement que du Visual Studio : une fois lancé, ca tourne très vite, et les fonctionnalités font gagner énormément de temps. Ne parlons pas en plus de Resharper...

Succombant a la mode, j'ai voulu tester Sublime.. je ne dis pas que ca peut pas être bien, mais la marche a franchir pour rattraper mon aisance avec l'IDE VS était trop haute. Si je faisais du ruby, je dis pas..

[buxbux]

@esperanto Commentaire très intéressant ! Merci pour ton point de vue.

[Thylia]

J'utilise UltraEdit quasiment tout le temps, j'adore le mode colonne.
Sinon Eclipse ou Visual Studio quand je suis obligé (mais alors vraiment) de faire du dev natif (genre Androïd, BlackBerry ou Windows Phone)
Sinon sur le serveur pour avoir de la coloration syntaxique à moindre coût, j'utilise Notepad 2

Pour moi Eclipse est vraiment trop lourd, voir vomitif.

[Pierre GIRARD]

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"...

Tout le monde s'accorde à dire que Notepad++ est un outil exceptionnel. Mais même si il est très évolué, ça reste un éditeur. Pas de compilateur incorporé par exemple, aucun moyen de composer visuellement une fenêtre de dialogue (même aussi simple qu'une boite "A Propos") avec des images, des boutons, etc...

Avec un EDI, on compose visuellement son application en y ajoutant des objets texte, éditeur, commandes, accès à des bases de données, etc... tout ça graphiquement. Et on bascule du mode visualisation au mode codage simplement. Par exemple, avec Delphi, un double-clic sur un bouton "Btnx" créé une procédure BtnxClic et s'ouvre directement dans le code.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
procedure BtnxClic...
begin

end.

Et on passe de la création visuelle au codage dans l'éditeur instantanément. Difficile de comparer Notepad++ à un EDI.

Par contre, pour du HTML, c'est différent. On enregistre "Page.html", on double-clic sur "Page.html" et on visualise son travail sur le navigateur par défaut. Dans ce cas, Notepad++ devient mon outil léger, rapide et efficace préféré.

[SurferIX]

Deux mondes semblent parfois s’affronter dans l'univers de la programmation logicielle.

J'aime :
- vim
- SublimeText
- PsPad
- PhpStorm.

Amusant parce que sur tous les exemples, de "gain de temps", vim le fait déjà et depuis longtemps. Séparation de l'écran (split / vsplit), onglets (oui des onglets dans la console), autocomplétion, aide en ligne, expressions régulières, macros, surlignage ultra simple de tous les langages possibles et entièrement customizable, trois types de gestion de dictionnaires, autocomplétion mais aussi l'aide qui va avec, codes snippets, déboguage pas à pas avec gcc (C++) et xdebug (Php), gestion svn / git intégrée dans une fenêtre dédiée (oui oui tout ça c'est bien dans la console), tout ça associé à screen pour avoir plusieurs bureaux (= consoles) qu'on peut récupérer et ré-afficher sur n'importe quel autre PC, et on a un EDI complet dans un seul éditeur.

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

Donc vim est à part : une courbe d'apprentissage affreusement longue et frustrante, mais résultat garanti : absolument aucun autre éditeur sur terre le vaut (sauf pour les Mr point-and-click qui n'arriveront jamais à admettre qu'ils perdent un temps fou à sortir la main du clavier pour prendre la souris et vice versa), et, vraiment bien configuré, il se rapproche dangereusement d'un EDI à part entière.

Cela dit, j'aime PhpStorm quoique beaucoup trop fouillis au départ, et SublimeText, qui n'est pas obligatoirement payant : il suffit de dire qu'on paiera plus tard.

Hors de question. Je préfère qu'un être humain vienne m'expliquer que j'ai de "mauvaises pratiques" de codage, parce qu'on moins, l'être humain, je peux le remettre à sa place en lui prouvant que c'est lui qui a tort et qu'il ferait mieux de se mêler de ce qui le regarde, parce que si je veux moi aussi je peux aller analyser son code pour lui casser les lucioles. Mais avec un programme informatique, je ne peux pas faire cela, donc hors de question que j'utilise un logiciel, c'est à dire un truc qui n'a même pas de cerveau (faut-il le rappeler), qui prétendrait mieux savoir que moi comment je dois coder. Non mais de quoi je me mêle ?

Marrant, parce que quelqu'un m'expliquait que PhpStorm est excellent pour ça. Sur quoi il enchaîne immédiatement : tu vois, ton "list(, $val) = each($tab_resultat);" est une faute en Php, c'est pratique ! Ce à quoi j'ai rétorqué en souriant : absolument, pas, bien au contraire, non seulement on peut faire ça en Php mais en plus il faut le faire si on n'utilise pas la première variable (qui est l'index), ça évite une allocation mémoire inutile Donc question correction, il y a encore du boulot... et effectivement, aucun éditeur n'expliquera clairement les "conventions" qu'il faut suivre...

[esperanto]

Pas de compilateur incorporé par exemple,

Il y a incorporé et incorporé. Quand tu regardes les EDI pour Java, la plupart te proposent de télécharger une version avec un compilateur intégré et une autre qui se propose d'utiliser celui que tu as déjà sur ta machine.
Et puis la plupart des compilateurs peuvent se lancer en ligne de commande, donc être intégrés dans un script, et donc potentiellement être intégrés sous forme d'une macro dans NP++.

Tu cites delphi, désormais je lui préfère son équivalent gratuit Lazarus... qui repose sur un compilateur free pascal qui tout intégré qu'il soit, n'en est pas moins développé indépendemment et utilisable sans Lazarus, ce qui n'est pas aussi facile avec le compilateur de Delphi.

Avec un EDI, on compose visuellement son application en y ajoutant des objets texte, éditeur, commandes, accès à des bases de données, etc... tout ça graphiquement. Et on bascule du mode visualisation au mode codage simplement.

Composer visuellement les accès au sgbd, il n'y a guère qu'en delphi que j'ai vu ça.

Pour les interfaces graphiques, comme je disais, c'est à double tranchant. En Delphi, si tu regardes le contenu d'une unité, tu n'y verras jamais les propriétés graphiques : elles sont dans un fichier séparé. Dans les premières versions si je me souviens bien c'était un binaire, donc impossible de faire une modification sans avoir un delphi à portée de main. Dans les versions suivantes c'est devenu du code, heureusement. Mais au fond, c'est bien que ce soit séparé: comme ça tu ne vas pas modifier le code généré par l'outil, modification qui serait écrasée dès qeut tu reviens sur l'éditeur graphique d'objets. C'est plus compliqué dans le cas de Java, que ce soit sous Eclipse/SWT ou NetBeans/Swing: ils ont beau mettre des commentaires ///DO NOT MODIFY HERE entre les parties générées automatiquement, rien ne t'empêche de le faire et dès que tu reviens sur la partie graphique le générateur de code s'emmèle les pinceaux.

Vous voyez, la conception visuelle, ça n'a pas que des avantages: soit on s'y tient jusqu'au bout (et tout le monde s'y tient, ce qui est plus difficile dans un projet avec beaucoup de contributeurs) soit on est obligé d'y renoncer à un moment ou l'autre.

[skypers]

Je suis personnellement un inconditionnel de vim. Les IDE ajoutent une couche intéressante, mais dont je ne suis pas fan car cela crée une relation trop grande à son IDE. Un développeur qui ne code qu’en se fiant à son IDE n’apprendra pas ce qu’un développeur sans IDE apprendra rapidement. Par ailleurs, cela a déjà été cité plus haut, mais les indentations automatiques, les } et ) rajoutés de partout, c’est ultra relou. Du coup, on se retrouve à les désactiver, et au final… on retrouve un IDE traditionnel, mais en plus lourd et plus lent.

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

[Pierre GIRARD]

@esperanto :
Je ne dis pas le contraire, et je suis le premier à utiliser VI (vim dans la réalité) sur Linux et Notepad++ sous Windows avec PERL, PHP et HTML/XHTML/CSS etc...

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.

J'utilise aussi IBExpert pour la conception de mes bases de données et les scripts SQL et une fois les scripts testés, je les incorpore dans mes programmes Delphi/Lazarus.

Pour finir, je suis juste un développeur "amateur". Je fais ça pour mon plaisir et quand on code moins de 2 heures par semaine, il faut reconnaitre qu'un bon IDE est plutôt bien pratique.

[nchal]

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)

[AurelienRibon]

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.