Variablen Variable Erzeugen oder nicht?

[Gossi]

Schönen guten Tag,

Ich habe hier mal eine Frage.

Bei meinem Programm schreibe ich normalerweise sowas:

String sql = "select * from something";
SimpleJdbcTemplate  temp = getSimpleJdbcTemplate(); //Kommt aus Spring ^^
List<String> stringList =  temp.query(sql, new StringMapper());

Nun ist meine Frage, wäre es nicht performanter das ganze so zu schreiben, falls nein, bitte auch ne kleine erklärung warum es nicht besser wäre (mal ohne das Guideline gdöns ):

String sql = "select * from something";
List<String> stringList =  getSimpleJdbcTemplate().query(sql, new StringMapper());

 

[Gast2]

imho ist die 1. Variante weniger elegant, da du eine temporäre Variable nur zur einmaligen Verwendung anlegst.

Ich würde daher immer Varinate 2 bevorzugen falls im Code Block keine erneute Verwendung vorkommt.

temp würde ich die Vairable allerdings nicht nennen.

 

[darekkay]

Das habe ich früher auch immer gedacht. Aber der zusätzliche Speicher kann bei den heutigen Rechnern fast immer vernachlässigt werden. Und schließlich entfernt der GC am Ende der Methode alle Objekte, die nicht mehr benötigt werden - der Speicher wird also ohnehin wieder freigegeben.

imho ist die 1. Variante weniger elegant, da du eine temporäre Variable nur zur einmaligen Verwendung anlegst.

Ich würde daher immer Varinate 2 bevorzugen falls im Code Block keine erneute Verwendung vorkommt.

temp würde ich die Vairable allerdings nicht nennen.

Ganz im Gegenteil. "Eleganter", spricht "lesbarer", ist auf jeden Fall die 1. Variante. Sehr schnell können Monsteranweisungen entstehen, wenn man das Ganze auch durchzieht. Von Eleganz keine Spur mehr.

 

[tfa]

Theoretisch ist Variante 2 performanter. Du könntest noch die sql-String-Variable sparen und alles in eine Zeile schreiben. Ist vielleicht noch performanter, dafür aber auch noch unlesbarer.

Hast du denn Performance-Probleme? Wie viele Millionen mal pro Sekunde soll dieser Code denn ausgeführt werden?

 

[Gossi]

imho ist die 1. Variante weniger elegant, da du eine temporäre Variable nur zur einmaligen Verwendung anlegst.

Ich würde daher immer Varinate 2 bevorzugen falls im Code Block keine erneute Verwendung vorkommt.

temp würde ich die Vairable allerdings nicht nennen.

temp war hier auch nur als Beispiel aufgelistet, aber danke für die schnelle Antwort.

PS: Habs mir aber auch schon gedacht, da ich durch sowas ja eigentlich den Speicher weniger "belaste" und Zeit gewinnen könnte ^^

PPS:

Ganz im Gegenteil. "Eleganter", spricht "lesbarer", ist auf jeden Fall die 1. Variante. Sehr schnell können Monsteranweisungen entstehen, wenn man das Ganze auch durchzieht. Von Eleganz keine Spur mehr.

Das ist wohl richtig ^^

Theoretisch ist Variante 2 performanter. Du könntest noch die sql-String-Variable sparen und alles in eine Zeile schreiben. Ist vielleicht noch performanter, dafür aber auch noch unlesbarer.


[edit]Da hast du wohl recht, der sql String wird aber auch per Methode gefüllt, da würde das dan so aussehen:

List<String> stringList = getSimpleJdbcTemplate().query(getSqlStatement("GET_STRINGS"), new StringMapper());

[/edit]

Hast du denn Performance-Probleme? Wie viele Millionen mal pro Sekunde soll dieser Code denn ausgeführt werden?

Nicht oft, aber versuche grad meinen Code aufzubessern und da is mir des ins Auge gefallen, da die ganze Anwendung mittlerweile nen bisschen größer geworden ist.

 

[tfa]

Habs mir aber auch schon gedacht, da ich durch sowas ja eigentlich den Speicher weniger "belaste" und Zeit gewinnen könnte

Das belastet weder den Speicher, noch gewinnt man dadurch messbar Zeit. Du verschlechterst höhenst deine Fehlersuch- und Codeverständnis-Performance.

 

[hdi]

@Gossi

