Les expressions régulières comment ça marche en java concrètement?
Je voudrais backslasher mes chaînes de caractères avant de les injecter
dans les requêtes SQL.
Je fais lu = lu.replaceAll("[']","'");
Mais le contenu de lu n'a pas changé!
Les expressions régulières comment ça marche en java concrètement?
Je voudrais backslasher mes chaînes de caractères avant de les injecter
dans les requêtes SQL.
Je fais lu = lu.replaceAll("[']","'");
Mais le contenu de lu n'a pas changé!
Les expressions régulières comment ça marche en java concrètement?
Je voudrais backslasher mes chaînes de caractères avant de les injecter
dans les requêtes SQL.
Je fais lu = lu.replaceAll("[']","'");
Mais le contenu de lu n'a pas changé!
Comme ça en réfléchissant 5 minutes je me dit que c'est de
l'optimisation fine qui ne doit pas s'utiliser n'importe comment et
qui ne doit être que rarement utilisée.
Plus généralement utiliser "==" à la place de equals peut être très
dangereux. A la moindre inatention dans l'affectation des String, ont
se retrouve avec un test d'égalité qui ne fait pas se qu'on attend de
lui, et ce genre de truc est très pénible à chercher parce que ça
n'explose pas...
A utiliser avec parcimonie, selon moi...
Comme ça en réfléchissant 5 minutes je me dit que c'est de
l'optimisation fine qui ne doit pas s'utiliser n'importe comment et
qui ne doit être que rarement utilisée.
Plus généralement utiliser "==" à la place de equals peut être très
dangereux. A la moindre inatention dans l'affectation des String, ont
se retrouve avec un test d'égalité qui ne fait pas se qu'on attend de
lui, et ce genre de truc est très pénible à chercher parce que ça
n'explose pas...
A utiliser avec parcimonie, selon moi...
Comme ça en réfléchissant 5 minutes je me dit que c'est de
l'optimisation fine qui ne doit pas s'utiliser n'importe comment et
qui ne doit être que rarement utilisée.
Plus généralement utiliser "==" à la place de equals peut être très
dangereux. A la moindre inatention dans l'affectation des String, ont
se retrouve avec un test d'égalité qui ne fait pas se qu'on attend de
lui, et ce genre de truc est très pénible à chercher parce que ça
n'explose pas...
A utiliser avec parcimonie, selon moi...
Ah bon, il faut éviter ?
Dommage je trouve, parce que question lisibilité, il faut avouer que ==,
c'est quand même nettement au-dessus. Surtout si on compare les
résultats d'imbrications de méthodes ...
______________________________________
Vincent a écrit, le 30/01/2004 16:47 :Comme ça en réfléchissant 5 minutes je me dit que c'est de
l'optimisation fine qui ne doit pas s'utiliser n'importe comment et
qui ne doit être que rarement utilisée.
(...)Plus généralement utiliser "==" à la place de equals peut être très
dangereux. A la moindre inatention dans l'affectation des String, ont
se retrouve avec un test d'égalité qui ne fait pas se qu'on attend de
lui, et ce genre de truc est très pénible à chercher parce que ça
n'explose pas...
A utiliser avec parcimonie, selon moi...
Ah bon, il faut éviter ?
Dommage je trouve, parce que question lisibilité, il faut avouer que ==,
c'est quand même nettement au-dessus. Surtout si on compare les
résultats d'imbrications de méthodes ...
______________________________________
Vincent a écrit, le 30/01/2004 16:47 :
Comme ça en réfléchissant 5 minutes je me dit que c'est de
l'optimisation fine qui ne doit pas s'utiliser n'importe comment et
qui ne doit être que rarement utilisée.
(...)
Plus généralement utiliser "==" à la place de equals peut être très
dangereux. A la moindre inatention dans l'affectation des String, ont
se retrouve avec un test d'égalité qui ne fait pas se qu'on attend de
lui, et ce genre de truc est très pénible à chercher parce que ça
n'explose pas...
A utiliser avec parcimonie, selon moi...
Ah bon, il faut éviter ?
Dommage je trouve, parce que question lisibilité, il faut avouer que ==,
c'est quand même nettement au-dessus. Surtout si on compare les
résultats d'imbrications de méthodes ...
______________________________________
Vincent a écrit, le 30/01/2004 16:47 :Comme ça en réfléchissant 5 minutes je me dit que c'est de
l'optimisation fine qui ne doit pas s'utiliser n'importe comment et
qui ne doit être que rarement utilisée.
(...)Plus généralement utiliser "==" à la place de equals peut être très
dangereux. A la moindre inatention dans l'affectation des String, ont
se retrouve avec un test d'égalité qui ne fait pas se qu'on attend de
lui, et ce genre de truc est très pénible à chercher parce que ça
n'explose pas...
A utiliser avec parcimonie, selon moi...
gloops wrote in message news:<bvii33$el4$...Ah bon, il faut éviter ?
Dommage je trouve, parce que question lisibilité, il faut avouer que ==,
c'est quand même nettement au-dessus. Surtout si on compare les
résultats d'imbrications de méthodes ...
C'est un choix à mon avis la règle générale c'est: "pas de ==", mais
éventuellement tu peux déroger ponctuellement si:
- la lisibilité en soufre vraiment.
ET
- la conception ne te permet pas de simplifier les expressions.
ET
- tu as pris toutes les garanties possibles pour ne pas trouver
dans le cas que je cite dans le message précédent...
Pas du tout d'accord.
______________________________________
Vincent a écrit, le 30/01/2004 16:47 :Comme ça en réfléchissant 5 minutes je me dit que c'est de
l'optimisation fine qui ne doit pas s'utiliser n'importe comment et
qui ne doit être que rarement utilisée.
(...)Plus généralement utiliser "==" à la place de equals peut être très
dangereux. A la moindre inatention dans l'affectation des String, ont
se retrouve avec un test d'égalité qui ne fait pas se qu'on attend de
lui, et ce genre de truc est très pénible à chercher parce que ça
n'explose pas...
A utiliser avec parcimonie, selon moi...
gloops <gloops@niark.fr> wrote in message news:<bvii33$el4$1@news-reader3.wanadoo.fr>...
Ah bon, il faut éviter ?
Dommage je trouve, parce que question lisibilité, il faut avouer que ==,
c'est quand même nettement au-dessus. Surtout si on compare les
résultats d'imbrications de méthodes ...
C'est un choix à mon avis la règle générale c'est: "pas de ==", mais
éventuellement tu peux déroger ponctuellement si:
- la lisibilité en soufre vraiment.
ET
- la conception ne te permet pas de simplifier les expressions.
ET
- tu as pris toutes les garanties possibles pour ne pas trouver
dans le cas que je cite dans le message précédent...
Pas du tout d'accord.
______________________________________
Vincent a écrit, le 30/01/2004 16:47 :
Comme ça en réfléchissant 5 minutes je me dit que c'est de
l'optimisation fine qui ne doit pas s'utiliser n'importe comment et
qui ne doit être que rarement utilisée.
(...)
Plus généralement utiliser "==" à la place de equals peut être très
dangereux. A la moindre inatention dans l'affectation des String, ont
se retrouve avec un test d'égalité qui ne fait pas se qu'on attend de
lui, et ce genre de truc est très pénible à chercher parce que ça
n'explose pas...
A utiliser avec parcimonie, selon moi...
gloops wrote in message news:<bvii33$el4$...Ah bon, il faut éviter ?
Dommage je trouve, parce que question lisibilité, il faut avouer que ==,
c'est quand même nettement au-dessus. Surtout si on compare les
résultats d'imbrications de méthodes ...
C'est un choix à mon avis la règle générale c'est: "pas de ==", mais
éventuellement tu peux déroger ponctuellement si:
- la lisibilité en soufre vraiment.
ET
- la conception ne te permet pas de simplifier les expressions.
ET
- tu as pris toutes les garanties possibles pour ne pas trouver
dans le cas que je cite dans le message précédent...
Pas du tout d'accord.
______________________________________
Vincent a écrit, le 30/01/2004 16:47 :Comme ça en réfléchissant 5 minutes je me dit que c'est de
l'optimisation fine qui ne doit pas s'utiliser n'importe comment et
qui ne doit être que rarement utilisée.
(...)Plus généralement utiliser "==" à la place de equals peut être très
dangereux. A la moindre inatention dans l'affectation des String, ont
se retrouve avec un test d'égalité qui ne fait pas se qu'on attend de
lui, et ce genre de truc est très pénible à chercher parce que ça
n'explose pas...
A utiliser avec parcimonie, selon moi...
gloops wrote in message news:<bvii33$el4$...Ah bon, il faut éviter ?
Dommage je trouve, parce que question lisibilité, il faut avouer que ==,
c'est quand même nettement au-dessus. Surtout si on compare les
résultats d'imbrications de méthodes ...
C'est un choix à mon avis la règle générale c'est: "pas de ==", mais
éventuellement tu peux déroger ponctuellement si:
- la lisibilité en soufre vraiment.
ET
- la conception ne te permet pas de simplifier les expressions.
ET
- tu as pris toutes les garanties possibles pour ne pas trouver
dans le cas que je cite dans le message précédent...
Pas du tout d'accord.
Le problème n'est pas lié à la lisibilité ou la simplification des expressions ou toute autre chose encore.
A mon avis tu aurais du lire le thread intégralement avant de monter
Tu peux TOUJOURS utiliser == pour tout ce qui est primitives (boolean, int, long, ...)
ça tombe sous le sens, il faudrait être tordu pour encapsuler les
Tu DOIS TOUJOURS utiliser == pour les variables d'objets, si tu veux être sûr qu'ils font référence au même emplacement mémoire.
Ben oui equals ne s'applique pas...
Tu DOIS TOUJOURS utiliser equals() pour les variables d'objets, si tu veux être sûr que leur contenu soient le même, mais ils peuvent être deux objets mémoire différents.
En résumé:
== retourne TRUE si la variable pointe vers la même adresse mémoire.
.equals() retourne TRUE si le contenu est le même.
Déjà dit en long et large et en travers dans le thread...
gloops <gloops@niark.fr> wrote in message news:<bvii33$el4$1@news-reader3.wanadoo.fr>...
Ah bon, il faut éviter ?
Dommage je trouve, parce que question lisibilité, il faut avouer que ==,
c'est quand même nettement au-dessus. Surtout si on compare les
résultats d'imbrications de méthodes ...
C'est un choix à mon avis la règle générale c'est: "pas de ==", mais
éventuellement tu peux déroger ponctuellement si:
- la lisibilité en soufre vraiment.
ET
- la conception ne te permet pas de simplifier les expressions.
ET
- tu as pris toutes les garanties possibles pour ne pas trouver
dans le cas que je cite dans le message précédent...
Pas du tout d'accord.
Le problème n'est pas lié à la lisibilité ou la simplification des expressions ou toute autre chose encore.
A mon avis tu aurais du lire le thread intégralement avant de monter
Tu peux TOUJOURS utiliser == pour tout ce qui est primitives (boolean, int, long, ...)
ça tombe sous le sens, il faudrait être tordu pour encapsuler les
Tu DOIS TOUJOURS utiliser == pour les variables d'objets, si tu veux être sûr qu'ils font référence au même emplacement mémoire.
Ben oui equals ne s'applique pas...
Tu DOIS TOUJOURS utiliser equals() pour les variables d'objets, si tu veux être sûr que leur contenu soient le même, mais ils peuvent être deux objets mémoire différents.
En résumé:
== retourne TRUE si la variable pointe vers la même adresse mémoire.
.equals() retourne TRUE si le contenu est le même.
Déjà dit en long et large et en travers dans le thread...
gloops wrote in message news:<bvii33$el4$...Ah bon, il faut éviter ?
Dommage je trouve, parce que question lisibilité, il faut avouer que ==,
c'est quand même nettement au-dessus. Surtout si on compare les
résultats d'imbrications de méthodes ...
C'est un choix à mon avis la règle générale c'est: "pas de ==", mais
éventuellement tu peux déroger ponctuellement si:
- la lisibilité en soufre vraiment.
ET
- la conception ne te permet pas de simplifier les expressions.
ET
- tu as pris toutes les garanties possibles pour ne pas trouver
dans le cas que je cite dans le message précédent...
Pas du tout d'accord.
Le problème n'est pas lié à la lisibilité ou la simplification des expressions ou toute autre chose encore.
A mon avis tu aurais du lire le thread intégralement avant de monter
Tu peux TOUJOURS utiliser == pour tout ce qui est primitives (boolean, int, long, ...)
ça tombe sous le sens, il faudrait être tordu pour encapsuler les
Tu DOIS TOUJOURS utiliser == pour les variables d'objets, si tu veux être sûr qu'ils font référence au même emplacement mémoire.
Ben oui equals ne s'applique pas...
Tu DOIS TOUJOURS utiliser equals() pour les variables d'objets, si tu veux être sûr que leur contenu soient le même, mais ils peuvent être deux objets mémoire différents.
En résumé:
== retourne TRUE si la variable pointe vers la même adresse mémoire.
.equals() retourne TRUE si le contenu est le même.
Déjà dit en long et large et en travers dans le thread...
