Compter le nombre de mots doublons

Compter le nombre de mots doublons - Java - Programmation

Marsh Posté le 04-01-2006 à 19:18:08    

Bonjour,
Je dois réaliser un exercice de cours, un programme en Java, qui parcourt un fichier texte, qui compte le nombre de mots au total du fichier puis enfin un affichage du type :
 
Mots         Nombre
maison ..... 3x
porte........ 2x
etc...
 
Ce que j 'arrive a faire : Je parcours mon fichier texte, j'extrais les mots de plus de 2 caracteres, et je les affiche pour verifier.
Maintenant, il faudrai que je stocke mes mots dans un containeur (lequel ?) et que je verifie si le mot ajouter n'existe pas deja.
 
Il faut aussi que je compte combien de fois j'ai rencontré le mot.
 
Quelle methode serait la plus appropriée ?
Merci
 
ps : sujet de l'exo
http://users.rockweb.org/java/iris [...] rJava1.pdf
(question 3-4)
 
edit : voila mon code pour le moment (il suit l'ordre des questions, donc oui il peut etre simplifier facilement, en commencant pas l expression reguliere par exemple )


Message édité par Pookie le 05-01-2006 à 20:52:21
Reply

Marsh Posté le 04-01-2006 à 19:18:08   

Reply

Marsh Posté le 04-01-2006 à 20:28:24    

stocker tes mots dans un Vector, ca devrait le faire. après avec un boolean contains(object) tu testes facilement si le mot y est déjà

Reply

Marsh Posté le 04-01-2006 à 20:33:11    

j'ai trouvé un moyen plus simpa :)
les Maps
 
Je créais ma map et ensuite je verifie par la fonction  
maMap.containsKey(Word);
 
ca me retourne un boolean.
Tres tres pratique.
Ca permet par rapport au vertor d avoir le mot + un chiffre, comme il me faut

Reply

Marsh Posté le 04-01-2006 à 20:39:36    

trevor a écrit :

stocker tes mots dans un Vector, ca devrait le faire. après avec un boolean contains(object) tu testes facilement si le mot y est déjà


J'utiliserais plutôt une hashmap perso, à chaque mot un test si la hashmap contient déjà le mot en clé (containsKey), si non on ajoute le mot en clé et "1" en valeur, si oui on incrémente la valeur de 1
 
Comme ça à la fin on a un compte bien propre pour chaque mot [:spamafote]
 
edit: fuck, grillé [:zytrasnif]


Message édité par masklinn le 04-01-2006 à 20:40:07

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 04-01-2006 à 20:41:44    

oui, si tu comptes stocker en + le nb d'occurrence, alors la hashmap est parfaite :)
disons que c'est juste un Vector en mieux ;)

Reply

Marsh Posté le 04-01-2006 à 20:43:50    

trevor a écrit :

disons que c'est juste un Vector en mieux ;)


Heuuu non, le seul lien entre les deux, c'est que tous deux sont des conteneurs [:pingouino]
 
Les maps ne sont pas "mieux" que les listes de manière absolue, les utilisations ne sont pas les mêmes [:spamafote]


Message édité par masklinn le 04-01-2006 à 20:44:34

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 04-01-2006 à 20:45:04    

trevor a écrit :

disons que c'est juste un Vector en mieux ;)


ok ouais,  [:x-httpd-php]


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 04-01-2006 à 20:47:31    

rahh faites pas comme si vous aviez pas compris quand même

Reply

Marsh Posté le 04-01-2006 à 20:58:28    

et même qu'en face du mot dans la hashMap, tu peux mettre un petit OcurencesCounter mutable ça te simplifie le code et est plus efficace.
 

Code :
  1. private static class OcurencesCounter{
  2.   private int value = 1;
  3.   public int getValue() {
  4.     return value;
  5.   }
  6.  
  7.   public int increment() {
  8.     value++;
  9.   }
  10. }


 

Code :
  1. private void registerWord(String word) {
  2.   OcurencesCounter counter = (OcurencesCounter)map.get(word);
  3.   if(holder != null)
  4.     counter.increment();
  5.   else
  6.     map.put(word, new OcurencesCounter());
  7. }


 
voiloù (code non vérifé)


Message édité par nraynaud le 04-01-2006 à 20:59:47
Reply

Marsh Posté le 04-01-2006 à 21:01:50    

Pookie a écrit :

je vous remercie ;)
C'est vraiment genial ce "Map"
 
