Ich musste auf jeden Fall in die Methode schauen, um zu wissen, was diese tut. Nur weil etwas privat ist, heißt dass ja nicht, dass die Methode irgendwie heißen sollte.
Ganz abgesehen davon, erhält diese Methode einen Übergabeparameter, den sie verändert und zurückgibt. Auch wenn die Veränderung nur Kontext bezogen passiert, ist dies kein guter Ansatz.
Weiter ist der Inhalt der Methode auch eher schwierig. Warum kommt Math.abs(x - list[i]) <= delta zweimal darin vor? Was bedeutet dieser Ausdruck überhaupt? Das „könnte“ auch in eine Methode extrahiert werden.
Zudem finde ich Rückgabewerte von -1 nicht ganz sprechend. Ich würde hier im Java-Umfeld mit einem Optional arbeiten.
Ich finde den Vorschlag von @Marco13 ganz sprechend.
Ich würde hier im Java-Umfeld mit einem Optional arbeiten.
Ich eher nicht. Gerade weil es „Konventionen“ gibt. Die kann man gut oder schlecht finden, aber von List#indexOf (oder auch Arrays#binarySearch, auch wenn es da nicht -1 ist) abzuweichen, sollte gut begründet sein.
Du zeigst doch gerade, dass sich beide Methoden im Rückgabewert unterschiedlich verhalten. Das muss keine „Konvention“ sein. Optional gab es zur Zeit der Implementierung noch nicht. Und Java ist bekannt dafür bei neuen Releases keine Codebrüche verursachen zu wollen. Das spricht dennoch nicht für einen guten Stil. Optional wäre in diesem Sinne sprechend. Jede(r) würde direkt an der Signatur erkennen, dass es sein kann, dass es keinen Rückgabewert gibt. Genau das ist der Sinn bei Optional. Das wäre für mich Grund genug.
Ein wichtiger Unterschied ist, ob Optional geeignet ist, um einen Sonderfall auszudrücken. Wenn man heute „auf der grünen Wiese“ die map.get(key)-Methode designen müßte, wäre Optional sinnvoll, um zu unterscheiden, ob unter den key nun wirklich nichts gespeichert ist, sondern der Wert null (das ist im Moment zweideutig, und muss mit containsKey explizit gecheckt werden, wenn es relevant ist). Aber bei indexOf oder Indizies allgemein ist eine -1 (oder eine negative Zahl) „üblich“. Man könnte nun mit dem „Overhead“ argumentieren, ein Optional-Objekt mit einem Integer-Objekt zu erzeugen, aber wichtiger finde ich, dass die Semantik in diesem Fall eindeutig ist.
Dafür hat Map die map.computeIfPresent(key, value->{}) und map.computeIfAbsent(key, key->{}) Methoden nachträglich spendiert bekommen. So gesehen hätten sie auch ein map.getOptional(key) einführen können. Nur würde das den Funktionsraum der derzeitigen Umsetzung nicht abdecken.
So gesehen hätten sie auch ein list.getOptional(key) oder list.computeIfPresent(index, value->{}) nachträglich einführen können. Aber was weiss ich schon
Hach. Es gibt nichts schöneres als ein map.computeIfAbsent(key, Value::new)
Das spart so viel Ärger
Ich denke, dass ist einfach dem Alter der API geschuldet. Ich wüsste nicht, warum es sinnvoll ist, hier an einer Konvention festzuhalten, wenn die Sprache es einem erlaubt, genau dies in der Methodensignatur zu dokumentieren.
Wird es jetzt politisch? Wenn ich etwas Neues einsetzen soll, dass komplizierter und langsamer ist, dann muss es dafür einen Grund geben. Ein Grund wäre, dass das Neue „besser“ wäre. Wenn etwas besser ist, dann muss es einen „Mehrwert“ haben. Und den sehe ich hier nicht.
Oder anders: Hier geht es nur um das Suchen des Index eines Elements. Um das Einfügen und das .computeIfAbsent( ) geht es nicht. Ein Array ist in dem Sinne keine vollwertige DS, d. h., es kann gar nicht >einfach sinnvoll< eingefügt werden.
Danke, dass Du anderen in den Rücken fällst, sobald diese nicht mehr schreiben dürfen.
Das hat nichts mit politisch zu tun. Jedenfalls verstehe ich hier den Zusammenhang nicht.
Optional ist nicht komplizierter, sondern seit 1.8 ein fester Bestandteil der API. Im Gegenteil, es schafft genau dort Klärung, wo nicht klar ist, ob ein Rückgabe-Wert Null sein darf oder kann.
Ob es langsamer ist, kann ich nicht beurteilen. Der Compiler optimiert eine Menge. Dafür nutzt man dann entsprechende Tools, um Performance-Probleme zu finden und beurteilen zu können.
Dass Du den Mehrwert leider nicht siehst, ist schade. Ich empfehle, dass Du Dich mehr mit sauberen und sprechenden Code auseinander setzt. Dass Du guten und schlechten Code wirklich unterscheiden kannst, würde ich Dir anhand Deiner Beispiele hier im Forum absprechen. Und das ist total unemotional und auch nicht böse gemeint. Auf jeden Fall wird Dir hier häufig gespiegelt, dass Dein Code in der Regeln schwer verständlich ist - das ist zumindest meine Wahrnehmung.
Ja, aber nicht jeder in die Länge gezogene Bezeichner ist gut. Und mir zuzusprechen, Code nicht beurteilen zu können, steht dir nicht zu, ganz egal, wie lange du eine Tätigkeit bereits durchführst. In einem anderen Forum hab ich schon erlebt, dass Leute einfach nur 10 Jahre auf einen Schreibtischstuhl saßen und dann meinten, andere abwerten zu können.
Ich beziehe mich auch nicht darauf, wie lange ich so etwas mache. Das hat auch nichts mit abwerten zu tun. Du bekommst hier im Forum von vielen Seiten negative Kritik zu Deinen Code-Beispielen hier. Ich kann mich auch nicht wirklich an ein gutes Stück Code von Dir erinnern - aber das ist mir vielleicht auch einfach untergegangen.
Im übrigen darf jede Person der Meinung sein, dass Du schönen Code nicht von schlechtem unterscheiden kannst. Die Frage ist, was Du daraus machst. Du kannst die Kritik annehmen, aber musst es nicht.
Und ja, ich glaube, Du bist nicht in der Lage guten und schlechten Code zu unterscheiden.
@Landei Ich sage nicht, dass ich alles besser wüsse. Aber bei dem Review auf SO von Pavlo Slavynskyy, dass dankenswerterweise noch da ist, ist es so, dass ich 3 der 8 angegebenen Kritikpunkte als „nicht so gravierend“ oder „nicht schwerwiegend“ empfinde. Jetzt kann man sich natürlich lange darüber streiten, ob etwas inwieweit „gerechtfertigt“ ist - aber eigentlich ist dieses Thema doch schon „gegessen“…!
Ich weiß, es ist Perlen vor die Säue, aber einer meiner Lieblings-Koans ist dieser:
Nan-in empfing einen Universitätsprofessor, der kam, um sich über Zen zu erkundigen. Nan-in servierte Tee. Er goss die Tasse seines Besuchers voll, und hörte nicht auf.
Der Professor beobachtete das Überlaufen, bis er sich nicht mehr zurückhalten konnte. „Die Tasse ist übervoll. Es geht nichts mehr hinein!“
„Wie diese Tasse“, sagte Nan-in, „bist du voll von deinen eigenen Meinungen und Spekulationen. Wie kann ich dir Zen zeigen, wenn du nicht zuerst deine Tasse leerst?“
Es geht nicht darum, wie gerechtfertigt nun jeder einzelne Kritikpunkt ist. Das Problem bei dir ist, dass du automatisch in Verteidigungsstellung gehst und versuchst, die Kritik zu entkräften. Und das, bevor du überhaupt ernsthaft in Erwägung gezogen hast, dass der andere recht haben könnte. Du bist nicht wirklich offen für Kritik, deine Tasse ist bereits voll von dem, was du selbst über guten Code zu wissen meinst - völlig egal wieviele Leute dir etwas anderes erzählen.
Und ich bin der Universitätsprofessor, der seine Teetasse nicht austrinkt? Da gibt es nur zwei Haken an der Sache, ich habe weder promoviert noch habilitiert, noch trinke ich überwiegend Tee.
Naja, was nicht ist, kann ja noch kommen (wehe, jetzt postet jemand ein unpassendes Gif ).
