Nutzung des auto Schlüsselwortes in Qt Projekten



  • Folgende zwei Schreibweisen sind ja möglich, welche bevorzugt ihr?

    auto actFileNewProject = new QAction(tr("&New Project"), this);
    
    QAction* actFileNewProject = new QAction(tr("&New Project"), this);
    


  • Die kürzere.



  • "All things being equal" die erste.

    Sobald es nicht mehr new ist sondern z.B. Factory-Funktionen zum Einsatz kommen, vielleicht gar Factory-Templates die verschiedene Spezialisierungen haben, ist es nicht mehr ganz so klar. Sofern diese sowie die Variable ausreichend gut benannt sind finde ich auto aber auch da OK.

    D.h. so lange der "Indexer" der IDE damit klarkommt.

    Das grösste Problem das ich in C++ mit auto habe ist bloss dass mir bekannte Indexer (Visual Studio, Visual Assist) damit leider nicht so gut klarkommen wie man es sich wünschen würde. Und dann wird's etwas doof, wenn man in manueller Detektivarbeit ausforschen muss was jetzt eigentlich der Typ ist.



  • @Swordfish Heisst das wenn der Typ bloss A heisst dann A*, bei längeren Namen aber auto? Schreibst du dann auch int für int aber auto für double?



  • @hustbaer Ok, vergiss die Antwort. Zu unpräzise.



  • Danke euch, dann werde ich weiterhin auto nutzen, hatte mich nur gefragt, warum man das so selten sieht bei Qt Beispielen.



  • Vermutlich weil Qt alt ist und daher wohl auch die Beispiele alt sind.
    Und in neueren Beispielen für neuere Features dann damit anfangen wäre auch irgendwie ein Stilbruch.



  • Macht ja Sinn, aber C++11 ist nun nicht gerade seit gestern draußen. Lambdas sehe ich hingegen öfters bei den Signals und Slots und das ist doch auch modernes C++.



  • Lambdas bringen da halt auch ungleich viel mehr als auto. Aber ich weiss es nicht, ist nur meine Vermutung. Und ja, 2011 ist schon ne Zeit her, aber Qt ist wirklich alt.



  • Ich bevorzuge QAction*. Ich finde das auf den ersten Blick viel besser lesbar. Oder evtl. etwas zutreffender formuliert, ich kann Code schneller erfassen, der mich nicht interessiert. Wenn ich auto irgendwas sehe, kann ich mit der Zeile noch nichts anfangen und muss weiterlesen. Wenn ich QAction* sehe, weiß ich gleich, dass mich der Rest sehr wahrscheinlich nicht interessiert.

    auto nehme ich wenn es nicht anders geht (z.B. Lambdas), oder wenn der Typ zu kompliziert wird, z.B. mit Templates.



  • Ist glaube ich stark davon abhängig wie man gewohnt ist Code zu lesen. Also ob man primär auf die Typen guckt oder primär auf die Bezeichner (Name der Variable die definiert wird und in der Zuweisung verwendete Bezeichner). Ich gucke eher auf die Bezeichner, von daher finde ich auto nicht schlimm zu lesen. WENN die Bezeichner gut sind. Wenn da natürlich auto st = createCtplSt(p, str, nr) oder ähnlicher Ranz steht und Variablen einfach mal fesch id oder nr heissen... dann geht das weniger gut 🙂

    (Und ja, je nachdem was eine Funktion macht können sowohl id als auch nr akzeptable oder sogar gute Namen für Parameter/lokale Variablen sein. Bzw. halt auch nicht.)



  • @Mechanics sagte in Nutzung des auto Schlüsselwortes in Qt Projekten:

    Ich bevorzuge QAction*. Ich finde das auf den ersten Blick viel besser lesbar. Oder evtl. etwas zutreffender formuliert, ich kann Code schneller erfassen, der mich nicht interessiert. Wenn ich auto irgendwas sehe, kann ich mit der Zeile noch nichts anfangen und muss weiterlesen. Wenn ich QAction* sehe, weiß ich gleich, dass mich der Rest sehr wahrscheinlich nicht interessiert.

    auto nehme ich wenn es nicht anders geht (z.B. Lambdas), oder wenn der Typ zu kompliziert wird, z.B. mit Templates.

    Da muss ich noch mal drüber nach denken, aber der Punkt mit der Lesbarkeit ist nicht zu verachten, schließlich liest mehr sehr viel häufiger Code als dass man ihn schreibt. Jedenfalls ist das bei mir so. Wenn ich alten Code von mir lese, dann habe zudem Probleme wenn ich ein Problem zu elegant lösen wollte, also mit OOP Spielereien wo ich mich dann erst mal durch drei Klassen kämpfen muss um halbwegs zu kapieren was ich da damals machen wollte.

    Heute versuche ich so wenig wie möglich irgendwas zu generalisieren und auch die Lösung so einfach wie möglich zu halten und auf irgendwelche genialen OOP Pattern oder sonst welche advanced C++ Kniffe zu verzichten. Lesbarkeit geht wirklich über alles.

    Dabei habe ich ja noch Glück weil ich nur meine eigenen Sachen wieder lesen muss. Ich kenne das aber noch von der Arbeit damals, gut das war nur PHP aber soviel OOP und schlecht dokumentiert, da sind Wochen drauf gegangen bis ich so halbwegs kapiert habe wie der Hase in dem Projekt läuft. Den Programmfluss über viele Klassen und Generalisierung hinweg zu verflogen ist das schlimmste was mir damals passiert ist.

    Um es kurz zu machen: Lesbarkeit sollte wirklich oberste Prio haben.



  • @hustbaer sagte in Nutzung des auto Schlüsselwortes in Qt Projekten:

    Ist glaube ich stark davon abhängig wie man gewohnt ist Code zu lesen. Also ob man primär auf die Typen guckt oder primär auf die Bezeichner (Name der Variable die definiert wird und in der Zuweisung verwendete Bezeichner). Ich gucke eher auf die Bezeichner, von daher finde ich auto nicht schlimm zu lesen. WENN die Bezeichner gut sind. Wenn da natürlich auto st = createCtplSt(p, str, nr) oder ähnlicher Ranz steht und Variablen einfach mal fesch id oder nr heissen... dann geht das weniger gut 🙂

    (Und ja, je nachdem was eine Funktion macht können sowohl id als auch nr akzeptable oder sogar gute Namen für Parameter/lokale Variablen sein. Bzw. halt auch nicht.)

    Ich mache es genauso. Und man kann es nicht oft genug wiederholen: Sprechende Namen für Variablen und Typen sind das A und auch das O!
    Auch wenn der Bezeichner im schlimmsten Fall 20 oder mehr Zeichen lang ist. Dann ist das eben so.


Log in to reply