Soutenez-nous
Publicité

Affichage des résultats du sondage: Quels outils de métrique java utilisez-vous ?

Votants
86. Vous ne pouvez pas participer à ce sondage.
  • Cobertura

    28 32,56%
  • CheckStyle

    57 66,28%
  • PMD/CPD

    45 52,33%
  • Findbugs

    34 39,53%
  • JDepend

    17 19,77%
  • JLint

    2 2,33%
  • Cast

    1 1,16%
  • Autre

    14 16,28%
Sondage à choix multiple
+ Répondre à la discussion
Affichage des résultats 1 à 14 sur 14
  1. #1
    Membre Expert Avatar de gifffftane
    Profil pro
    Inscrit en
    février 2007
    Messages
    2 354
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : février 2007
    Messages : 2 354
    Points : 2 337
    Points
    2 337

    Par défaut Quels outils de métrique Java utilisez-vous ?

    Bonjour,

    Ce petit sondage est également l'occasion de partager vos expériences et usages. Par exemple :

    dans quel contexte technique vous les utilisez (maven, ant, EDI, autre ? )
    dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
    quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
    quel conseil ?
    quels serait vos souhaits, si vous voudriez des tutoriaux sur ce sujet dans dvp (ou les écrire, nous sommes toujours à la recherche de contributeurs), etc, etc, etc.

    Voici les sites des outils cités : Cobertura, CheckStyle, PMD/CPD, Findbugs, JDepend, JLint, Cast

    Vous pouvez voter pour plusieurs produits.

    Sur ce sujet, vous pouvez consulter Les outils de gestion de la qualité d'un projet Java et leur intégration à Maven 2, Calculer les métriques de vos projets avec Metrics, Analyse de la qualité du code Java avec JDepend 2.7, Maven Comment analyser les métriques avec JDepend ?
    Mieux que Google, utilisez Sur Java spécialisé sur la plate-forme java !
    Pour réaliser vos applications Java dans le cadre de prestations, forfait, conseil, contactez-moi en message privé.

  2. #2
    Rédacteur
    Avatar de eclesia
    Inscrit en
    décembre 2006
    Messages
    1 941
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 1 941
    Points : 2 421
    Points
    2 421

    Par défaut

    Outils :
    Selenium, cobertura
    dans quel contexte technique vous les utilisez (maven, ant, EDI, autre ? )
    Maven,NetBeans,Hudson
    dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
    Nos projets sont en continuel developpement (domaine de la recherche).
    quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
    Aucun benefice particulier, juste reconforter le client et le patron.
    quel conseil ?
    Il ne faut pas que ces outils vous empeche de travailler ni contraigne votre code a respecter des patterns ou des mises en forme douteuses, ca ne doit pas prendre plus de 5% de votre temps.

  3. #3
    Membre Expert
    Avatar de hasalex
    Homme Profil pro Alexis Hassler
    Inscrit en
    janvier 2009
    Messages
    802
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexis Hassler
    Âge : 44
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : janvier 2009
    Messages : 802
    Points : 1 058
    Points
    1 058

    Par défaut

    Outils :
    PMD, Checkstyle, jDepend

    dans quel contexte technique vous les utilisez (maven, ant, EDI, autre ? )
    Checkstyle intégré à Eclipse, PMD et jDepend en ligne de commande avec sortie CSV

    dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
    Checkstyle dans tous les projets, PMD et jDepend en audit de code ou revue d'architecture

    quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
    L'outil est plus objectif que le consultant, il n'est pas discutable ; ce qui est évidemment discutable puisque c'est moi qui fais le paramétrage. Par contre, d'un point de vue psychologique, ça permet de ramener plus facilement les fortes têtes et contestataires dans le droit chemin.

    quel conseil ?
    - Checkstyle doit être intégré dès le début du projet.
    - Sélectionner les règles pertinentes (et rentables)
    - Associer des diagrammes UML de packages aux résultat de jDepend

  4. #4
    Rédacteur/Modérateur
    Avatar de romaintaz
    Homme Profil pro Romain Linsolas
    Java craftsman
    Inscrit en
    juillet 2005
    Messages
    3 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Romain Linsolas
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2005
    Messages : 3 717
    Points : 6 516
    Points
    6 516

    Par défaut

    En plus de ce qui a été dit précédemment, je voulais ajouter que j'utilise personnellement Sonar, qui agglomère les résultats de checkstyle, cobertura / clover, findbugs, pmd...
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  5. #5
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    novembre 2004
    Messages
    1 176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 176
    Points : 2 131
    Points
    2 131

    Par défaut

    Contexte technique :
    Bamboo pour ordonnancer des tests et présenter les métriques, maven pour jouer les builds et eclipse pour la partie IDE
    dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
    projets géré par méthodologie agile, cycles de développement court et itératif qui nécessitent des phases de non régression automatisé.
    quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
    Grand bénéfice sur la maintenance. L'utilisation des outils permet de mesurer les évolutions qualitatives du code (PMD, checkstyle, findbugs) et quantitative (clover indique le nombre de lignes de code et sa couverture).
    La tracabilité des commits sous svn et la liaison entre commit et fiche JIRA et builds bamboo permet de mettre le doigt rapidement sur le bout de code fautif ainsi que la motivation qui a entrainé la modification.
    Grand bénéfice pour le développeur qui est rassuré vis à vis de la non régression et qui sait travailler dans un cadre bien délimité. C'est aussi un confort puisque chaque développeur utilise les mêmes conventions et cela améliore la facon de reprendre le code d'un autre développeur.
    Les tests unitaires associés à la couverture de code permettent de mettre en évidence le code à risque ainsi que le code mort.
    Bénéfice clients faible, nous ne communiquons que très peu sur nos méthodes.
    quel conseil ?
    L'effort de mise en place est important mais nécessaire. Que ce soit sur un projet "historique" existant ou un nouveau projet, les métriques sont un facteur de qualité.
    Evidemment il faut les associer aux développeurs et leur en montrer le bénéfice. La mise en place n'est pas uniquement technique, c'est aussi une formation continuelle des équipes afin de les encourager à travailler avec.

    En voyant d'ailleurs une des réponses plus haut, (désolé eclesia si je prends ta réponse, mais elle est significative), on voit clairement que l'effort de communication n'a pas été fait puisque le développeur n'est pas convaincu des outils qu'il utilise et n'y voit aucun bénéfice et conseille d'ailleurs d'y passer peu de temps.

    C'est au responsable qualité s'il y en a un et au manager de mettre en évidence les apports positifs de ces techniques et ce n'est pas toujours évident puisque c'est très consommateur en temps pour parfois peu de résultats directement visibles (mais les résultats sont bien la dans le temps).

  6. #6
    Membre actif
    Avatar de David Gimelle
    Profil pro
    Développeur Java
    Inscrit en
    janvier 2007
    Messages
    79
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : janvier 2007
    Messages : 79
    Points : 199
    Points
    199

    Par défaut Sonar

    Bonjour,

    J'utilise Sonar. Trés pratique pour repérer les copié collé ainsi que les classes trop complexes qui doivent etre refactorisés.
    Il permet aussi de voir facilement la couverture de test de chaque classe.

    David Gimelle
    Développeur J2EE
    blog: http://getj2ee.over-blog.com

  7. #7
    Nouveau Membre du Club
    Inscrit en
    octobre 2004
    Messages
    56
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 56
    Points : 30
    Points
    30

    Par défaut

    perso findbugs dans Eclipse ou en standalone, juste pour vérifier que j'ai pas fait d'erreurs grossières une fois de temps en temps pendant le developpement d'un projet

  8. #8
    Rédacteur
    Avatar de eclesia
    Inscrit en
    décembre 2006
    Messages
    1 941
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 1 941
    Points : 2 421
    Points
    2 421

    Par défaut

    Citation Envoyé par hugo123 Voir le message
    En voyant d'ailleurs une des réponses plus haut, (désolé eclesia si je prends ta réponse, mais elle est significative), on voit clairement que l'effort de communication n'a pas été fait puisque le développeur n'est pas convaincu des outils qu'il utilise et n'y voit aucun bénéfice et conseille d'ailleurs d'y passer peu de temps.
    De mon point de vue, il y a une part de ses outils qui sont fait pour les non-javaiste et les debutants java, comme les corrections de nom de methode, de variable et de porté. C'est sans doute tres utile afin de garantir un minimum de qualité et de rigueur dans le code.
    Toutefois tout le monde n'est pas comme ca, quand je ne met pas de "get" devant un accesseur, j'en connais la raison et je sais ce que je fais. de meme pour l'usage des final et des bloc if else sans les {} pour raison de lisibilité. Bref plein de raison du genre.

    Pour imager :
    On ne demande pas a quelqu'un de peler une pomme de terre avec un epluche legume alors qu'il le fait plus vite depuis 5ans avec un couteau.
    (car il faut l'admettre, ces outils ralentissent les machines et prennent du temps de mise en place)

    Ce n'est pas une question de communication, c'est savoir faire son métier.

    Tout ses outils, tout comme les designs patterns sont des aides et des recomandations, en aucun cas des obligations et en aucun cas des standards (si ca le devient nous ne seront plus que machine a taper vivante, de la marchandise consommable)

  9. #9
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    novembre 2004
    Messages
    1 176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 176
    Points : 2 131
    Points
    2 131

    Par défaut

    C'est malheureusement ce que nous sommes. Sans vouloir dénaturer notre profession, le temps de l'informaticien artisan/artiste est un peu révolu.
    Aujourd'hui il faut travailler dans des sociétés qui pratiquent l'offshore, qui ont des turnovers importants et des niveaux très hétérogènes dans les équipes.

    Dans un contexte d'artisanat et individuel, je te rejoins à moitié sur ton analyse, effectivement on peut travailler avec ces normes personnelles depuis plusieurs années et être très productif.

    Dans un contexte de travail en équipe, les standards apportent un plus indéniable pour la compréhension, qui plus est si on prend des normes internationales (exemple la convention java beans, les normes de codage sun etc...).
    Qui plus est, ces outils font plus que détecter que la variable n'a pas un nom camelcase ou que la méthode bidule dépasse les 100 lignes. Ils sont capable de détecter grossièrement des erreurs de synchro, des problèmes de copier coller, des complexités algorithmiques trop importantes (qui peuvent être justifiés mais pas toujours) etc...

    Pour prendre certain de tes exemples :
    - quand je ne met pas de "get" devant un accesseur, j'en connais la raison et je sais ce que je fais.
    => toi tu le sais, et sans doute que tu as analysé ton cas d'usage qui te permet de dire que ce n'est pas utile. Par contre le débutant, voire même la personne confirmé qui tentera d'utiliser ton bean plus tard avec jaxb ou hibernate ne va pas comprendre pourquoi son attribut n'est pas modifié et il mettra longtemps avant de voir que ca vient du fait que ca ne respecte pas le standard java beans

    - bloc if else sans les {} pour raison de lisibilité
    => La encore, le développeur sait très bien qu'il peut s'en passer que c'est plus lisible et que cela ne comporte pas de bugs. Mais la personne qui repassera dessus dans 2 ans et qui utilisera un éditeur qui aura mangé les indentations ou qui n'aura juste pas pris son litre de café et aura rajouté une ligne en dessous ou en dessus en pensant la prendre dans le if (ou pas), aura bien des surprises.


    Bref, ce post est peut être a moitié adapté pour ce type de discussion et pourrait être poursuivi ailleurs. Ce que je souhaitais souligner de facon constructive (sans cibler qui que ce soit), c'est que justement la mise en place de ces outils n'est pas qu'une question de départager les personnes qui savent faire leur métier et les autres. Les experts ont tout autant besoin de ce type d'outils pour se concentrer sur leur coeur de métier.
    Le conseil plus haut visait justement a souligner l'importance de la communication pour faire accepter ces outils plutôt que les imposer, ce qui donne généralement des résultats contre productifs car on ne voit que le coté consommateur de temps.
    Visibiblement j'ai l'impression que c'est ton cas

    Evidemment cela n'est vrai que dans les équipes qui font la maintenance de leur propre code (ce qui n'est pas toujours le cas) et qui ont une longévité supérieure à 1 ans sur le même projet, dans le cas contraire il sera très difficile de prouver l'intérêt de l'outils sur le long terme.

  10. #10
    Rédacteur/Modérateur
    Avatar de CyberChouan
    Homme Profil pro Benoît Courtine
    Directeur technique
    Inscrit en
    janvier 2007
    Messages
    2 749
    Détails du profil
    Informations personnelles :
    Nom : Homme Benoît Courtine
    Âge : 31
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : janvier 2007
    Messages : 2 749
    Points : 4 027
    Points
    4 027

    Par défaut

    Outils :
    PMD, Checkstyle, jDepend, FindBugs, Sonar, Hudson (serveur d'intégration continue)

    dans quel contexte technique vous les utilisez (maven, ant, EDI, autre ? )
    Checkstyle intégré à Eclipse également, tous les autres sont passés automatiquement chaque nuit par Hudson (ou chaque week-end sur les très gros projets nécessitant un temps de compilation important)

    dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
    Sur tous les projets, afin d'assurer un bon niveau de qualité de code (et former les développeurs en explicitant les raisons des erreurs remontées par les outils de qualimétrie)

    quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
    pour le client, l'assurance de la qualité de ce qui est livré (encore que les outils ne font pas tout...)
    pour le développeur, la formation : à force d'avoir des avertissements (et leurs explications... sinon c'est stérile) et de devoir les corriger, ils apprennent à mieux coder
    pour la maintenance, le coût et le temps qui est réduit : on débuggue bien plus facilement une méthode avec javadoc et commentaire, décomposée en sous-méthodes élémentaires qu'un pavé procédural de 200 lignes sans commentaires (et je n'exagère pas... c'est du vécu)
    pour l'évolution... c'est plus délicat : certes, les outils aident, mais c'est plus l'architecture (utilisation d'interfaces, etc.) qui assure l'évolutivité d'une application. Et les outils ne font pas (encore ?) de vérification de l'architecture

    quel conseil ?
    - Checkstyle doit être intégré dès le début du projet... corriger un projet sinon est bien trop coûteux
    - Ne pas appliquer toutes les règles... certaines sont inutilement énervantes à mettre en place (par exemple, je ne vois pas spécialement l'intérêt d'interdire l'indentation par tabulation au profit des espaces)
    - Si les outils ne sont pas mis en place dès le début du projet, il faut les intégrer petit à petit (en mettant d'abord les règles les plus importantes, puis en les rajoutant quand le projet avance) pour ne pas avoir 17562 violations de règles d'un coup !
    Avant de poster, pensez à regarder la FAQ, les tutoriaux, la Javadoc (de la JRE que vous utilisez) et à faire une recherche
    Je ne réponds pas aux questions techniques par MP: les forums sont faits pour ça
    Mes articles et tutoriaux & Mon blog informatique

  11. #11
    Rédacteur
    Avatar de eclesia
    Inscrit en
    décembre 2006
    Messages
    1 941
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 1 941
    Points : 2 421
    Points
    2 421

    Par défaut

    Citation Envoyé par hugo123 Voir le message
    Dans un contexte de travail en équipe, les standards apportent un plus indéniable pour la compréhension, qui plus est si on prend des normes internationales (exemple la convention java beans, les normes de codage sun etc...).
    Tout a fait d'accord.

    Citation Envoyé par hugo123 Voir le message
    - quand je ne met pas de "get" devant un accesseur, j'en connais la raison et je sais ce que je fais.
    => toi tu le sais, et sans doute que tu as analysé ton cas d'usage qui te permet de dire que ce n'est pas utile. Par contre le débutant, voire même la personne confirmé qui tentera d'utiliser ton bean plus tard avec jaxb ou hibernate ne va pas comprendre pourquoi son attribut n'est pas modifié et il mettra longtemps avant de voir que ca vient du fait que ca ne respecte pas le standard java beans.
    ce n'est effectivement pas la norme java bean, ce cas m'arrive en fait tres souvent, quand j'ai des classes offrant des collections vivante en acces.
    Par exemple, au lieu d'avoir un :
    Code :
    1
    2
    3
    4
    5
    setUsers(List<User> users);
    List<User> getUsers();
    // j'ai ceci :
    List<User> users();
    Horrible vas tu me dire, on accede a la liste direct, probleme de synchronisation droit devant. Sauf que si tu es un bon developpeur, tu ira lire la javadoc et tu sauras qu'il s'agit d'un objet synchronisé d'un tout autre type qui se cache derriere et qui ne fait qu'offrir une interface de type List.
    Ca parait deroutant quand on est habitué aux bien beaux et bien jolies patterns, mais c'est du java parfaitement legal.

    Quand a JaxB tu as mon avis sur cette horreur ici :
    http://www.developpez.net/forums/d62...professionnel/
    (le fait qu'il en resort un 50-50 montre que ce n'est pas une API de reference)

    Citation Envoyé par hugo123 Voir le message
    - bloc if else sans les {} pour raison de lisibilité
    => La encore, le développeur sait très bien qu'il peut s'en passer que c'est plus lisible et que cela ne comporte pas de bugs. Mais la personne qui repassera dessus dans 2 ans et qui utilisera un éditeur qui aura mangé les indentations ou qui n'aura juste pas pris son litre de café et aura rajouté une ligne en dessous ou en dessus en pensant la prendre dans le if (ou pas), aura bien des surprises.
    Je pense a des cas comme :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    if(var==null) throw new NullPointerException(...);
    //ou encore
    if(       var.equals(...) ) varN = ... ;
    else if( var.equals(...) ) varN = ... ;
    else if( var.equals(...) ) varN = ... ;
    else if( var.equals(...) ) varN = ... ;
    else                           varN = ... ;
    l'usage des {} dans beaucoup de petit cas rend le code moins lisible et 2 à 3 fois plus étalés (et donc encore moins lisible).

    Le conseil plus haut visait justement a souligner l'importance de la communication pour faire accepter ces outils plutôt que les imposer, ce qui donne généralement des résultats contre productifs car on ne voit que le coté consommateur de temps.
    Visibiblement j'ai l'impression que c'est ton cas
    C'est effectivement mon cas mais je ne denigre pas tout les outils, loin de la, c'est surtout les patterns, la syntaxe, la mise en forme et les cas particuliers qui font faussement baisser le verdict de "qualité".

    ps: si le debat prend trop d'ampleur, je ferais un nouveau topic

  12. #12
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    novembre 2004
    Messages
    1 176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 176
    Points : 2 131
    Points
    2 131

    Par défaut

    héhé, pour jaxb c'est plutot 50% pour / 15% contre et 30% ne sais pas (je viens de voter) mais avec 6 votes c'est pas très représentatif ^^

    Bon sinon sur le reste je ne reviendrais pas, je pense que ces outils c'est avant tout une question de conventions accepté par une équipe (et non imposé). Si nous travaillions ensemble je tenterais de t'en convaincre en pause café, c'est de le meilleur endroit pour les discussions informelles ^^

    Mais pourquoi pas un petit article dvp qui pourrait être intéressant pour expliciter certaines de ces normes

    Promis le prochain message c'est en PM pour éviter de polluer le topic

  13. #13
    Futur Membre du Club
    Inscrit en
    février 2003
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : février 2003
    Messages : 52
    Points : 18
    Points
    18

    Par défaut

    Pourtant je la trouve intéressante votre discussion ! C'est le genre de question auxquelles on fait face lorsqu'on met en place ces outils...

  14. #14
    Expert Confirmé
    Avatar de natha
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    2 346
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : janvier 2006
    Messages : 2 346
    Points : 2 735
    Points
    2 735

    Par défaut

    Perso j'active dans le CheckStyle l'obligation des { } dans les if/else !
    Je trouve beaucoup plus lisible un code indenté que cette horreur (sans offense, c'est une appréciation personnelle) :

    Code :
    1
    2
    3
    4
    5
    6
    7
    if(var==null) throw new NullPointerException(...);
    //ou encore
    if(       var.equals(...) ) varN = ... ;
    else if( var.equals(...) ) varN = ... ;
    else if( var.equals(...) ) varN = ... ;
    else if( var.equals(...) ) varN = ... ;
    else                           varN = ... ;
    D'autant plus qu'il suffit qu'un petit malin fasse Ctrl+Shift+F sur ta classe pour indenter selon la configuration Eclipse et on se retrouve avec :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    if(var==null)
        throw new NullPointerException(...);
    //ou encore
    if (var.equals(...))
        varN = ... ;
    else if( var.equals(...))
        varN = ... ;
    else if( var.equals(...))
        varN = ... ;
    else if( var.equals(...))
       varN = ... ;
    else
       varN = ... ;
    Et je ne connais pas un débutant voire expert qui ne soit jamais tombé dans le panneau du if/else sans { }.


    Chez nous pour la mise en place des normes j'ai pu le faire quand l'équipe était encore jeune (comprendre peu de personnes). J'ai mis en place un certains nombre de règles en suivant les standards Sun et mis au vote les règles. Certaines ont été acceptées sans problèmes, d'autres ont suscité débat, mais maintenant notre code est vraiment uniforme (ce qui évite également de générer trop de diff lors des commits SVN pour de la mise en forme...).


    Ah oui, à noter qu'Eclipse 3.4 est maintenant capable de mettre automatiquement les accolades sur les blocs if/else lorsqu'il sont manquants via le Ctrl+Shit+F.
    On se retrouve donc directement avec :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    if(var==null) {
        throw new NullPointerException(...);
    }
    //ou encore
    if (var.equals(...)) {
        varN = ... ;
    } else if( var.equals(...)) {
        varN = ... ;
    } else if( var.equals(...)) {
        varN = ... ;
    } else if( var.equals(...)) {
       varN = ... ;
    } else {
       varN = ... ;
    }
    Ce qui est quand même le plus lisible. Cependant ce type de code dénote souvent un problème d'algorythmie sur le fond. Les if/else en cascade devraient être rares.
    Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
    De la bonne manière de poser une question (et de répondre).
    Je ne fais pas de service par MP. Merci (...de lire les règles...).
    Ma page dvp.com

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •