Je pense surtout que tu n'as pas grand chose a montrer a par ton arogance.

heuresement qu elle est très grande parce que visiblement tu n'as que ca ^^

Ton cas semble désespéré.
T'attaquer à ma personne plutôt qu'à mes arguments montrerait au moins qu'il sert à quelque chose de parler avec toi.
Essaie au moins de parler du sujet, du Java, de programmation, je ne sais pas moi, montrer que tu es un programmeur et pas juste un troll dont le seul but est de faire des allusions grosses comme "oh tu as jamais programmé de ta vie puisque tu sais parler programmation", trop logique de ta part.
Enfin continue à faire des allusions pleine de cohérence, c'est presque amusant

T'attaquer à mes arguments plutôt qu'à ma personne *

ne confond pas c'est toi qui attaque tout le monde en sortant des truc comme.

moi je sais faire la différence entre un bon code et un movais code. Moi je ne code pas mon cher monsieur je fais de l'art. Moi j'ai appris avec les meilleur je suis devenu un expert. et du moi moi moi moi moi lol

en gros j'ai aucun envie de débattre avec toi ca c'est sure ^^
tu me fait juste rire c'est tout ^^

tu peux citer cette phrase que j'ai dit ?

Et ben bordel, tout ça parce que j'ai amené la solution "machin".equals(unTruc);

J'hallucine un peu là, pour le coup.