Du hast jetzt wohl nur die erste Antwort gelesen, die (@kapessf: no offense) eigentlich die schlechteste war Vergiss das mal mit der Performanz. Das macht einen so geringen Unterschied dass du es nicht mal messen kannst. In diesem konkreten Bsp ist es wohl echt egal welche Variante, aber grundsätzlich gilt: Lesbarkeit > Performance! Also bevor du alles in eine fette Zeile quetscht, leg dir diese lokalen Variablen an. Keine Angst, dann Programm wird ganz bestimmt nicht langsamer laufen.

 

[Gossi]

@Gossi

Du hast jetzt wohl nur die erste Antwort gelesen, die (@kapessf: no offense) eigentlich die schlechteste war
Jepp ^^

Vergiss das mal mit der Performanz. Das macht einen so geringen Unterschied dass du es nicht mal messen kannst. In diesem konkreten Bsp ist es wohl echt egal welche Variante, aber grundsätzlich gilt: Lesbarkeit > Performance! Also bevor du alles in eine fette Zeile quetscht, leg dir diese lokalen Variablen an. Keine Angst, dann Programm wird ganz bestimmt nicht langsamer laufen.

Jo, bin ja auch oben schon drauf eingegangen (siehe PPS vom letzten Post).
Aber Lesbarkeit > Performance sehe ich eh so, war deswegen auch nur eine Frage :toll:

 

[maki]

Schönen guten Tag,

Ich habe hier mal eine Frage.

Bei meinem Programm schreibe ich normalerweise sowas:

String sql = "select * from something";
SimpleJdbcTemplate  temp = getSimpleJdbcTemplate(); //Kommt aus Spring ^^
List<String> stringList =  temp.query(sql, new StringMapper());

Nun ist meine Frage, wäre es nicht performanter das ganze so zu schreiben, falls nein, bitte auch ne kleine erklärung warum es nicht besser wäre (mal ohne das Guideline gdöns ):

String sql = "select * from something";
List<String> stringList =  getSimpleJdbcTemplate().query(sql, new StringMapper());

Das ist keine frage der Performance, sondern der Lesbarkeit.

Auch wenn es auf den ersten Blick anders erscheint, helfen temporäre Variablen nicht(!) die Lesbarkeit zu erhöhen sondern bewirken das Gegenteil, vorrausgesetzt man würde stattdessen Methoden nutzen.

Da hier eine Methode (getSimpleJdbcTemplate()) verwendet würde, macht die temp Variable den Code weniger gut lesbar (1 zusätzliche Zeile, eine zus. Variable).

 

[Gossi]

Also liegt es auch hier wieder zum Teil an der eigenen Vorliebe/Einstellung, is ja häufiger so, habs mal gemessen, in 100 Versuchen war Variante 2 nur einmal 1ms besser, sonst waren beide gleich, aber die Lesbarkeit ist, finde ich, in Variante 2 besser, die Klasse ist so schon mehr als groß genug -.-

 

[maki]

Nur um das Klarzustellen: Es gibt ekinen Performaceunterschied, der Compiler bzw. zur Laufzeit werden schon die benötigten temp Variablen erzeugt, ob explizit im code angegeben oder nicht.

Wichtig: das ist keine Frage der persönlichen Vorliebe, ausser man bezeichnet die tatsache dass man sauberen code schreibejn will als persönliche Vorliebe.

Große Klassen solltest du aufspalten, du wirst sicher ein paar Methoden finden die nur wenige Attribute der Klasse nutzen, idealerweise sind das Attribute die nur von diesen Methoden genutzt werden (Kohärenz).

 

[SlaterB]

das SimpleJdbcTemplate, ob neu erzeugt, vergänglich oder dauerhaft, liegt so oder so im Speicher und wird in beiden Varianten bald weggeräumt, falls überhaupt,

der relevante Unterschied sind 4 Bytes auf dem Stack-Speicher für die lokale Variable, die Referenz,
die werden exakt beim Ende der Methode aufräumt, unabhängig davon was mit dem Objekt im Heap passiert

viele lokale Variablen könnten theoretisch bei Rekursion und begrenzten Stack-Platz stören,
siehe folgendes Testprogramm:

public class Test
{
    static int k1;
    static int k2;
    static int k3;

    public static void main(String[] args)
    {
        try { rek3();   }  catch (Throwable e)   { }
        try { rek2();   }  catch (Throwable e)   { }
        try { rek1();   }  catch (Throwable e)   { }
        System.out.println("k1: " + k1);
        System.out.println("k2: " + k2);
        System.out.println("k3: " + k3);
    }