Par contre, niveau affichage, c est un peu le bordel.
Il m'affiche le mot + le nombre d'occurence+ , +mot 2 ....
c est pas tres lisibles mais bon
 
sinon je poste mon code si jamais ca peu depanner cetains
 

Code :
  1. import java.io.*;
  2. import java.util.*;
  3. public class Alice
  4. {
  5. public static void main (String[]args)
  6. {
  7.  try
  8.  {
  9.   BufferedReader bfr = new BufferedReader (new FileReader ("Alice.txt" ));
  10.   String line;
  11.   Map maMap = new HashMap();
  12.   Integer Mot = new Integer(1);
  13.   while ((line = bfr.readLine())!= null)
  14.   {
  15.    String [] tokens = line.split("\\b" );
  16.    int i = 0;
  17.    while (tokens.length > i)
  18.    {
  19.     String Word = tokens[i++];
  20.     Word = Word.toLowerCase();
  21.     Word = Word.replaceAll("[^a-z]","" );
  22.     if(Word.length()>2)
  23.     {
  24.      if (maMap.containsKey(Word)== false )
  25.      {
  26.       maMap.put(Word, Mot);
  27.      }
  28.      else
  29.      {
  30.       String nombre_key = maMap.get(Word).toString();
  31.       Integer MotStoke = new Integer(nombre_key);
  32.       int temp = Mot.intValue()+ MotStoke.intValue();
  33.       Integer nbMot = new Integer (temp);
  34.       Mot.toString();
  35.       maMap.remove(Word);
  36.       maMap.put(Word, nbMot);
  37.      }
  38.     }
  39.    }
  40.   }
  41.   System.out.println(maMap);
  42.  }
  43.   catch (Exception e) {
  44.   System.out.println(e);
  45.  }
  46. }
  47. }


 
 
bonne soirée,
Merci


ah ! oui !  
 
On a pas le même style [:pingouino]

Reply

Marsh Posté le 04-01-2006 à 21:01:50   

Reply

Marsh Posté le 04-01-2006 à 21:07:58    

  • Pourquoi ya des toString partout? (accessoirement avec Java1.5 les hashmaps sont des generics, donc tu te débarasse de tous les casts et autres)
  • Pourquoi dégages tu les lettres accentuées?
  • Pourquoi ne pas créer tes nombres au moment du put? (map.put(word, new Integer(1)); map.put(word, new Integer(occurences))); de même en 1.5 l'autoboxing doit gérer ce genre de conneries tout seul non? (--, nraynaud, je me plante encore ou pas?)
  • les variables locales en minuscules :o
  • le map.remove() ne sert strictement à rien: si une clé existe déjà, un "put" avec cette clé remplace simplement la valeur associée.
  • Quel est l'intérêt de "temp = Mot.intValue()+MotStoke.intValue()" par rapport à "temp = MotStoke.intValue() + 1" [:petrus dei]
  • Accessoirement, faut en vouloir pour comprendre que MotStoke est le nombre d'occurences précédentes du mot dans le texte [:pingouino]
  • Tes boucles/conditions de boucles sont franchement bizarres [:pingouino] (pourquoi ne pas utiliser un simple for [:petrus dei])


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 04-01-2006 à 21:12:43    

Mask> ouais, je pense que c'est une des conditions de l'autoboxing, mais je reste sur mon holder mutable, qui ne provoque aucun ré-hachage et aucune création d'objets.

Reply

Marsh Posté le 04-01-2006 à 21:14:03    

le truc qui est bien vu, c'est \b.

Reply

Marsh Posté le 04-01-2006 à 21:15:15    

nraynaud a écrit :

Mask> ouais, je pense que c'est une des conditions de l'autoboxing, mais je reste sur mon holder mutable, qui ne provoque aucun ré-hachage et aucune création d'objets.