Donc, ce type de ligne est aussi très utilisé, que tu le veuilles ou non. Après, tu le considères comme tu veux, ça te regarde.
Quant à l'argument du "et si il faut changer 'machin' un jour, faudra le changer à 150 endroits ?". Tout d'abord, elle est écrite en dur car elle n'est présente que deux ou trois fois grand maximum. Ensuite, si il a à d'autres endroits, c'est évident que ce sera une encapsulé dans une constante.
Le seul problème dans "machin".equals(unTruc);, c'est dans le cas où "machin" n'est pas une String littéral, mais une variable quelconque qui peut, pour une raison ou une autre, ne pas avoir initialisée (pas d'initialisation à la création par le développeur parce qu'il n'y en a pas, ou pour éviter de prendre de la mémoire inutile par exemple).
Dans ce cas-là, et uniquement celui-là, je vois un intérêt à utiliser le equals de StringUtils (je parle bien d'une unique méthode, pas de StringUtils en elle-même, que l'on se comprenne).

Pour le concours de grosse bite, par contre, je passe mon tour.
Je dirai juste : Silvermo, je te souhaite de continuer à avoir beaucoup de temps pour tes projets et de pouvoir bien faire.

"T'attaquer à mes arguments plutôt qu'à ma personne *" LOL !!!!!!!!!!!!!!!!!!!!!

Le meilleur de Silvermo :

Après, si tu considères qu'être bon dans la pratique signifie écrire un code pourri, alors oui tu es meilleur que moi en pratique.

• En attendant, bien que tu sois meilleur que moi, et que tu aies une longue carrière dans la programmation, tu ne sais toujours rien du métier.

Et tu n'as pas l'air d'avoir appris à programmer

• et toi t'as pas l'air de savoir différencier un bon d'un mauvais code

Programmer bien est comme composer une mélodie, ou faire de l'art, c'est quelque chose qui ne peut se faire comme il faut sans un certain goût de ce qui est beau.
Une oeuvre est parfaite quand il n'y a plus rien à jeter.

je suis content d'avoir profité de la connaissance et l'expérience de développeurs expérimentés, et de faire un meilleur travail de meilleure qualité que ce que j'ai pu voir dans ce topic.

Bunyan : je ne dis pas qu'il faut utiliser toutes les méthodes de StringUtils, mais il y a évidemment des utilitaires tels que celui-là, ou simplement des bonnes pratiques, qu'il convient de suivre pour éviter de nombreux problèmes.
Et je persiste : à partir de deux références au moins à la même valeur magique codée en dur, il vaut mieux redéfinir une constante
C'est le cas pour les fonctions aussi, ou pour les codes similaires qui peuvent être évités grâce à des Patterns simples (Strategy par exemple);

Enfin soit, ce n'est que du bon sens, il y a tellement d'articles sur le sujet, ce n'est pas pour rien, je n'ai rien inventé et je ne suis pas Dieu comme dirait l'autre, juste un programmeur qui aime apprendre et améliorer l'existant, quand c'est possible, surtout quand c'est aussi simple à faire que dans les exemples donnés.

Si tout le monde n'était pas aussi fermé, le débat aurait été clos depuis longtemps. Je suis capable de reconnaître mes erreurs, mais là, ma seule erreur est de vouloir montrer de bonnes pratiques, qui ne font qu'améliorer un projet et améliorer les connaissances et la vision d'un programmeur sur son travail.

Il faut savoir prendre du recul sur ce qu'on fait, je pense que trop de développeurs sont si convaincus d'être parfaits en sortant de l'école qu'ils ne prennent pas la peine de remettre en question leur savoir et leurs compétences.
J'essaie au moins de bénéficier du meilleur savoir possible, et si on ne me le fournit pas, alors je l'acquiers, les livres sont un moyen d'apprendre beaucoup de choses qu'on apprendrait que bien trop tard si on attendait d'avoir l'expérience d'un Senior.

Ce n'est tout de même pas un mal de vouloir partager des bonnes pratiques, c'est juste dommage que tous les esprits ne soient pas ouverts.

"je suis content d'avoir profité de la connaissance et l'expérience de développeurs expérimentés, et de faire un meilleur travail de meilleure qualité que ce que j'ai pu voir dans ce topic. "
En effet, je n'ai nullement dit que j'avais travaillé avec les meilleurs. Mais que je préfère apprendre des autres plutôt que considérer que tout ceux qui partagent des connaissances sont forcément des cons qui ne savent rien faire en pratique.
Il faut admettre parfois qu'il y a meilleur que soi.

Il y a bien meilleur que moi, mon percentile n'est pas des plus élevés ,et c'est normal, j'ai toute la vie pour apprendre, alors j'apprends, et ce que j'ai appris, je le partage. Mais quand je vois les réactions...

"Et je persiste : à partir de deux références au moins à la même valeur magique codée en dur, il vaut mieux redéfinir une constante "
C'est ce que j'ai dis. Juste que j'ai écrit "à partir de deux ou trois", sous-entendu implicite qui ne saute pas au yeux : "au même endroit environs" (i.e. : dans la même classe).

Vu que le reste n'a rien à voir avec la choucroute, je passe.

Voilà, une constante, une enum, éventuellement s'il y a plusieurs valeurs magiques de même catégorie, bref c'est pas si compliqué à comprendre.
Tu l'as compris, je crois pas que tu l'as appris ici, c'est juste que tu l'as appris avant, ou que ça t'es venu de bon sens, par expérience.
Pour ça que je pensais que parler avec un développeur ayant fait carrière serait simple car il devrait logiquement avoir une bonne expérience de ce genre de petites optimisations.
Mais apparemment pas.

Le probleme n est pas de partager des bonnes pratiques mais de vouloir imposé ton point de vue a tout pris d'un maniere méprisante sans comprendre les contrainte ou context qui entourne un projet.

il y a une facon de partager les choses et tu ne sais pas le faire du tout.

enfin il y a plein de chose en dehors de la technique que tu ocultes ou ignore complétement et ca rend ton discour complétement décalé par rapport a la réalité des choses ^^

déja un projet si tu le veux parfait tu peux passé une vie, tu pourras toujours le rendre encore plus modulaire et générique c'est sans fin.

un projet a une durée de vie. un projet qui est refondu tout les 2 ans n'a pas a etre aussi évolutif qu'un projet qui a une duré de vie de 5 ans par contre il devra etre modulaire.

parce que a un momment il faut livrer donc il faut savoir dire stop. Et cela n'est pas sinonyme de code pourri.

Je ne veux pas imposer mon point de vue, mais faire face à une telle résistance juste car je parle d'améliorer le code proposé en page 1 du topic est assez consternant de la part de programmeurs.
Un programmeur aime en général faire les choses au mieux, et apprendre tous les jours.

Et le projet sur lequel je bosse est déjà en production, et d'une qualité superbe autant visuelle que dans le code (forcément, quand des programmeurs sont soucieux de la qualité, et que ça se ressent dans l'impression de plus en plus positive des utilisateurs à qui nous livrons de plus en plus rapidement des livrables de plus en plus exempts de bugs).
En Europe, il s'agit de l'application dans sa catégorie qui offre le plus grand confort d'utilisation aux utilisateurs. Cela est plutôt réconfortant, et ça n'a pas duré 5 ans, ni 3.

