Cela a son utilité par exemple si fais une comparaison de deux chaines sans être sûr qu'elles soient toutes deux instanciées, exemple en redéfinissant un Comparator, une méthode de tri, ou simplement en comparant des valeurs récupérées via l'appel de getters sur un objet, et que tu n'es pas sûr que le getter te renvoie bien une chaîne non nulle dans tous les cas (il peut y avoir eu une erreur, ou simplement une raison logique à ce qu'une chaîne soit null plutôt que vide)

Bref je pense qu'on peut trouver pas mal d'exemples, mais Google Code Search te montrera des cas réels d'utilisation.

Et enfin, aussi car il n'est pas vraiment de coutume de faire "aaa".equals...
Je veux dire, c'est peut-être coutume dans le cas d'un code très très spécifique, mais sur de gros projets, où la réutilisabilité est privilégiée, ainsi que l'internationalisation, on va rarement coder des chaînes en dur comme dans ce cas.

Le "aaa".equals... sera même l'exception niveau syntaxe, il vaut mieux en effet appeler la méthode d'une variable pour savoir à quoi cela correspond dès la première lecture, plutôt que d'apprendre seulement après lecture de la ligne complète quelle est la variable à laquelle on compare cette valeur.

Bref on aura plutôt :
s1.equals("aaa")
que "aaa".equals(s1)

Question de consistance par rapport au reste du code, où en général on indique les noms des variables en premier, pour pouvoir parcourir le code plus rapidement (car plus lisible).

En effet, si on s'amuse avec des :
"aaaaaaaaaaaaaaaaaaa".equals(s1)
puis "bb".equals(s2)
et à la ligne suivante :
"cccccccccccc".equals(s3)

on aura une difficulté à lire, car pour lire les noms de trois variables, on doit s'amuser à faire bouger les yeux dans tous les sens, et à rechercher...

Tandis que si on met le nom en premier :
s1.equals...
s2.equals...
s3.equals...

c'est plus clair car tout est bien indenté

"aaaaaaaaaaaaaaaaaaa".equals(s1)

ou équivalent
est un jeux d'écriture très souvent utilisé.

premiere fois que j'ai vue cette facon d'écrire c'était dans les sources d'un framework.

C'est souvent utilisé, mais pas forcément la bonne façon de faire, du moins pas la plus propre (Oui, j'ai peut-être un peu trop l'habitude de vouloir profiter de l'expérience de développeurs plus doués que moi, et à cette fin je lis beaucoup d'ouvrages sur la façon d'être productif, efficace, et propre quand on programme)

Et comme je l'ai expliqué, ça ne fonctionne pas dans tous les cas, en particulier si on a la même chaîne à plusieurs endroits du code, cette façon de faire oblige à modifier plusieurs endroits du code pour juste changer le contenu de la chaîne.

Et si on veut internationaliser, c'est encore moins la bonne façon de faire.

Et quand on a de nombreuses chaînes du genre à tester, il vaut mieux repenser à la façon dont le programme est fait, car il y a vraiment un problème de réflexion, et des questions à se poser.

En effet c'est une méthode peu sûre, peu générique, et cela nuit à la maintenance et la lisibilité du code;
bref à privilégier pour du code écrit à la va vite, mais en entreprise on éviter ce genre de choses sous peine de se taper les foudres de ses collègues

"bref à privilégier pour du code écrit à la va vite, mais en entreprise on éviter ce genre de choses sous peine de se taper les foudres de ses collègues"

pas d'accord du tout mais bon chacun son avis.Pour moi tout est une question de context.

de plus si il y a bien un endroit ou les codes sont écrit a la va vite c'est bien en entreprise.

Cela dépend peut-être du contexte, mais coder en dur des chaînes des règles de validation du modèle, des business rules plic ploc à gauche à droite sans unifier et centraliser ces définitions, c'est pas une bonne façon de faire, ce n'est pas une bonne découpe du code.
Ce n'est pas propre à la réutilisabilité.
Si on fait de nombreux tests de la chaîne "aaaa" dans le code, il vaut mieux alors en faire une constante.
Et ce même dans le cas où on ne la définit qu'une fois.
Il vaut mieux avoir sous les yeux, à un endroit, les chaînes appartenant au même contexte, que de les éparpiller.
C'est simplement une question de programmer avec une vision à long terme (maintenabilité, réutilisabilité, internationalisation, réduction de bugs)

Ensuite, c'est bel et bien dans le monde professionnel que j'ai l'occasion de voir ces règles les plus souvent appliquées.
Evidemment, celà dépend aussi de la volonté du développeur à bien faire son travail.
Mais j'ai l'amour du travail bien fait, et j'aime m'améliorer constamment, et écrire du code fonctionnel et lisible. J'applique la règle du boy scout, qui est de toujours laisser le code plus propre que je ne l'ai trouvé.

Chacun son avis comme tu dis.

Evidemment, celà dépend aussi de la volonté du développeur à bien faire son travail.

tu viens du monde des bisounours ?LOL

dans 90% du temp la facon de faire ne dépendra pas du développeur, tout simplement parce qu on ne lui laissera pas le temps ^^

Compte à juger si une chaine de caractere.equals quelque chopse est propre ou non je ne pense pas que tu es le niveau et sans doute moi non plus comme je l ai dit c'est une question de context je pense. Je l ai vue écris dans des framework très sérieux (Telosys) par des gens sans doute bien meilleur que toi et moi. Dans tout les cas c'est une maniere inteligente d'éviter des exception et d'éviter des test inutiles. Donc ils avaient surment leurs raisons.

sur ce...

"tu viens du monde des bisounours ?LOL "
Non, seulement je fais mon possible pour en apprendre plus chaque jour et en faire profiter mon travail et mes collègues. Bref heureusement qu'il y a des gens désireux de devenir meilleurs.

