IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

EDI vs Editeurs de texte : quelle est votre préférence pour coder ?

Le , par buxbux

95PARTAGES

7  1 
Deux mondes semblent parfois s’affronter dans l'univers de la programmation logicielle. Dans un camp les utilisateurs d'EDI et dans l'autre ceux qui utilisent des éditeurs de texte plus conventionnels.

Bien que chacune de ces pratiques saura être adaptées a différents usages, il n'est pas rare d'écouter des développeurs défendre coûte que coûte leurs outils quelque soit l'usage. Les propos tenus ici n'ont pas pour but de simplement vanter les mérites des EDI mais de soulever les bienfaits que l'on peut en tirer. Un regard autre que ce qui a été soulevé dans l'article "Les IDE sont-ils dangereux pour les développeurs ? Certains pensent qu'ils rendent incompétents" publié récemment. Les EDI peuvent être équipés d'une série de fonctionnalités destinée à améliorer la rédaction du code sans la remplacer pour autant, en voici quelques-uns :

Naviguer dans le code

Travailler sur une application complexe constituée de nombreux composants se traduit souvent par devoir faire interagir de nombreux objets, interfaces, schémas ... Le tout imbriqué par des patrons de conceptions plus ou moins complexes. Un EDI saura analyser votre code pour en connaître sa composition: quelle est la signature de la méthode que vous utilisez, la documentation de la classe que vous instanciez ou surchargez, etc. Cela ce traduira par une aide contextuelle composée de la documentation et la signature de la méthode que vous vous apprêtez à utiliser, le type d'une variable dans votre code, des propositions de méthode, table SQL, champs de table SQL, si vous surchargez correctement un objet, une méthode, etc. Cela étant essentiel pour économiser le temps que prend le va-et-vient manuel entre les fichiers de son programme ou aux erreurs de compilations.


Le code et sa forme

La forme, l'organisation et la qualité du code se doivent d'être soignées pour que sa maintenance, son utilisation et son évolution ne soient pas un calvaire. En plus de vérifier la syntaxe du code, un EDI pourra nous assister dans la rédaction d'un code propre et ainsi participer à la bonne qualité de son application:

En fonction des conventions de codage préparamétrées ou configurées par vos soins, il vous sera signalé les formes syntaxiques non conformes, préparera vos zones de commentaires, générera les méthodes d'accès encapsulant vos attributs. Il vous signalera également les mauvaises pratiques présentes dans votre code ou encore les formes syntaxiques à problème, susceptible d'engendrer des erreurs. Un EDI pourra même vous faire quelques remarques sur la longueur de vos classes et méthodes comme le conseille Robert Martin dans son livre "Coder proprement".


Intégration d'outils externes

Certains EDI intègrent des outils comme des gestionnaires de versions (GIT, Subversion, etc), framework de tests unitaires (jUnit, PHPUnit, etc.), non pas seulement avec de simples interfaces (GUI) mais en les intégrant visuellement dans les pages de code. Vous permettant par exemple de voir à l'aide de couleurs les lignes modifiées depuis votre dernier commit ou la couverture de code des tests.



Un EDI peut être un formidable outil pour nous accompagner dans l'écriture d'un code de qualité sans pour autant nous remplacer dans cette tache. Pouvant nous inculquer de bonnes pratiques et habitudes je pense qu’ils font partie des outils essentiels du développeur.

Quel est votre point de vue sur la question ? Utilisez-vous un EDI et ressentez-vous ces bénéfices ? Ou au contraire, pourquoi vous tournez-vous vers un éditeur de texte plus standard ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de ptah35
Membre éclairé https://www.developpez.com
Le 25/06/2014 à 14:40
Pour faire du pain à la maison, j'ai besoin d'un coin de table et d'un four ménager capable d'atteindre un température de l'ordre de 250°C. Rien de plus. Pour faire du pain de manière professionnelle, c'est une autre affaire; j'ai besoin d'un pétrin mécanique, d'un four à plusieurs dizaines de millier d'Euro, d'une diviseuse hydraulique, d'une façonneuse, d'un grands plans de travail, de chariot de stockage, de meubles parisiens, j'en passe et des meilleurs... sans compter un grand laboratoire pour y caser tout ce fourbi.