"enfin il y a plein de chose en dehors de la technique que tu ocultes ou ignore complétement et ca rend ton discour complétement décalé par rapport a la réalité des choses ^^ "
Par exemple ?

Je parle du projet en entreprise évidemment.

ba lire les parahraphes juste en dessous ...

Un programmeur aime en général faire les choses au mieux, et apprendre tous les jours.

Oui sauf que tu oublie que les gens, oui parce que le programmeur sont avant tout des gens, n'aiment pas se faire insulter ^^

Un ptit gus gus qui vient avec le moi je suis meilleur que les gens de se topic parce que j ai vue une erreur ba ca saoule et ca donne pas envie de lui parler. Puis qui continu d enchainer sur ses soit disans compétance exepcetionnel

Si tu n'es pas capable de comprendre ca tu va avoir de gros probleme relationnel avec des collegue ou client.

"déja un projet si tu le veux parfait tu peux passé une vie, tu pourras toujours le rendre encore plus modulaire et générique c'est sans fin. "
Un projet ne sera jamais parfait, ça je suis bien d'accord, est-ce une raison pour laisser les choses en l'état ?
Il y a toujours des améliorations possibles.
Il y a une règle que des centaines de milliers de programmeurs utilisent chaque jour, la règle du boy-scout.
Il s'agit, quand on doit intervenir dans du code existant, et qu'on doit le modifier pour implémenter le code correspondant à une nouvelle fonctionnalité, de voir comment on peut améliorer le code existant, pour qu'à la fin de l'implémentation, au moment du commit, ce qui est committé soit de meilleure qualité qu'à la révision précédente.

Bref ne pas forcément refactorer TOUT le code à chaque fois, juste petit à petit, ainsi il ne peut se dégrader sur le long terme.
Et ainsi il sera plus facile encore pour un autre programmeur d'intervenir dans le code.

Explique moi en quoi c'est mal ?
Et enfin, ce genre de pratique est monnaie courante à mon boulot. Et dans toutes les équipes de programmeurs, c'est considéré comme normal.

"Si tu n'es pas capable de comprendre ca tu va avoir de gros probleme relationnel avec des collegue ou client."
ça va très bien de ce côté là, mes collègues plus âgés apprennent de moi, demande mon avis sur leur code, et de la même façon je demande leur avis sur certains points obscurs, bref échange d'information.
Avec les clients aussi, un sourire, de la patience, de la bonne volonté, l'envie de ne pas laisser le client seul face à son problème, bref je pense avoir assez d'attention et de considération du client. Si on m'appelle Mona (car je suis toujours souriant et que je mets les gens de bonne humeur) au boulot, c'est pas pour rien

"Oui sauf que tu oublie que les gens, oui parce que le programmeur sont avant tout des gens, n'aiment pas se faire insulter ^^ "
Moi ^^ non ^^ ^^^^^ ^^ ^^ ^^ ^^ ^^^ plus

"Un ptit gus gus qui vient avec le moi je suis meilleur que les gens de se topic parce que j ai vue une erreur ba ca saoule et ca donne pas envie de lui parler. Puis qui continu d enchainer sur ses soit disans compétance exepcetionnel "
Je ne suis pas meilleur que les autres, comme je l'ai déjà maintes fois dit mais que tu n'as jamais lu. Je suis juste désireux de devenir meilleur. Et parce que j'essaie, je le deviens. Meilleur de jour en jour, meilleur que je l'étais avant, plus productif, plus respecté par ses pairs au boulot, et ça rend le travail plus agréable pour tout le monde, car TOUT le monde y gagne, du chef de projet, au développeur, au client, c'est le but non ?

Parce que sur des gros projet on ne touche pas a ce qui marche pour éviter les effets de bord ca n'est pas plus compliqué que ca.

parce que quand tu viens ajouter une fonctionnalité tu es souvent loin d'avoir une compréhension total du projet. Tout l monde ne travail pas que sur un et unique projet les gens tourne.

que le les garc qui recette derriere toi va faire la recette sur ta partie en suposant et a raison que tu n'a pas été trifouillé autre part et donc ne pas se retaper une recette compléte qui est longue et fastidieuse.

après tout dépend de la modif j'ai déja fait des modif que je savais parfaitement équivalente mais juste plus propre quand cela ne coute pas de temp et que le risque est nul

remplacer des

!isEmpty(obj)
par
notEmpty(obj)

ou des truc équivalent