"dans 90% du temp la facon de faire ne dépendra pas du développeur, tout simplement parce qu on ne lui laissera pas le temps ^^ "
C'est sûr que si le développeur baisse sa culotte, on peut lui imposer ce qu'on veut. Là où je bosse il y a un respect du travail bien fait, une volonté d'améliorer l'existant. Alors oui je fais ptet partie des 10%, pour ça d'ailleurs que nous sommes productifs, car notre code est amélioré dès que possible, pour en faire profiter l'équipe, la productivité, et donc les clients (en effet, rien de pire que de reprendre le code d'un ancien collègue, si ce code est illisible et mal pensé ) qui profitent d'un logiciel de meilleure qualité, plus robuste aux bugs puisque plus facile à maintenir.

Le refactoring n'existe pas pour rien.

"Compte à juger si une chaine de caractere.equals quelque chopse est propre ou non je ne pense pas que tu es le niveau et sans doute moi non plus"
Admettons

" Je l ai vue écris dans des framework très sérieux (Telosys) par des gens sans doute bien meilleur que toi et moi"
Sans doute pas meilleurs , non, j'ai vu le code de leur framework, il n'est ni sérieux, ni écrit par des gens compétents.
As-tu au moins jeté un oeil avant de promouvoir ce framework ?
Sais-tu qui l'utilise ?

Amusons nous à regarder son code.
Première recherche sur Google Code Search :

http://grepcode.com/file/repo1.maven.org/maven2/org.objectweb.telosys/telosys-framework/1.1.0/org/objectweb/telosys/util/MonthCalendar.java

"if (sLang.toUpperCase().equals("FR"))"
aucune notion des constantes ou des enum n'est mise à profit pour ce code.
Alors que les locale, l'encodage, l'internationalisation font partie des choses les plus courantes à gérer dans des gros projets , frameworks etc.

"return AMONTHSFR[iMonth];
"return AMONTHSEN[iMonth];"
Aucune notion de réutilisabilité... ils ne savent peut-être pas que l'héritage et les interface ça existe en Java ?
Il ne devrait pas être nécessaire d'avoir à repasser dans le code de tout un projet juste si on rajoute une langue. Cela devrait être le plus générique possible. Diminuer la dépendance entre les différentes couches.

"//--- Changement de ligne
"iLig++;"
Ils rient ? Ils commentent vraiment ce que fait une instruction ? En français en plus ? Le code doit pouvoir être lu par n'importe quel programmeur, d'où l'utilisation de l'anglais comme norme...

"//--- Jour suivant dans le calendrier
"calendar.add(Calendar.DAY_OF_MONTH, +1);"
Merci de rappeler ce que le code dit déjà... plus explicitement.

bref ça me fait mal de voir ce genre de code. Il y a de quoi alimenter pas mal de conversations entre programmeurs.

Dans tout les cas c'est une maniere inteligente d'éviter des exception et d'éviter des test inutiles. Donc ils avaient surment leurs raisons.
Manière intelligente ? Pas vraiment, c'est une manière de causer une perte de temps et de dévoiler un manque de connaissance des principes fondamentaux de la programmation Objet, dont font partie l'héritage et le polymorphisme par exemple.
Dans les exemples donnés, on remarque bien la mauvaise compréhension du polymorphisme.
On remarque aussi l'inutilité des commentaires proposés.

Un commentaire est là pour dire ce que le code ne peut expliquer. Quand le code est bien écrit et parle de lui même, pas besoin de commentaire.
Mais dans le cas montré en exemple, ce type de commentaire n'apporte aucune information.
Peut-être que le programmeur ayant écrit ce code était en stage, ou que son code n'a jamais été relu par ses collèges.
Celà arrive, dans les boîtes où l'intérêt du travail bien fait ne fait pas partie des priorités.

Soit, 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. Je te conseille le livre : http://conception.developpez.com/livres/?page=livresProc#L9782744023279

Je pense qu'il serait utile que tout programmeur voulant devenir meilleur le lise.

Wow, encore actif ce topic ?

J'ai lancer un débat sans faire gaffe...

ca va ta pas l air de péter plus que ton cul lol

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

ho que ca me rend triste lol ^^
tu sais des garc comme toi dans ma carriere j en n ai croiser pas mal ^^
ca n est en général pas très interessant. souvent a critiquer mais en général leur code est loin d etre aussi bon qu il essaye de le faire croire. et a mon avis tu es bien pareil

montre nous un de tes projets voir un code si merveilleux que ca ^^

^^ oh ^^ dommage que ^^ ça te rende ^^ triste ^^
Plus sérieusement, je crois juste que tu trolles, car quelqu'un ayant véritablement fait carrière et ayant travaillé avec de nombreux développeurs aurait appris quelque chose : programmer.

Et tu n'as pas l'air d'avoir appris à programmer. Beaucoup de gens savent mal programmer, ça n'est pas difficile, il suffit de ne pas réfléchir plus loin que le bout de son nez quand on programme et de n'avoir jamais eu à relire son code des mois ou années après, pour remarquer à quel point il est emprunt de défauts et peu propice à la maintenance.

Peut-être que tu feras carrière dans un environnement où il est possible de développer des compétences un peu plus étoffées

Beaucoup trop de projets sont victimes du coûté engendré par la maintenance, due souvent à du code très facile à écrire au début, mais qui devient illisible et pénalisant pour les évolutions du projet, rendant difficile la maintenance, engendrant des bugs, de la redondance de code, et beaucoup de projets se sont vus ainsi arrêtés nets, ayant dépassé de loin les budgets alloués, juste car personne ne prenait de véritable bonne décision.

au moins ce qui est cool c'est que tu te prend pas pour de la merde ^^

hey mon garc tu es juste développeur arrete de te prendre pour un dieux hein...
c'est un métier lol tu n'es pas au dessus d'un mec qui fait le ménage.

pas parce que tu arrive a écrire 2 jolies de code qu il faut de la péter et etre méprisant^^

surtout qu a par ton blabla rien ne prouve ton sois disant haut niveau^^

on n'es sur un forum jeux video tu te permet des conseil donc montre un de tes jeux et après tu pourras l ouvrir.

Le refactoring de code me sert tous les jours;
Quand tu passes de 1500 lignes à 200 lignes pour faire la même chose, ou de 90 lignes à 25 lignes pour faire la même chose, tu comprends que c'est pas juste une question de style mais aussi d'efficacité
Je m'en fous de pas avoir le niveau que tu prétends avoir, au moins j'ai des connaissances utiles.
Je ne suis pas méprisant, mais tu sembles complètement fermé à ce que tu ne connais pas. Et tu sembles aussi passer complètement à côté de l'art du métier.
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.
Et pour un code, c'est pareil, tant qu'il y a des déchets dedans, il faut nettoyer. Jusqu'à avoir un code qui fait parfaitement ce qu'il doit faire, de la façon la plus simple et la plus courte possible.

Que de jolie blabla mais toujours pas de post de jeux pardon de ton "art" codé par tes petites mimines

J'en déduit que tu es surtout bon dans la théorie mais que la pratique

Tu peux en déduire ce que tu veux tu sais, on peut tous faire des suppositions; Je ne suis pas venu parler de moi mais conseiller l'auteur sur comment régler son problème de la meilleure façon, après il y a eu des objections, j'y ai répondu en donnant de vrais exemples et conseils qui si on réfléchit, sont effectivement des bonnes pratiques de plus en plus recommandées.
Ce n'est pas sans raison.
Programmer sans réfléchir n'est pas une solution viable sur le long terme.
Plus le nombre de lignes de code augmente dans un projet, plus la complexité croit, et plus il est nécessaire de repasser dans du code complexe existant. Dans ces cas là, il y a toutes les raisons de refactorer du code dès que l'on sent une complexité inutile engendrée par des ajouts de code petits à petits.

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.

En attendant tu n'as toujours rien écrit comme code.

et oui on devient bon développeur avec la pratique pas en lisant des livres et en critiquand a tout va le travail des autres.

tu apprendras en codant que c'est toujours plus facile de critiquer le code de quelqu un que d'écrire le sien.

en attendent continu de ne pas coder et de lire tu as bien raison ^^
en attendant moi je m éclate en codant et ce que pense les sois disans élite de la programmation comme toi qui n ont jamais rien coder de leur vie on s en fou pas mal lol.

Peux-tu par exemple donner une meilleure solution que ce que j'ai proposé pour le equals ?
une solution robuste aux NPE, pour comparer deux variables de type String dont on ne connait pas la valeur à l'avance, mais juste le nom ?

Peux-tu comprendre pourquoi il est mal d'avoir des centaines de références à "FR" dans un code ?
Que faudra-t-il faire si un jour on veut rajouter "IT" ou "NL" à ces mêmes endroits ? Combien d'endroits faudra-t-il modifier ?
Et si on avait utilisé le polymorphisme ? En écrivant une méthode qui en fonction d'un argument qui est la langue, effectue le traitement correspondant à la langue donnée en paramètre ?
Il y aurait alors ZERO modification à faire à ces endroits là, et si le code est bien fait, il n'y aurait même rien à modifier, à part en Base de données, càd rajouter un record, la langue.

Trouves-tu un commentaire véritablement utile à cette instruction ?
"i++"

acemicka : tu crois vraiment que quelqu'un n'ayant jamais programmé pourrait faire la différence entre un bon et un mauvais code ?
Et quant à tes allusions sur le fait que je n'ai jamais programmé, c'est juste de la provocation inutile. Malheureusement ça ne fonctionne pas. Mais continue, si tu aimes te défouler ainsi en dévoilant ton manque de compréhension et de professionnalisme dans tes propos, c'est tout à ton honneur.