Chuis bien d'accord, mais bon :o


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 04-01-2006 à 21:39:57    

masklinn a écrit :

  • Pourquoi ya des toString partout? (accessoirement avec Java1.5 les hashmaps sont des generics, donc tu te débarasse de tous les casts et autres)
  • Pourquoi dégages tu les lettres accentuées?
  • Pourquoi ne pas créer tes nombres au moment du put? (map.put(word, new Integer(1)); map.put(word, new Integer(occurences))); de même en 1.5 l'autoboxing doit gérer ce genre de conneries tout seul non? (--, nraynaud, je me plante encore ou pas?)
  • les variables locales en minuscules :o
  • le map.remove() ne sert strictement à rien: si une clé existe déjà, un "put" avec cette clé remplace simplement la valeur associée.
  • Quel est l'intérêt de "temp = Mot.intValue()+MotStoke.intValue()" par rapport à "temp = MotStoke.intValue() + 1" [:petrus dei]
  • Accessoirement, faut en vouloir pour comprendre que MotStoke est le nombre d'occurences précédentes du mot dans le texte [:pingouino]
  • Tes boucles/conditions de boucles sont franchement bizarres [:pingouino] (pourquoi ne pas utiliser un simple for [:petrus dei])


je tiens compte de tes remarques, je te remercie :)
C'est un exercice de decouverte de Java (notre 1er exercice en java). Donc c'est sur que le style doit pas etre tres tres jolie :) je m'en excuse.
Je vais  rendre tout ca, tout beau tout joli ;)

Reply

Marsh Posté le 04-01-2006 à 22:22:21    

Si tu fais ça sérieusement, je te file ma version complète (mais non testée, 'faut pas abuser) des choses.

Reply

Marsh Posté le 04-01-2006 à 23:24:48    

Perso, après avoir lu les remarques de certains intervenants, j'ai envie de rammener ma fraise.
 
Alors...
 
En gros, y'a quelques années, un langage a été inventé, et son cahier des charge faisait a peut près 3 fois plus de pages que la norme ISO toute entière, soit le plus gros cahiers des charges jamais réalisé à ce jour. Il avait pour objectif premier d'être infaillible, et permettre, à tout instant dans le source, de savoir exactement ce qu'on faisait.
 
Une des solutions apportées pour répondre à cette condition fut le choix d'un langage "très fortement typé". C'est à dire que même si on crééait un type à dérivé partir d'un type standard, il était absolument impossible de faire des oppérations combinant ces deux types, sans au préalable faire un cast ou une surcharge des oppérateurs.
Grace à ça, plus d'autres points importants, à partir du moment où un programme compile, on est sûr à 100% qu'il est implantable.
 
Ce langage, c'est ADA. (pas la version 95, la version première du nom, la 95 a apporté un fort lot d'instabilité, et du coup un programme qui compile peut planter). C'est ce langage qui fait voler Ariane, qui a permis de mettre au point les modèles physique du TGV, ou simplement qui guide un missile nucléaire, l'armé américaine étant le rédacteur du cahier des charges.
 
J'ai appris à développer sur ce langage, et je reste persuadé que ses parties les plus chiantes sont les parties les plus importantes d'un programme. Ainsi, je dénonce les transtypages implicites, et je vote pour les transtypages explicites.
 
Ainsi, quelque soit le type d'objet qu'on utilise, et quelque soit s méthode par défaut, si on veut le mélanger avec une variable de type String, il est pour moins impératif de mettre un ".toString()", ou appel à toute autre méthode qui retourne une chaîne, quand bien même ce serait la méthode par défaut.
 
Comme dit Masklinn, depuis Java1.5, les hashmaps sont des "generics".
Pour moi, c'est porteur de plusieurs sens :
-> Si on compile et fait tourner avec une VM < 1.5, on n'aura pas le même comportement "par défaut" du code.
-> Rien ne nous assure que la prochaine version de Java utilisera toujours des Hashmaps "generics"
-> Si "generic" correspond à ce qu'on appel "object" dans les langages Microsoft (.NET, VB, etc.), alors j'en déduit qu'on peut faire cohabiter dans un même hashmaps deux valeurs de type différents. Ainsi, si une valeur numérique se glisse dedans et qu'on attends un String sans faire de vérification ni cast, alors on ne peut en aucun cas garantir le comportement du programme.
 