    public static void rek1()
    {
        k1++;
        rek1();
    }

    public static void rek2()
    {
        Object o = null;
        k2++;
        rek2();
    }

    public static void rek3()
    {
        Object o = null;
        Object o2 = null;
        k3++;
        rek3();
    }
}

Ausgabe:

k1: 16685
k2: 12513
k3: 10011

wenige lokale Variablen, die für alle 10.000 Methodenaufrufe gemerkt werden, reduzieren die maximale Rekursionstiefe schon deutlich,
mit mehr Speicher kann man das aber entschärfen

 

[hdi]

@Gossi

Die Messergebnisse sagen nichts aus, da deine Messung von vornherein falsch war. Und ja, ich kann das sagen ohne zu wissen wie du es gemacht hast. Das ist Micro-Benchmarking deluxe, und die paar wenigen Leute die sowas tatsächlich richtig aufziehen können würden hier wohl sagen: Sorry, nicht messbar.

 

[Marco13]

Hier wird von Performance und Speicher geredet... ???:L Es geht um eine Datenbankabfrage... In der Zeit, die benötigt wird, um auch nur 1 byte aus der DB zu lesen, könnten hunderttausende von methodenaufrufen gemacht werden, und da es bei einer DB sicher nicht um 1 byte geht, ist der Speicher auch egal :bahnhof:

Performance könnte relevant sein bei sowas wie

for (int i=0; i<n; i++)
{
    x += getFoo().getBar(i);
}

vs.

Foo foo = getFoo();
for (int i=0; i<n; i++)
{
    x += foo.getBar(i);
}

Aber darum ging es ja nicht.

Hier ist IMHO Lesbarkeit das alleinige Kriterium. Ich würde auch das erste bevorzugen. Ganz pragmatisch weil ich es subjektiv übersichtlicher finde, (es kürzere Zeilen hat), es leichter handhabbar und wartbar ist, und ich immer k**** könnte, wenn ich fremden Code ausführe, und dann bei einer Zeile wie

getFoo().getBar().getPing().getPong().getKladderadatsch().doSomethingVeryTricky();

eine NullPointerException bekomme :autsch:

 

[darekkay]

und ich immer k**** könnte, wenn ich fremden Code ausführe, und dann bei einer Zeile wie

getFoo().getBar().getPing().getPong().getKladderadatsch().doSomethingVeryTricky();

eine NullPointerException bekomme :autsch:

Sehe ich auch so. Stringmanipulationen können auch recht schnell ausarten:

String sub = (text.substring(text.indexOf('('), text.indexOf(')'))).concat(text.substring(text.indexOf('{'), text.indexOf('}')));

Sowas würde ich auf jeden Fall immer über temporäre Variablen lösen. Natürlich sollte dann aber auch nicht für jedes indexOf eine int Variable angelegt werden.
Aber alleine zu Testzwecken, wo man sich jede Teiloperation ausgeben lassen kann, finde ich es praktisch.

 

[Gast2]

Um das klarzustellen:

Mir gehts nicht um die Performanz. Die ist wirklich schnuppe. Ich finde aber auch gerade lesbarer wenn man KEINE Variable verwendet sofern diese nur einmal genutzt wird und der Getter so eindeutig ist.

Es ging mir nur um das konkrete Beispiel.

Würde man mehrere Abfragen hintereinander machen würde ich eine Variable deklarieren, alleine schon um klar zu machen, dass es sich immer um das selbe Objekt handelt.

 

[Gossi]

Große Klassen solltest du aufspalten, du wirst sicher ein paar Methoden finden die nur wenige Attribute der Klasse nutzen, idealerweise sind das Attribute die nur von diesen Methoden genutzt werden (Kohärenz).

Das ist leider das Problem, das einzige was ich auslagern könnte wären die Mapper, das wären dann rund 80 Zeilen die wegfallen, bleiben immernoch 800

Und den Methoden müsste ich sonst zum einen das SimpleJdbcTemplate und zum anderen das Sql-Statement übergeben....

 

[hdi]

Ja, bei diesem konkreten Beispiel finde ich Variante 1 auch etwas Overkill. "Schlecht" oder gar "falsch" ist aber keine von beiden, es ist hier echt einfach nur egal, in jederlei Hinsicht. Wer sich bei sowas aufregt, der braucht echt Urlaub

 

