Status:
Ich habe eine Lise von 0-n Elementen. (1.3.5.45.342.77854.0.1.1.443.5, 1.23.22343.522,44232.2342...) bei denen ich wissen will, ob und wie oft diese in einem Textfile in Kombination mit dem String "Namen" vorkommen.
Problem:
die zweite Suche mit dem line.contains greift mir leider nicht bzw. kann es auch sein, dass wenn die Suche nach dem ersten Listenelement fertig ist, die Iteration auf das zweite Element gar nicht mehr durchgeführt wird.
Anbei der Code:
Java:
FileReader freader =newFileReader(file);BufferedReader reader =newBufferedReader(freader);int counter =0;for(int i =0; i < list.size(); i++){while(reader.readLine()!=null){
line = reader.readLine();if(line.contains("Name")){System.out.println("Listenelement: "+list.get(i));if(line.contains(list.get(i))){
counter++;System.out.println(counter +list.get(i)+" found");}}}}
freader.close();
FileReader freader =newFileReader(file);BufferedReader reader =newBufferedReader(freader);int counter =0;for(int i =0; i < list.size(); i++){while(line = reader.readLine()!=null){if(line.contains("Name")){//*System.out.println("Listenelement: "+list.get(i));if(line.contains(list.get(i))) counter++;}}}System.out.println(counter +" Elemente geunden.");
freader.close();
Wenn du irgendwas mit "max" haben willt, dann musst du erstmal definieren, was für dich "größer" bedeutet. Wer größer als was? Wie vergleichst du? ...
Davon ist im Programm nichts zu erkennen.
Bisher zählst du nur!
Etwas OT, aber ich finde diese [c]while (line = reader.readLine() != null)[/c]-Idiom einfach grauenhaft. Warum nicht [c]for(String line= reader.readLine(); line != null; line = reader.readLine())[/c]?
Etwas OT, aber ich finde diese [c]while (line = reader.readLine() != null)[/c]-Idiom einfach grauenhaft. Warum nicht [c]for(String line= reader.readLine(); line != null; line = reader.readLine())[/c]?
Sieht meiner Mainung nach viel schrecklicher aus, und beinhaltet den eigentlichen readLine-Vorgang wieder 2 x, was wesentlich schlechter zu lesen und schlechter zu warten ist.
(Kürzer ist es auch nicht. Schneller soundso nicht.)
Zum einen finde ich die klare "Aufgabenteilung" besser (Initialisierung, Schleifen-Test, Schleifen-Schritt), zum anderen wird der Scope von line auf die Schleife beschränkt (es kann also niemand hinter der Schleife auf die Idee kommen, mit line - das ja nun null ist - irgendetwas dummes zu machen).
Dass das so "lang" ist, liegt auch an der verkrüppelten API. Warum nicht [c]BufferedReader implements Iterable<String>[/c]? Dann könnte man [c]for(String line : reader)[/c] schreiben.
Stimmt! Gute Idee!
(Hab ich auch wieder was dazugelernt)
Langsam wird's richtig elegant:
Java:
for(String element : list){BufferedReader reader =newBufferedReaderimplementsIterable<String>(newFileReader(file));int counter =0;for(String line : reader)if(line.contains("Name")&& line.contains(element))
counter++;System.out.println("'"+ element +"' found "+counter +" times.");}
Wobei
Code:
BufferedReader reader = new BufferedReader implements Iterable<String>(new FileReader(file));
ungeprüft ist (damit arbeite ich nie), vielleicht gehts noch besser.
[TIPP]Eine generelle Anmerkung: Ist es wirklich schlau, die Datei n-Mal zu lesen? Wäre es nicht sinniger, die Schleife über die Liste nach innen zu packen?[/TIPP]
[TIPP]Eine generelle Anmerkung: Ist es wirklich schlau, die Datei n-Mal zu lesen? Wäre es nicht sinniger, die Schleife über die Liste nach innen zu packen?[/TIPP]
1) Bei 10.000 Zeilen wirst du bald mal an die Speichergrenze kommen. (Je nach Laufumgebung.)
Für diesen Zweck sind externe Speicher erfunden worden.
2) Beim Umpacken der Schleifen wirst du dein blaues Wunder mit Counter erleben!
Weil dann nicht mehr rauskommt, wieviele Zeilen den aktuellen Suchstring enthalten,
sondern wieviele Suchstrings in der aktuellen Zeile vorkommen!
Die Moral von der Geschicht':
Schleifen tauschen tut man nicht!
Das tust du ja bereits!
Deine Datei liegt ja auf "externem Speicher" (= Festplatte, ...)
Ich wollte damit nur sagen, dass die gesamte Datei leicht größer sein kann, als du überhaupt einlesen kannst.