En bref, user et abuser des cast (ou appel à des méthodes de cast), ça ne nuit pas plus que ça à la lisibilité, et au contraire, ça facilite le débug puisqu'on est sûr et certains des types utilisés. Deplus, un compilo correct fera abstraction de tous les casts inutiles à la compilation, donc ça ne nuit en rien aux performances.
 
Voilà voilà :)

Reply

Marsh Posté le 04-01-2006 à 23:30:57    

Arjuna a écrit :

Ainsi, quelque soit le type d'objet qu'on utilise, et quelque soit s méthode par défaut, si on veut le mélanger avec une variable de type String, il est pour moins impératif de mettre un ".toString()", ou appel à toute autre méthode qui retourne une chaîne, quand bien même ce serait la méthode par défaut.


Sauf que si tu lisais le code, il utilise .toString sur des objets qui sont déjà des strings [:spamafote]  

Arjuna a écrit :

-> Si on compile et fait tourner avec une VM < 1.5, on n'aura pas le même comportement "par défaut" du code.


Ca c'est sûr, je pense qu'on aura un code qui compile pas [:dawa]

Arjuna a écrit :

-> Rien ne nous assure que la prochaine version de Java utilisera toujours des Hashmaps "generics"


Hum... lol...
 
C'est vrai qu'ils vont sûrement retirer une fitioure dont la non-utilisation produit actuellement des warnings et qu'ils viennent d'ajouter dans le langage [:moule_bite]  

Arjuna a écrit :

-> Si "generic" correspond à ce qu'on appel "object" dans les langages Microsoft (.NET, VB, etc.), alors j'en déduit qu'on peut faire cohabiter dans un même hashmaps deux valeurs de type différents. Ainsi, si une valeur numérique se glisse dedans et qu'on attends un String sans faire de vérification ni cast, alors on ne peut en aucun cas garantir le comportement du programme.


Justement non [:pingouino]
 
Fais moi plaisir:

  • Va te renseigner sur ce que sont les generics en Java (2e lien quand tu google "Java generics" pour une explication simple, ça devrait être faisable non?)
  • Ou vas au moins comparer la déclaration d'une HashMap entre Java 1.4 et Java 1.5


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 04-01-2006 à 23:32:07    

merci Arjuna pour cette très belle sortie de piste, on dirait du Senna, et c'est pas peu dire.

Reply

Marsh Posté le 04-01-2006 à 23:33:46    

Arjuna > je te propose de revenir quand tu sauras exactement à quoi correspond T extends Pouet dans les generics en java.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ça devrait nous laisser peinard pour un moment [:pingouino]

Reply

Marsh Posté le 04-01-2006 à 23:38:15    

Arjuna a écrit :

Perso, après avoir lu les remarques de certains intervenants, j'ai envie de rammener ma fraise.
 
Alors...
 
En gros, y'a quelques années, un langage a été inventé, et son cahier des charge faisait a peut près 3 fois plus de pages que la norme ISO toute entière, soit le plus gros cahiers des charges jamais réalisé à ce jour. Il avait pour objectif premier d'être infaillible, et permettre, à tout instant dans le source, de savoir exactement ce qu'on faisait.
 
Une des solutions apportées pour répondre à cette condition fut le choix d'un langage "très fortement typé". C'est à dire que même si on crééait un type à dérivé partir d'un type standard, il était absolument impossible de faire des oppérations combinant ces deux types, sans au préalable faire un cast ou une surcharge des oppérateurs.
Grace à ça, plus d'autres points importants, à partir du moment où un programme compile, on est sûr à 100% qu'il est implantable.
 
Ce langage, c'est ADA. (pas la version 95, la version première du nom, la 95 a apporté un fort lot d'instabilité, et du coup un programme qui compile peut planter). C'est ce langage qui fait voler Ariane, qui a permis de mettre au point les modèles physique du TGV, ou simplement qui guide un missile nucléaire, l'armé américaine étant le rédacteur du cahier des charges.
 