Pour coder un petit script ou un petit programme non commercial, un éditeur de texte suffit amplement (pour autant, tout de même, qu'il soit un rien plus élaboré que le notepad de Window). Lorsqu'il s'agit de développement professionnel, l'intégration des différent outils nécessaires (refactoring, contrôle de versions, bug tracking, tests unitaires, debugger, profiler, etc.) n'est rapidement plus une option.

Mais bon... cela étant dit, les vrais programmeurs programme en assembleur... non?
10  0 
Avatar de gretro
Membre averti https://www.developpez.com
Le 24/06/2014 à 17:47
Personnellement, pour de petites modifications rapides, je suis tenté d'ouvrir un éditeur de texte (surtout quand il s'agit d'un langage scripté). Sinon, je code toujours avec un IDE (ou EDI), que ce soit au bureau qu'à la maison. On dira ce qu'on voudra, mais je ne me vois pas vraiment utiliser un éditeur de texte conventionnel pour faire des projets relativement complexes. La complétion de code, l'intégration aux tests unitaires et tous ces outils me sont indispensables afin d'être moyennement productif.

De plus, programmant surtout en C#, j'ai accès à ce que je crois être le meilleur IDE du monde, soit Visual Studio (avec en plus Resharper). De mon expérience avec Java et PHP, aucun IDE ne l'accote ne serait-ce qu'un peu au niveau des fonctionnalités et de l'aide qu'il fournit.

Ton avis est certainement dû au fait d'avoir utilisé NetBeans qui est vraiment le pire IDE que j'ai eu à utiliser!
J'aimerais également savoir ce qui s'est passé pour que tu aies une si mauvaise opinion de NetBeans, car l'ayant utilisé pour mes projets Java, je peux dire que c'est mon deuxième favoris. (IntelliJ vient peu derrière). Personnellement, le pire IDE à mon opinion est Eclipse . Cet EDI fait tout, et probablement de manière compétente, mais sa présentation est tellement désuète et il a la fâcheuse tendance à cacher les fonctions les plus utilisées. Si cela convient à certains, c'est parfait, mais moi, je passe mon chemin.
9  2 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 27/06/2014 à 14:59
Citation Envoyé par buxbux Voir le message
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.
Citation Envoyé par esperanto Voir le message
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.

Citation Envoyé par esperanto Voir le message
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.
  • ...


Citation Envoyé par esperanto Voir le message
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 ;-)

Citation Envoyé par esperanto Voir le message
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 ?

Citation Envoyé par esperanto Voir le message
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é.

Citation Envoyé par SurferIX Voir le message
Le dernier Linux mag 172 m'a encore appris des choses même après deux ans de pratique !
C'est une blague ?

Citation Envoyé par skypers Voir le message
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

Citation Envoyé par nchal Voir le message
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).

Citation Envoyé par esperanto Voir le message
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 ;-)
6  0 
Avatar de esperanto
Membre émérite https://www.developpez.com
Le 26/06/2014 à 17:29
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.
5  0 
Avatar de Carhiboux
Expert éminent sénior https://www.developpez.com
Le 26/06/2014 à 10:13
Citation Envoyé par CodeurPlusPlus Voir le message
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...
4  0 
Avatar de ndalaba
Membre habitué https://www.developpez.com
Le 24/06/2014 à 17:35
Citation Envoyé par beekeep Voir le message
C'est quand même dommage de ne pas profiter des avantages d'un bon IDE.
Ton avis est certainement dû au fait d'avoir utilisé NetBeans qui est vraiment le pire IDE que j'ai eu à utiliser!
Je me demande bien pour quel genre de projet tu as utilisé netbeans pour le traiter de pire IDE.
J'aimerai savoir sur quoi tu te base pour le dire.
4  1 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 24/06/2014 à 17:47
Notepad++ est l'un des meilleurs éditeurs de texte que j'ai eu à utiliser : rapide, facile et rapide à paramétrer, un système de macro super, gère très bien les fichier de gros volume
Bref, c'est l'idée pour des tâches courtes et l'analyse des logs

Par contre, pour le dev, surtout sur des projets avec beaucoup de dépendances, rien ne vaut un bon IDE
Par contre, cela demande pas mal de temps pour obtenir un paramétrage qu'il nous convient
Certes, c'est lourd au démarrage mais quel bonheur d'avoir un tout-en-un qui évite de constamment switcher entre 10 applications
3  0 
Avatar de nchal
Membre expérimenté https://www.developpez.com
Le 27/06/2014 à 14:27
Citation Envoyé par esperanto Voir le message
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.
3  0 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 22/06/2014 à 7:05
pour développer en PHP j'utilise aussi bien NetBeans que Notepad++ et je dois dire qu'entre les deux mon coeur balance, le premier propose des aides précieuses, le second se lance en 1/10ième de secondes et ne subit aucun ralentissement d'analyse du code puisqu'il n'en fait pas

J'ai du mal avec les IDE très complets mais très lourds, même sur une machine bien garnie, car je code très vite et j'ai besoin d'un éditeur réactif, d'ailleurs je désactive généralement la complétion de code (en partie tout au moins) car elle perturbe ma saisie au lieu de me faire gagner du temps...que ce soit en ajoutant un } intempestif, ou en confondant une simple quote et une apostrophe => "l'apostrophe" et 'la simple quote' n'ont pas la même signification
2  0 
Avatar de arnolddumas
Rédacteur/Modérateur https://www.developpez.com
Le 24/06/2014 à 19:00
J'utilise Netbeans pour mes projets en Java ou en PHP. Pour les projets C et C++, j'utilise Qt Creator.
2  0