Dans un bouquin à la réputation établie, j'ai trouvé ce bout de code qui
vérifie la validité d'un login.
if (login.equals("".trim()){ //traitement de l'erreur ...
Je ne comprend pas l'utilité du trim().
J'ai compris que trim enlève les espaces avant et après la chaine concernée.
Mais ici la chaine est "" qui par définition ne contient rien.
Qui peut m'expliquer ce mystère ???
Tout à fait d'accord avec ce bout de code, mis à part le fait qu'il est parfois utile d'inclure le test à null dans le if, afin d'en faire un traitement d'erreur personnalisé ( plutôt que l'assert ) donc :
[code]*
if( login == null || "".equals(login.trim()) ) { // Traitement de l'erreur de paramètre }
*[/code]
Encore plus optimisé ;-)
K
Bonjour,
Là il y a clairement débat :)
Si ta fonction est appelée par du code qui te fournit parfois du login = null alors tu as raison. Mais si ce n'est pas le cas (par contrat) mais qu'il te fournit du login="" à la place. Alors je préfère le assert car celà définit plus clairement le contrat : appeler la methode doit se faire avec un login != null ...
Tout à fait d'accord avec ce bout de code, mis à part le fait qu'il est
parfois utile d'inclure le test à null dans le if, afin d'en faire un
traitement d'erreur personnalisé ( plutôt que l'assert ) donc :
[code]*
if( login == null || "".equals(login.trim()) ) {
// Traitement de l'erreur de paramètre
}
*[/code]
Encore plus optimisé ;-)
K
Bonjour,
Là il y a clairement débat :)
Si ta fonction est appelée par du code qui te fournit parfois du login =
null alors tu as raison.
Mais si ce n'est pas le cas (par contrat) mais qu'il te fournit du
login="" à la place. Alors je préfère le assert car celà définit plus
clairement le contrat : appeler la methode doit se faire avec un login
!= null ...
Tout à fait d'accord avec ce bout de code, mis à part le fait qu'il est parfois utile d'inclure le test à null dans le if, afin d'en faire un traitement d'erreur personnalisé ( plutôt que l'assert ) donc :
[code]*
if( login == null || "".equals(login.trim()) ) { // Traitement de l'erreur de paramètre }
*[/code]
Encore plus optimisé ;-)
K
Bonjour,
Là il y a clairement débat :)
Si ta fonction est appelée par du code qui te fournit parfois du login = null alors tu as raison. Mais si ce n'est pas le cas (par contrat) mais qu'il te fournit du login="" à la place. Alors je préfère le assert car celà définit plus clairement le contrat : appeler la methode doit se faire avec un login != null ...
- l'erreur 1 est évidente et largement discuté, je passe.
- l'erreur 2 est de virer les blancs dans un temporaire:
trim retournes une copie de l'instance dans lesquels les blancs sont virés, or si l'auteur pense qu'un mot de passe ne peut pas contenir d'espace en début ou en fin, il fera obligatoirement par la suite:
if (login.trim().equals(leMotDePasseDeReference)) ...
et ceci peut être dans une boucle.
il aurait donc fallu:
// étant donné String typedLogin; ... // définir String workingLogin = typedLogin.trim(); // puis if (workingLogin.equals("")) ...
- mais erreur 3: la méthode equals reçoit un objet (pas un char* global!!); donc on créé ici un autre temporaire (new String("")) également inutilement couteux.
il aurait du coder:
if (workingLogin.length() == 0) ...
ah, l'optimisation, ça se perd ! ... ;)
Bon sans rapport avec java mais tant qu'a optimiser je ferai même pas de trim. Si l'utilisateur a mis un espace tant pis pour lui il se loggera pas. Parce qu'on vire les espaces mais pourquoi pas virer toutes les classes de caractères non autorisées dans un login tant qu'on y est ...
- l'erreur 1 est évidente et largement discuté, je passe.
- l'erreur 2 est de virer les blancs dans un temporaire:
trim retournes une copie de l'instance dans lesquels les blancs sont
virés, or si l'auteur pense qu'un mot de passe ne peut pas contenir
d'espace en début ou en fin, il fera obligatoirement par la suite:
if (login.trim().equals(leMotDePasseDeReference)) ...
et ceci peut être dans une boucle.
il aurait donc fallu:
// étant donné
String typedLogin;
...
// définir
String workingLogin = typedLogin.trim();
// puis
if (workingLogin.equals("")) ...
- mais erreur 3: la méthode equals reçoit un objet (pas un char*
global!!); donc on créé ici un autre temporaire (new String(""))
également inutilement couteux.
il aurait du coder:
if (workingLogin.length() == 0) ...
ah, l'optimisation, ça se perd ! ... ;)
Bon sans rapport avec java mais tant qu'a optimiser je ferai même pas de
trim. Si l'utilisateur a mis un espace tant pis pour lui il se loggera pas.
Parce qu'on vire les espaces mais pourquoi pas virer toutes les classes
de caractères non autorisées dans un login tant qu'on y est ...
- l'erreur 1 est évidente et largement discuté, je passe.
- l'erreur 2 est de virer les blancs dans un temporaire:
trim retournes une copie de l'instance dans lesquels les blancs sont virés, or si l'auteur pense qu'un mot de passe ne peut pas contenir d'espace en début ou en fin, il fera obligatoirement par la suite:
if (login.trim().equals(leMotDePasseDeReference)) ...
et ceci peut être dans une boucle.
il aurait donc fallu:
// étant donné String typedLogin; ... // définir String workingLogin = typedLogin.trim(); // puis if (workingLogin.equals("")) ...
- mais erreur 3: la méthode equals reçoit un objet (pas un char* global!!); donc on créé ici un autre temporaire (new String("")) également inutilement couteux.
il aurait du coder:
if (workingLogin.length() == 0) ...
ah, l'optimisation, ça se perd ! ... ;)
Bon sans rapport avec java mais tant qu'a optimiser je ferai même pas de trim. Si l'utilisateur a mis un espace tant pis pour lui il se loggera pas. Parce qu'on vire les espaces mais pourquoi pas virer toutes les classes de caractères non autorisées dans un login tant qu'on y est ...
Sylvain
Kupee wrote on 25/09/2006 11:20:
Bon sans rapport avec java mais tant qu'a optimiser je ferai même pas de trim. Si l'utilisateur a mis un espace tant pis pour lui il se loggera pas. Parce qu'on vire les espaces mais pourquoi pas virer toutes les classes de caractères non autorisées dans un login tant qu'on y est ...
fonctionnellement il n'y a en effet aucune raison de trimer - l'espace est un caractère valide - ni de tester la nullité du paramètre String car l'appelant (surement lié à l'IHM) doit (par contrat) transmettre une instance valide.
mais bon, on va pas refaire le bouquin non plus ...
Sylvain.
Kupee wrote on 25/09/2006 11:20:
Bon sans rapport avec java mais tant qu'a optimiser je ferai même pas de
trim. Si l'utilisateur a mis un espace tant pis pour lui il se loggera pas.
Parce qu'on vire les espaces mais pourquoi pas virer toutes les classes
de caractères non autorisées dans un login tant qu'on y est ...
fonctionnellement il n'y a en effet aucune raison de trimer - l'espace
est un caractère valide - ni de tester la nullité du paramètre String
car l'appelant (surement lié à l'IHM) doit (par contrat) transmettre une
instance valide.
mais bon, on va pas refaire le bouquin non plus ...
Bon sans rapport avec java mais tant qu'a optimiser je ferai même pas de trim. Si l'utilisateur a mis un espace tant pis pour lui il se loggera pas. Parce qu'on vire les espaces mais pourquoi pas virer toutes les classes de caractères non autorisées dans un login tant qu'on y est ...
fonctionnellement il n'y a en effet aucune raison de trimer - l'espace est un caractère valide - ni de tester la nullité du paramètre String car l'appelant (surement lié à l'IHM) doit (par contrat) transmettre une instance valide.
mais bon, on va pas refaire le bouquin non plus ...
Tout à fait d'accord avec ce bout de code, mis à part le fait qu'il est parfois utile d'inclure le test à null dans le if, afin d'en faire un traitement d'erreur personnalisé ( plutôt que l'assert ) donc :
[code]*
if( login == null || "".equals(login.trim()) ) { // Traitement de l'erreur de paramètre }
*[/code]
Encore plus optimisé ;-)
K
Bonjour,
Là il y a clairement débat :)
Si ta fonction est appelée par du code qui te fournit parfois du login = null alors tu as raison. Mais si ce n'est pas le cas (par contrat) mais qu'il te fournit du login="" à la place. Alors je préfère le assert car celà définit plus clairement le contrat : appeler la methode doit se faire avec un login != null ...
Vive l'assert :P
A+ TM
Vive Assert certes, mais http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html vous apprendra (ou vous rapellera) que :
Do not use assertions to check the parameters of a public method.
bref, il ne faut pas confondre AssertError et IllegalArgumentException
Tout à fait d'accord avec ce bout de code, mis à part le fait qu'il
est parfois utile d'inclure le test à null dans le if, afin d'en faire
un traitement d'erreur personnalisé ( plutôt que l'assert ) donc :
[code]*
if( login == null || "".equals(login.trim()) ) {
// Traitement de l'erreur de paramètre
}
*[/code]
Encore plus optimisé ;-)
K
Bonjour,
Là il y a clairement débat :)
Si ta fonction est appelée par du code qui te fournit parfois du login =
null alors tu as raison.
Mais si ce n'est pas le cas (par contrat) mais qu'il te fournit du
login="" à la place. Alors je préfère le assert car celà définit plus
clairement le contrat : appeler la methode doit se faire avec un login
!= null ...
Vive l'assert :P
A+
TM
Vive Assert certes, mais
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html vous
apprendra (ou vous rapellera) que :
Do not use assertions to check the parameters of a public method.
bref, il ne faut pas confondre AssertError et IllegalArgumentException
Tout à fait d'accord avec ce bout de code, mis à part le fait qu'il est parfois utile d'inclure le test à null dans le if, afin d'en faire un traitement d'erreur personnalisé ( plutôt que l'assert ) donc :
[code]*
if( login == null || "".equals(login.trim()) ) { // Traitement de l'erreur de paramètre }
*[/code]
Encore plus optimisé ;-)
K
Bonjour,
Là il y a clairement débat :)
Si ta fonction est appelée par du code qui te fournit parfois du login = null alors tu as raison. Mais si ce n'est pas le cas (par contrat) mais qu'il te fournit du login="" à la place. Alors je préfère le assert car celà définit plus clairement le contrat : appeler la methode doit se faire avec un login != null ...
Vive l'assert :P
A+ TM
Vive Assert certes, mais http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html vous apprendra (ou vous rapellera) que :
Do not use assertions to check the parameters of a public method.
bref, il ne faut pas confondre AssertError et IllegalArgumentException
Tout à fait d'accord avec ce bout de code, mis à part le fait qu'il est parfois utile d'inclure le test à null dans le if, afin d'en faire un traitement d'erreur personnalisé ( plutôt que l'assert ) donc :
[code]*
if( login == null || "".equals(login.trim()) ) { // Traitement de l'erreur de paramètre }
*[/code]
Encore plus optimisé ;-)
K
Bonjour,
Là il y a clairement débat :)
Si ta fonction est appelée par du code qui te fournit parfois du login = null alors tu as raison. Mais si ce n'est pas le cas (par contrat) mais qu'il te fournit du login="" à la place. Alors je préfère le assert car celà définit plus clairement le contrat : appeler la methode doit se faire avec un login != null ...
Vive l'assert :P
A+ TM
Vive Assert certes, mais http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html vous apprendra (ou vous rapellera) que :
Do not use assertions to check the parameters of a public method.
bref, il ne faut pas confondre AssertError et IllegalArgumentException
GLH
Personne n'a parlé de méthode "public" ;-)
"Gestion de la conception par contrat" (toujours n°2 dans le classement des RFE et posé depuis 2001) http://bugs.sun.com/bugdatabase/view_bug.do?bug_idD49383
Tout à fait d'accord avec ce bout de code, mis à part le fait qu'il
est parfois utile d'inclure le test à null dans le if, afin d'en
faire un traitement d'erreur personnalisé ( plutôt que l'assert ) donc :
[code]*
if( login == null || "".equals(login.trim()) ) {
// Traitement de l'erreur de paramètre
}
*[/code]
Encore plus optimisé ;-)
K
Bonjour,
Là il y a clairement débat :)
Si ta fonction est appelée par du code qui te fournit parfois du login
= null alors tu as raison.
Mais si ce n'est pas le cas (par contrat) mais qu'il te fournit du
login="" à la place. Alors je préfère le assert car celà définit plus
clairement le contrat : appeler la methode doit se faire avec un login
!= null ...
Vive l'assert :P
A+
TM
Vive Assert certes, mais
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html vous
apprendra (ou vous rapellera) que :
Do not use assertions to check the parameters of a public method.
bref, il ne faut pas confondre AssertError et IllegalArgumentException
GLH
Personne n'a parlé de méthode "public" ;-)
"Gestion de la conception par contrat" (toujours n°2 dans le classement
des RFE et posé depuis 2001)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_idD49383
Tout à fait d'accord avec ce bout de code, mis à part le fait qu'il est parfois utile d'inclure le test à null dans le if, afin d'en faire un traitement d'erreur personnalisé ( plutôt que l'assert ) donc :
[code]*
if( login == null || "".equals(login.trim()) ) { // Traitement de l'erreur de paramètre }
*[/code]
Encore plus optimisé ;-)
K
Bonjour,
Là il y a clairement débat :)
Si ta fonction est appelée par du code qui te fournit parfois du login = null alors tu as raison. Mais si ce n'est pas le cas (par contrat) mais qu'il te fournit du login="" à la place. Alors je préfère le assert car celà définit plus clairement le contrat : appeler la methode doit se faire avec un login != null ...
Vive l'assert :P
A+ TM
Vive Assert certes, mais http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html vous apprendra (ou vous rapellera) que :
Do not use assertions to check the parameters of a public method.
bref, il ne faut pas confondre AssertError et IllegalArgumentException
GLH
Personne n'a parlé de méthode "public" ;-)
"Gestion de la conception par contrat" (toujours n°2 dans le classement des RFE et posé depuis 2001) http://bugs.sun.com/bugdatabase/view_bug.do?bug_idD49383