J'ai appris à développer sur ce langage, et je reste persuadé que ses parties les plus chiantes sont les parties les plus importantes d'un programme. Ainsi, je dénonce les transtypages implicites, et je vote pour les transtypages explicites.
 
Ainsi, quelque soit le type d'objet qu'on utilise, et quelque soit s méthode par défaut, si on veut le mélanger avec une variable de type String, il est pour moins impératif de mettre un ".toString()", ou appel à toute autre méthode qui retourne une chaîne, quand bien même ce serait la méthode par défaut.
 
Comme dit Masklinn, depuis Java1.5, les hashmaps sont des "generics".
Pour moi, c'est porteur de plusieurs sens :
-> Si on compile et fait tourner avec une VM < 1.5, on n'aura pas le même comportement "par défaut" du code.
-> Rien ne nous assure que la prochaine version de Java utilisera toujours des Hashmaps "generics"
-> Si "generic" correspond à ce qu'on appel "object" dans les langages Microsoft (.NET, VB, etc.), alors j'en déduit qu'on peut faire cohabiter dans un même hashmaps deux valeurs de type différents. Ainsi, si une valeur numérique se glisse dedans et qu'on attends un String sans faire de vérification ni cast, alors on ne peut en aucun cas garantir le comportement du programme.
 
En bref, user et abuser des cast (ou appel à des méthodes de cast), ça ne nuit pas plus que ça à la lisibilité, et au contraire, ça facilite le débug puisqu'on est sûr et certains des types utilisés. Deplus, un compilo correct fera abstraction de tous les casts inutiles à la compilation, donc ça ne nuit en rien aux performances.
 
Voilà voilà :)


 [:arrakys]

Reply

Marsh Posté le 04-01-2006 à 23:52:49    

je lis ou pas ?


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 05-01-2006 à 00:01:18    

t'as qu'à pas lire :spamafote:

Reply

Marsh Posté le 05-01-2006 à 00:05:22    


Oui, pour une fois que c'est pas moi que tu vas insulter sur du java je suis intéressé :o


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 05-01-2006 à 00:05:38    

ok, donc, 18 lignes pour dire que c'est bien de mettre toString(), alors que tout le monde serait d'accord là dessus, c'est juste qu'on a rien dit parce que Masklinn, on laisse pisser.
 
et 10 lignes de vent pour nous montrer qu'il ne sait pas ce qu'on entend par "generics", en java.
 
 
Ben finalement, il était vachement interessant, ton machin pour afficher les infos d'un serveur sur le bureau.


Message édité par the real moins moins le 05-01-2006 à 00:08:11

---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 05-01-2006 à 00:25:41    

Hmmmm, ok pour le coup du Generic...
 
Seulement, j'ai beau relire les bouts de code ci-dessus, je ne vois pas un appel à cette fonctionnalité de Java...
Et là, les collections utilisées sont bel et bien multi-types, d'où l'incapacité d'être sûr à tout moment qu'elles ne contiennent que des String...
 
Chuis pas si ç l'ouest que ça finalement...

Reply

Marsh Posté le 05-01-2006 à 00:29:49    

:sleep: Masklinn suggérait à notre ami d'utiliser les generics pour justement mieux typer ses collections et éviter de caster à tout va :sleep:
il pourrait faire
Map<String, Integer> maMap = new HashMap<String, Integer>() quoi.


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 05-01-2006 à 00:35:49    

Citation :


    * Pourquoi ya des toString partout? (accessoirement avec Java1.5 les hashmaps sont des generics, donc tu te débarasse de tous les casts et autres)


Faut savoir qu'il lui suggère d'utiliser les generics... Moi j'interprète pas ça comme ça. :spamafote:
 
M'enfin bon, je retourne dans la cat SGBD, au moins les gens allument pas le premier qui dit une connerie, et si y'a un expert incompris, c'est moi, donc j'ai pas de mal à le comprendre :p

Reply