[Gossi]

....der braucht echt Urlaub

War ja grade letzte Woche krank geschrieben, da hab ich dann zu Hause an meinem kleinen Übungsprojekt weitergeschrieben xD

 

[maki]

Das ist leider das Problem, das einzige was ich auslagern könnte wären die Mapper, das wären dann rund 80 Zeilen die wegfallen, bleiben immernoch 800

Das wäre ein anfang

Als nächstes könntest du mal nachsehen, wieviele "helper" du hast, die machen sich auch gut in eigenen Klassen.

Redundanzen rausziehen ist auch immer eine gute Sache..

Und den Methoden müsste ich sonst zum einen das SimpleJdbcTemplate und zum anderen das Sql-Statement übergeben....

Vielleicht sollten der Mapper, das SQL Statement & das JDBCtemaplte von haus aus in der anderen Klasse stecken?

Martin Fowler hat mal ein sehr gutes Buch über Refactoring geschrieben (Refactoring - Improving the Design of existing Code), da wird so einiges erklärt

 

[thE_29]

Bei Variante 1 könnte man zusätzlich noch abprüfen, ob "temp" überhaupt was ist oder null ist um so eine NPE zu verhindern..

2mal für sowas die get-Methode aufzurufen (einmal für den != null Vergleich und einmal zum Arbeiten) ist dann halt nicht so super..


Und wenn man im finaly etwas mit dem "temp" machen müsste (zB Verbindungen schließen), dann müsste man es schonmal außerhalb von try/catch deklarieren und im finaly damit halt was machen..


Es kommt also auch drauf an, was man mit dem "temp" alles machen muss und ob du noch paar Sicherheitsabfragen einbauen willst..

 

[maki]

2mal für sowas die get-Methode aufzurufen (einmal für den != null Vergleich und einmal zum Arbeiten) ist dann halt nicht so super..

Eine getMethode (oder alölgemeiner accessor, muss ja nicht imer alles mit getXX beginnen) kann den null check schon durchführen ohne dass ich ihn jedesmal explizit durchführen muss

Methoden haben nunmal Vorteile gegenüber temp Variablen..."

 

[thE_29]

Jo, nur ist zB diese Methode ja von spring oder so..

Dh, etwas externes und wenn ich da keinen Source habe, woher soll ich wissen ob die get Methode auf sowas abfragt..

Ich frage lieber einmal mehr auf eine Exception ab, als einmal zuwenig..

 

[maki]

Ich frage lieber einmal mehr auf eine Exception ab, als einmal zuwenig..

Aber sicherlich doch keine NPE...
Ich meinte ja auhc nicht einer NPE vorbeugen indem man in einem "getter" schnell ein Objekt strickt falls das erwarete null ist.

 

[thE_29]

Doch ich frage oft ab, ob Objekt XYZ null ist, vorallem wenn es von Funktionen/Methoden von einer Lib kommt wo ich keinen Source habe...


Auch wenn eine Anwendung zB mit defekter Konfig gar nicht laufen sollte/kann, so wärs schön, wenn man eine Fehlermeldung kommt und das Programm nicht einfach verschwindet oder gar nicht auftaucht..

 

[maki]

Bekommst doch auch so eine Fehlermeldung..

[c]NullPointerException in..[/c]

 

[thE_29]

Haha..

Und wenn man dann kein try/catch drüber hat, dann hängt wegen einer NPE alles, bzw. funktioniert etwas komplett falsch/gar nicht oder macht sonstigen Blödsinn..

Na das ist doch ne super Fehlerbehandlung

 

[tfa]

Und wenn man dann kein try/catch drüber hat, dann hängt wegen einer NPE alles, bzw. funktioniert etwas komplett falsch/gar nicht oder macht sonstigen Blödsinn..

Wieso hängt da was? Die NPEx wird automatisch "ganz nach oben" durchgereicht und vom Ober-Exception-Handler abgefangen, der dann für den Fehlerdialog veranlasst. Das ist die beste Art der Fehlerbehandlung (falls das Problem nicht sowieso schon durch automatische Tests während der Entwicklung entdeckt und behoben wurde).

 

[thE_29]

Nunja, da habe ich mit 3t Libs schon andere Probleme gehabt..

Wo die manchmal intern gecatched wird oder sonstiger Blödsinn betrieben wird und man dann statt sinnvollen Daten null hatte und die wurden dann zB in Registry, etc. geschrieben..


Wie gesagt, ich mache fast ausschließlich die Kommunikation von uns intern nach irgendwelchen 3t-Libs (SAP, Schufa, Adobe, etc.) und da gehe ich nunmal lieber auf Nummer sicher


Außerdem, wenn eine NPE schon vor einem try/catch auftritt, dann wird auch dessen finaly nicht durchgemacht und somit zB Verbindungen zur Datenbank nicht geschlossen, etc..

 

[maki]

.. und dann?

.. macht die Anwendung einfach weiter als ob nix war?
Ich kenne keine User die sich explizit für NPEs interessieren, sei es im log, oder im Stacktrace wen die App gerade gestorben ist.

Ich meine, es gibt Fehlerfälle die man behandeln kann, bei anderen hat man einfach schon verloren wenn sie auftreten.

 

[Gossi]

Haha..

Und wenn man dann kein try/catch drüber hat, dann hängt wegen einer NPE alles, bzw. funktioniert etwas komplett falsch/gar nicht oder macht sonstigen Blödsinn..

Na das ist doch ne super Fehlerbehandlung

Dafür habe ich extra meinen Try Block in meiner Model Klasse, die alles für den View vorbereitet, hier werden alle fehler der Bearbeitung aufgefangen und entsprechend an den User und den Administrator weitergegeben (der User bekommt ne kleine selbst geschriebene Internetseite, der Admin nen Logfile)

Zudem streikt das Program eh schon früher wenn das ganze Null ist....

 

[thE_29]

@maki: Kommt aufs Einsatzgebiet an.. Zb wenn ne App Online oder Offline laufen kann und man eine NPE bei einem Verbindungsaufbau kriegt (ja so selten komische APIs gibts es ) dann sollte diese dann halt weiterlaufen können..

Aber oft treten NPEs ja auf an was der Dev gar nicht denkt.. Zb wenn in einem Feld eine Eingabe erforderlich ist und man dort zB einen substring macht..
Gibt man da nix ein (was der Dev meistens nicht macht, weil wozu gibt es das Eingabefeld -> Dev Logik != User-Logik ), macht man einen substring was entweder schonmal ne ArrayIndex..Exception wirft oder zB noch null zurückgibt und man dann gleich weiterarbeitet und dann auf eine NPE kommt..

Sowas könnte man natürlich via JUnit oder sonstige Tests abprüfen lassen, aber das macht man ja auch nicht immer..


Außerdem selbst wenn ich die NPE catche oder so, habe ich dem User nie eine Exception angezeigt.. Was tut ein Durchschnittsuser mit einer Exception?!
Da kam immer eine Fehlermeldung, die den Fehler schon ziemlich eingrenzte um somit dem Support gleich mal weiterzuhelfen...

Weil configs verschwinden ja manchmal von alleine oder sind von Zauberhand auf was falsches eingestellt

 

[maki]

NPE sind ja die klassischen Dev Fehler im Normalfall, NPEs fangen gehört für mich zur Ausnahme, niemals zur Regel.
Klar gibt es auch Fälle, in denen einfach null zurückkommen kann, aber die sind doch marginal.
Das Risiko beim NPE fangen ist doch, dass man Dev Fehler unter den Teppich kehrt.

 

[thE_29]

Deswegen fange ich ja die NPEs nicht, sondern frage ab wenn Variable XYZ null ist..

Dann gibt es entweder nen Else-Zweig oder ne Fehlermeldung (zB keine Eingabe, config nicht gefunden, etc.).



Also ich redete immer von der Überprüfung ob ein Objekt null ist und nicht vom NPE catchen.. Das tue ich wirklich nicht..

 

[Gossi]

Aber oft treten NPEs ja auf an was der Dev gar nicht denkt.. Zb wenn in einem Feld eine Eingabe erforderlich ist und man dort zB einen substring macht..
Gibt man da nix ein (was der Dev meistens nicht macht, weil wozu gibt es das Eingabefeld -> Dev Logik != User-Logik ), macht man einen substring was entweder schonmal ne ArrayIndex..Exception wirft oder zB noch null zurückgibt und man dann gleich weiterarbeitet und dann auf eine NPE kommt..

Deswegen gibts bei mir fast nur User-Eingaben/Angaben mit Drop-Down ^^
Da die Daten ja eh aus der Datenbank kommen, da reicht es dann manchmal schon nen kleines L anselle eines großen I's zu nehmen