Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Note: meintool.java:207:32: Declaring variables, return values or parameters of type 'ArrayList' is not allowed.
Diese besagt, dass ich anscheinend keine ArrayList als Parameter übergeben darf. Und auch nicht als Return eine solche zurückgeben darf.
Warum gibts es diese Einschränkung?
Kann mir einer sagen was ich den böses getan habe?
Noch zur kleinen Hilfe...für die Analysten.
Ich habe eine Methode geschrieben, die es mir erlaubt ein ArrayList zu übergeben, diese ArrayList wird dann in der Methode sortiert und danach als Array vom Typ int ( also return int[]) wieder zurück gegeben. Es funktioniert wie ich es mir gedacht habe, aber es kommt der oben genannte fehler.
Wäre toll wenn mir jemand Zeitnah weiterhelfen könnte. Jeder Post hilft vielleicht weiter. Danke
List statt ArrayList, das findet man überall,
ich kopiere mal wahllos aus einem google-Link
List ist ein Interface, dass von verschiedenen Klassen implementiert wird. Dadruch, dass als Rückgabetyp List genommen wird, weiß derjenige, der die Funktion aufruft, dass er halt irgendeinen solchen Typ bekommt. Welchen genau, ist unbekannt. Aber das Interface List definiert einige Zugriffsmethoden, die jede dieser Implementationen garantiert hat. Intern verwendet die Klasse ShoppingCart nun eine beliebige dieser Implementationen, im Beispiel halt ArrayList. Ergibt sich nun die Situation, dass die Klasse erweitert werden soll, und dabei stellt sich heraus, dass z.B. Vector besser geeignet wäre, so kann man dass innerhalb dieser Klasse einfach ändern, ohne dass sich außerhalb der Klasse was ändert.
Ok ich glaub ich hab es verstanden. Da durch, dass ja ArrayList und LinkedList von List erben, kann ich alle damit verwenden. Bin also viel flexibler. Was wäre aber jetzt wenn ich den Aufruf wirklich nur auf den Typ ArrayList limitieren möchte. Falls es mal der Fall wäre. Oder bei einer LinkedList etwas anderes passieren soll, als bei meiner ArrayList?
es ist durchaus denkbar, wirklich nur ArrayList zu schreiben,
keine Ahnung ob Check-wasauchimmer da genau prüft, ob nur Methoden des Interfaces verwendet werden,
und selbst dann kann es im Extremfall Sinn machen, die Liste näher zu bestimmen, z.B. wegen Performance,
dann muss man wohl mit der Warnung leben und standhaft bleiben
Man kann das natürlich machen, allerdings gibt es nur weniges, was bei einer ArrayList angeboten wird, was nicht schon bei jeder anderen List geht.
Die Frage, was man machen sollte, wenn "bei LinkedList etwas anderes passieren sollte, als bei ArrayList" ist mehr als berechtigt. Bei einer LinkedList hat der indizierte Zugriff O(n) während er bei einer ArrayList mit O(1) passiert. Wenn man z.B. einen eigenen Sortieralgorithmus für eine List implementiert, und da überall mit [c]list.get(index)[/c] auf der Liste rumhantiert wird, ist das gääähnend langsam. Im konkreten Fall von Collections.sort wird das umgangen: Dort wird die Liste in einen Array gepackt, DER dann sortiert, und am Ende der sortiere Array in die Liste zurückgeschrieben.
Im Allgemeinen braucht man aber noch nicht mal die Information, ob es denn wirklich eine ArrayList ist. Wenn man stattdessen einen Vector oder eine CopyOnWriteArrayList hat, dann ist das ggf. schon KEINE ArrayList mehr. Für die Fälle, wo die Unterscheidung, ob man auf die Elemente schnell indiziert zugreifen kann, gibt es das Interface RandomAccess (Java Platform SE 6) das von ArrayList implementiert wird. Man KÖNNTE dann also sowas machen wie
oder so. (Ich finde das mit dem Tagging-Interface eigentlich nicht so hübsch, aber ... naja :bahnhof: )
EDIT: Ach ja noch als Nachtrag: Solche Sachen wie CheckStyle, PMD und FindBugs sind zwar nett und praktisch, und man sollte sowas ab und zu mal über seinen Code laufen lassen, aber sie ersetzen nicht das, wofür man als Softwareentwickler das ganze Geld kriegt
EDIT: Ach ja noch als Nachtrag: Solche Sachen wie CheckStyle, PMD und FindBugs sind zwar nett und praktisch, und man sollte sowas ab und zu mal über seinen Code laufen lassen, aber sie ersetzen nicht das, wofür man als Softwareentwickler das ganze Geld kriegt
nette verhamlosung... imo sollten die 3 (oder teile) definitiv Teil des continous builds sein bzw auch schon waehrend der Entwicklung in der IDE anschlagen. Alles andere waere blauaeug.
Proklamiere: wenn man es nicht einsetzt und beachtet sollte man weniger Geld bekommen !
Btt:
wenn du unbedingt eine ArrayList brauchst (warum auch immer), dann eher
Java:
public void foo(List<String> bar) {
List l = new ArrayList<String>(bar);
...
}
"...kon-tin-ju-us bild-s ..." ? ???:L Ach so, das was theoretisch dafür sorgen könnte, dass Programme besser funktionieren und weniger Fehler entstehen Aber mal im Ernst: Viele der Dinge, die von diesen Programmen angekreidet werden, macht man (spätestens, wenn man ein, zwei mal darauf hingewiesen wurde) "automatisch" richtig. Wenn man Dinge macht, die man noch nie vorher gemacht hat, und für Fehler, die eher in die Kategorie "Tippfehler" oder "Flüchtigkeitsfehler" fallen, sind solche Sachen ja OK. Aber auch eher theoretisch, wenn das ganze Team sie konsequent einsetzt. Gibt's sowas? ???:L ... Hier ist ein Programm mit ca. 100000 Zeilen Code und 4-8 ständig wechselnden Entwicklern - und der einzige, der FindBugs und PMD installiert hat, bin ich. Wenn ich das jetzt da drüberlaufen lasse, bekomme ich locker mehrere tausend Warnungen, mit teilweise SEHR hoher Priorität und SEHR hoher Berechtigung - eben einfach Stellen, die FALSCH sind. Aber was soll ich jetzt machen? Dem Chef sagen: Joa, die nächsten 6 Monate machen wir NICHTS - außer Bugfixing? Das funktioniert halt nicht.... :bahnhof:
Eigentlich bezog sich meine Aussage aber ohnehin eher darauf, dass solche Programme eben manchmal "Fehler"/"Warnungen" raushauen, bei denen man als Mensch eben erkennt: "Ja, das ist vielleicht ungewöhnlich, aber in diesem speziellen Fall ist es genau richtig so".
Ich hoffe das erschüttert jetzt niemanden: Meine Meinung: Nur weil Checkstyle, findbugs oder eine warning sagt das irgendwo etwas nicht passt, heißt das nicht das ich jetzt mit aller gewalt meinen Code ändern muss. Diese Tools sind eine gute Hilfestellung und man tut gut daran sich daran zu halten, aber es gibt Fälle da liegen sie einfach falsch. Also nicht jeder Meldung blind vertrauen
Ich hoffe das erschüttert jetzt niemanden: Meine Meinung: Nur weil Checkstyle, findbugs oder eine warning sagt das irgendwo etwas nicht passt, heißt das nicht das ich jetzt mit aller gewalt meinen Code ändern muss. Diese Tools sind eine gute Hilfestellung und man tut gut daran sich daran zu halten, aber es gibt Fälle da liegen sie einfach falsch. Also nicht jeder Meldung blind vertrauen
ich sprech in keiner weise von blind vertrauen. QS sollte aber eine enorm hohen Stellenwert im Code haben und dafuer helfen diese Tools einfach. Man muss sich mit punkten beschaeftigen und kann entscheiden ob das nun wirklich problematisch sein koennte oder nicht. Aber du argumentierst ja auch nicht dass sie komplett unnuetz sind.
macht man (spätestens, wenn man ein, zwei mal darauf hingewiesen wurde) "automatisch" richtig
natuerlich - sollte auch in einer richtigen produktiven Umgebung. Wenn nicht versagen meiner Ansicht nach Teamleiter bzw Verantwortlicher.
bzw nach dem Prinzip - Tests... klappt theoretisch wenn alles einsetzen - gibts das ? naja egal.
bekomme ich locker mehrere tausend Warnungen, mit teilweise SEHR hoher Priorität und SEHR hoher Berechtigung - eben einfach Stellen, die FALSCH sind. Aber was soll ich jetzt machen? Dem Chef sagen: Joa, die nächsten 6 Monate machen wir NICHTS - außer Bugfixing? Das funktioniert halt nicht....
ah... verzeih mir, aber die bescheu*** argumentation bzgl solcher Tools.
"Sorry chef, ich habe hier ziemlich schlechten, fehleranfaelligen code. Das wird uns bei den Bugreports vom Kunden spaeter um die Ohren hauen, aber jetzt haben wir ja keine Zeit dafuer..."
Ebenso vermute ich mal du bist ein guter Programmierer, daher sollten a) die Warnungen schon gering sein und b) sie schnell loesbar.
Ich finde es wesentlich erschreckender bewusst schlechten Code als release zu nutzen nur weil man in der Zeitplanung nicht beachtet hat sein Code in gutem Zustand zu haben (sch*** auf quali... raus damit).
Codingstandards - egal... jeder macht was er will. Bugs werden danach schon behoben.
Man glaubt nicht wieoft solche Faelle auftauchen
Java:
void foo() {
String someValue = someCondition ? null : "";
// zig zeilen code
bar(someValue);
// wieder code
}
void bar(String value) {
// viel viel code
if (value.charAt(0) == '1') {
...
}
}
die NPE hier zu erkennen ist nicht trivial fuer das den Code auswendig kennende Entwicklerauge
aehnlich
Java:
public void foo(String value, boolean flag) {
if (value == null && flag) {
return;
}
value.substring(1);
}
oder gern auch genommen
Java:
public Boolean isSet() {
return null;
}
Ich behaupte niemals dass man sein ganzes Wissen und Vertrauen in diese Tools stecken sollte. Sie dienen als Hilfswerkzeuge um seine getane Arbeit zu bewerten. Lernt man aus sowas - perfekt.
Ich weiss dass es in unzaehligen Teams / Firmen nicht praktiziert wird (Metriken / Tests), dennoch ist es einfach falsch es nicht zu tun - Software ist eben mehr als der Prozess der Entwicklung.
bygones = alte diskussion... wer das nicht nutzt bzw den sinn nicht sieht ist in meinen Augen kein guter Programmierer.
Ich habe nicht andeuten wollen, dass das schlecht ist - eher im Gegenteil. Je öfter man es einsetzt, um so seltener "müßte" man es einsetzen, weil man von vornherein bestimmte Fehler vermeidet, und weiß, worauf man achten sollte.
ah... verzeih mir, aber die bescheu*** argumentation bzgl solcher Tools.
"Sorry chef, ich habe hier ziemlich schlechten, fehleranfaelligen code. Das wird uns bei den Bugreports vom Kunden spaeter um die Ohren hauen, aber jetzt haben wir ja keine Zeit dafuer..."
...
sch*** auf quali... raus damit.
Codingstandards - egal... jeder macht was er will. Bugs werden danach schon behoben.
Ich stimme dir da vollkommen zu. Und ich sage das auch immer wieder. Aber meine Hinweise werden ignoriert. Und ... sie werden nicht einfach nur ignoriert, es wird auf sie GEKOTZT. Inzwischen habe ich es aufgegeben. Wenn man 2 Wochen braucht, um einen Bug zu fixen, der durch 2 Minuten Style-Checking hätte vermieden werden können, dann kostet das viel Zeit und viel Geld, aber es ist eben so. Zufrieden bin ich damit nicht, aber ich kann daran nichts ändern. Ich bin nur ein kleines Rädchen, das zwar manchmal (mit den Zähnen) knirscht und meckert, aber mehr kann ich eben nicht tun... Entscheidungen treffen andere.
Man glaubt nicht wieoft solche Faelle auftauchen
...
bestehen (und das ist kein übertriebenes Plakativbeispiel - leider darf ich den Code hier nicht posten, aber die Antwortenden würden die Foreninterne Beschränkung der Anzahl der :autsch:-Smileys kennenlernen) dann fühlt man sich, wie wenn man einen runden (Mühl-)Stein einen Berg raufrollt, auf dem eine Windmühle steht, gegen die man dann kämpfen muss.
EDIT: Ach ja noch als Nachtrag: Solche Sachen wie CheckStyle, PMD und FindBugs sind zwar nett und praktisch, und man sollte sowas ab und zu mal über seinen Code laufen lassen, aber sie ersetzen nicht das, wofür man als Softwareentwickler das ganze Geld kriegt
Danke für den Tipp mit PMD und FindBugs. Wir in der Uni müssen CheckStyle zwingend über das Programm laufen lassen. Finde es manchmal ein wenig zu überladen, was mir alles gemeckert wird. Aber FindBugs und PMD kannte ich noch nicht, sehen aber sehr nützlich aus. Danke!
Ich find's lustig, dass Checkstyles in der Standardkonfiguration Einrückung mit Tabs anmeckert Ohne Tabs würde ich sterben. So habe ich über 3k Meldungen *hehe*
Ich find's lustig, dass Checkstyles in der Standardkonfiguration Einrückung mit Tabs anmeckert Ohne Tabs würde ich sterben. So habe ich über 3k Meldungen *hehe*
kleiner tipp. stelle um, dass tabs in leerzeichen umgewandelt werden, damit hast du dann 3k fehlermeldungen weniger welches betriebsystem hast du den, dann kann ich dir den punkt im einstellungsmenu sagen.
Nein ich will es ja gerade nicht umstellen. Ich mag Tabs, weil sie jeder von der Breite einstellen kann wie er es mag. Z.B. haben wir jemanden in der Firma der liebt es nur 2 Leerzeichen-Breite zum Einrücken zu nutzen, ich liebe meine 4er Einrückung
Daher Tabs > Spaces
Das man die automatisch umstellen kann weiß ich, immerhin hab ich ja bei jedem Speichern den CodeFormatter laufen
Checkstyle fand ich auch immer extrem unnütz. Es ist allerdings schon einige Zeit her, dass ich es mir zuletzt angesehen habe. Vielleicht kann es jetzt ja mehr.
Findbugs hingegen ist Gold wert. Leider ist der Ressourcenbedarf so hoch, dass man es nicht ständig in der IDE laufen lassen kann. CI müsste man haben...
Früher haben wir auch CruiseControl genutzt, zum Erzeugen von NightlyBuilds. Eine Continous Integration im eigentlichen Sinne (also auch auf die Commits der einzelnen Entwickler bezogen), war damit nicht möglich. Den Konfigurationsaufwand fand ich auch ziemlich hoch.
Bamboo und Hudson sagen mir nichts. Werde ich mir mal ansehen. Vielleicht ist ja mal ein wenig Budget für sinnvolle Sachen übrig...
Man kann CC auch nach jedem Commit bauen, man muss dafür aber einen commit hook im SCM (SVN,etc.) einrichten, welcher dann den Build im CC triggert.
Bei Hudson kann man regelmässig pollen lassen und bei einer neuen revision baut er, man braucht keinen hook im SCM.
Bamboo macht entweder Polling um neue Commits zu finden oder kann in Verbindung mit Fisheye aktiviert werden oder alternativ wie maki schon sagte per post-commit-hook.