Marsh Posté le 05-01-2006 à 00:38:54    

merci.


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 05-01-2006 à 20:57:19    

je reviens au sujet.
J'ai refait l'exercice, et ca me donne le code suivant (j'ai edité mes autres messages en effacant les autres codes, de plus je precise que c'est pour analyser un texte en anglais, donc pas d accent).
Par contre je suis bloqué a la derniere question du sujet.
 
4. On désire trier l'index précédent en fonction des occurrences (les plus fréquentes en tête).
a. Donner les stratégies possibles pour constituer une liste triée sur les occurrences.
b. Appliquer cette strategie au code precedent.
c. Ajouter au programme la sortie des mots triés sur leur occurrence inverse.

 
Si vous pouviez m'aider :) merci
 

Code :
  1. import java.util.*;
  2. import java.io.*;
  3. public class DesMots
  4. {
  5.   public static void main(String[] args)
  6.   {
  7.     int j = 0;
  8.     Map dico = new TreeMap();
  9.     try
  10.     {
  11.       BufferedReader in = new BufferedReader(new FileReader(new File(args[0])));
  12.       String line;
  13.       while ((line = in.readLine()) != null)
  14.       {
  15.         String[] tokens = line.split("\\b", -1);
  16.         int i = 0;
  17.         while (tokens.length > i)
  18.         {
  19.           String word = tokens[i++];
  20.           word = word.toLowerCase();
  21.           word = word.replaceAll("[^a-z]", "" );
  22.           if (word.length() > 2)
  23.           {
  24.             if (dico.containsKey(word))
  25.             {
  26.               String count = (String) dico.get(word);
  27.               int icount = Integer.parseInt(count);
  28.               dico.remove(word);
  29.               dico.put(word, Integer.toString(++icount));
  30.             }
  31.             else
  32.               dico.put(word, Integer.toString(1));
  33.           }
  34.         }
  35.       }
  36.     }
  37.     catch (Exception e)
  38.     {
  39.       System.out.println("Exception :" + e);
  40.     }
  41.     // Affichage des résultas
  42.     Set dicoSet = dico.keySet();
  43.     Iterator i = dicoSet.iterator();
  44.     System.out.println(
  45.       args[0] + " contient " + dico.size() + " mots différents" );
  46.     System.out.println("---Mots---------------Nombres" );
  47.     while (i.hasNext())
  48.     {
  49.       String key = (String) i.next();
  50.       String skey = key;
  51.       for (int k=key.length(); k < 24; k++)
  52.        skey = skey + '.';
  53.       System.out.println(skey + (String) dico.get(key));
  54.     }
  55.   }
  56. }


 
edit : la partie pour gerer la Map a eté corrigée par mon prof d'info ce matin.


Message édité par Pookie le 05-01-2006 à 21:21:43
Reply

Marsh Posté le 05-01-2006 à 21:58:13    

Mais pourquoi tu stockes tes comptages sous la forme de strings nom de dieu [:mlc]
 
Quel intérêt ça a, à part rajouter des opérations inutiles [:petrus dei]
 
Et je t'ais déjà dit que tes dico.remove ne servent à rien, un put sur une clé déjà existante met la valeur de celle ci à jour
 
Et accessoirement, utilise donc l'objet mutable de nraynaud, ça diminue encore le nombre d'opérations nécessaires, donc ça clarifie le code.


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 05-01-2006 à 22:02:40    

masklinn a écrit :

Et accessoirement, utilise donc l'objet mutable de nraynaud, ça diminue encore le nombre d'opérations nécessaires, donc ça clarifie le code.


une chose à la fois.


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 05-01-2006 à 22:18:07    

bah c'est le code de mon prof grand gourou, donc je le prends comme un code bon, bien fait.
Mais je lui ferais la remarque :) juste histoire de voir ca reaction

Reply

Marsh Posté le 05-01-2006 à 22:49:43    

Une autre question, aussi:
 
Pourquoi ne pas faire ton toLowerCase() et ton filtrage de caractère directement sur la ligne complète (avant de la splitter)?
 
Ca génèrerait beaucoup moins d'objets.


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed